Ssh linux настройка: SSH | Русскоязычная документация по Ubuntu
SSH | Русскоязычная документация по Ubuntu
Эта статья помечена как незаконченная. См. заметку в конце статьи.
Данная статья посвящена клиенту и серверу защищенного терминала (secure shell) в Ubuntu, их настройке и использованию. SSH — это специальный сетевой протокол, позволяющий получать удаленный доступ к компьютеру с большой степенью безопасности соединения. Более подробно про протокол ssh можно прочитать тут.
Описание принципов работы и используемых приложений
В основном, SSH реализован в виде двух приложений — SSH-сервера и SSH-клиента1) В Ubuntu используется свободная реализация клиента и сервера SSH — OpenSSH. При подключении клиент проходит процедуру авторизации у сервера и между ними устанавливается зашифрованное соединение. OpenSSH сервер может работать как с протоколом ssh2, так и с протоколом ssh3.
В настоящее время протокол ssh2 считается небезопасным, поэтому его использование крайне не рекомендуется. Я намеренно опускаю различные технические подробности работы протокола, т. к. основной целью данного руководства является описание его настройки и использования. Про сам протокол, принципы его работы, алгоритмы шифрования и т. д. существует множество статей в интернете, например подробно про это можно почитать здесь.
Установка
Установить OpenSSH можно из терминала командой:
sudo apt-get install ssh
В метапакете ssh содержится как клиент, так и сервер, но при этом, скорее всего, будет установлен только сервер, т. к. клиент уже есть в Ubuntu по умолчанию.
Настройка сервера
При установке SSH-сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:
sudo service ssh stop|start|restart
Основной файл конфигурации SSH-сервера — файл /etc/ssh/sshd_config, доступный для чтения или редактирования только суперпользователю.
После каждого изменения этого файла необходимо перезапустить ssh-сервер для применения таких изменений.
Пример конфигурации SSH-сервера в Ubuntu по умолчанию2):
# Пример конфигурации open-ssh сервера с русскими # # комментариями. # # Написан для http://help.ubuntu.ru # # by MadKox, 01.2010. # # # # # # Условные обозначения: # # Под "по умолчанию" - подразумевается поведение sshd при # # неуказанной явно директиве. Стоит заметить, что в Ubuntu # # файл sshd_config уже содержит ряд настроек, которые # # являются настройками по умолчанию для именно для Ubuntu. # # Такие настройки указаны в этом файле. # # # ############################################################ ################ Настройки адресов/портов и т.д. ########### ############################################################ # # ## Port #################################################### # # # Используемый порт. Можно указывать несколько, например: # # Port 22 # # Port 23 # # Port 24 # # Рекомендуется использовать нестандартный порт, т.к. # # стандартный часто сканируется ботами на предмет # # потенциальных "дырок". Может быть опущен, если задан # # через адрес. См. также параметр ListenAddress. # # # Port 22 # # ## ListenAddress ########################################### # # # Сетевой адрес, на котором "слушает" сервер.
д. ###########
############################################################
# #
## Port ####################################################
# #
# Используемый порт. Можно указывать несколько, например: #
# Port 22 #
# Port 23 #
# Port 24 #
# Рекомендуется использовать нестандартный порт, т.к. #
# стандартный часто сканируется ботами на предмет #
# потенциальных "дырок". Может быть опущен, если задан #
# через адрес. См. также параметр ListenAddress. #
# #
Port 22
# #
## ListenAddress ###########################################
# #
# Сетевой адрес, на котором "слушает" сервер.
Адрес можно #
# записывать так: #
# ListenAddress host|IPv4_addr|IPv6_addr #
# ListenAddress host|IPv4_addr:port #
# ListenAddress [host|IPv6_addr]:port #
# Если порт не задан, sshd будет слушать на этом адресе и #
# на порту, указанному в опции Port. Если вы будете #
# использовать ListenAddress не указывая порт, то опция #
# Port должна предшествовать опции ListenAddress. Если не #
# указывать, то по умолчанию слушает на всех локальных #
# адресах. Можно указывать несколько адресов. #
# #
## AddressFamily ###########################################
# #
# Указывает, какое семейство IP адресов должно быть #
# использовано sshd. Возможные варианты: #
# “any” - любые #
# “inet” (только IPv4) #
# “inet6” (только IPv6) #
# По умолчанию - “any”.
#
AddressFamily inet
# #
## UseDNS ##################################################
# #
# Указывает, должен ли sshd проверять имя хоста и #
# используя это имя сверять IP адрес переданный клиентом с #
# полученным от DNS. #
# Значение по умолчанию - “yes”. #
# #
############################################################
############# Настройки доступа пользователей ##############
############################################################
# #
# Пустить/не пустить пользователя определяется директивами #
# DenyUsers, AllowUsers, DenyGroups, и AllowGroups. #
# при этом, проверка проходит сверху - вниз по цепочке: #
# ## DenyUsers ## #
# || #
# ## AllowUsers ## #
# || #
# ## DenyGroups ## #
# || #
# ## AllowGroups ## #
# Принимаются только имена пользователей и групп, числовые #
# идентификаторы (UserID) - не распознаются.
Корректная #
# запись нескольких пользователей/групп по очереди, через #
# пробел. Если записано в виде пользователь@хост - то #
# пользователь и хост проверяются отдельно, это позволяет #
# разграничить доступ определенных пользователей с #
# определенных хостов. Стоит помнить, что директивы #
# DenyUsers и AllowUsers принимают в качестве параметра #
# имя пользователя, а DenyGroups и AllowGroups - имя #
# группы. См. PATTERNS в man ssh_config для дополнительной #
# информации о формах записи имен пользователей и групп. #
# #
## DenyUsers ###############################################
# #
# Список ПОЛЬЗОВАТЕЛЕЙ, которым НЕЛЬЗЯ пользоваться sshd. #
# По умолчанию - не указан = не запрещен никто. Т.е. если #
# тут указан пользователь, то ему будет отказано в доступе #
# к ssh серверу. #
# #
## AllowUsers ##############################################
# #
# Список ПОЛЬЗОВАТЕЛЕЙ, которым МОЖНО пользоваться sshd, #
# По умолчанию - не указан = разрешено всем.
Т.е. если #
# указан хотя бы один пользователь, ssh доступ к серверу #
# доступен только для него. #
# #
## DenyGroups ##############################################
# #
# Список ГРУПП, которым НЕЛЬЗЯ пользоваться sshd. #
# По умолчанию - не указан = не запрещена ни одна группа. #
# Т.е. если указана хотя бы одна группа, то пользователям, #
# входящим в эту группу будет отказано в доступе к ssh #
# серверу. #
# #
## AllowGroups #############################################
# #
# Список ГРУПП, которым МОЖНО пользоваться sshd. #
# По умолчанию - не указан = разрешено всем. Т.е. если #
# указана хотя бы одна группа, то только тем пользователям,#
# которые в нее входят будет разрешен доступ к ssh серверу.
#
# #
############################################################
######### Опции определения состояния соединения ###########
############################################################
# #
## TCPKeepAlive ############################################
# #
# Указывает, нужно системе посылать TCP сообщения клиенту #
# с целью поддержания соединения. Если посылать эти пакеты,#
# можно определить разрыв соединения. Однако это также #
# означает, что соединение может быть разорвано в случае #
# кратковременного перебоя в работе маршрутизации и #
# некоторых это сильно раздражает. С другой стороны, если #
# таких сообщений не посылать - сеансы на сервере могут #
# длиться бесконечно, порождая пользователей - "призраков",#
# и пожирая ресурсы сервера. Значение по умолчанию - “yes”,#
# т.е. посылать такие сообщения.
Для отключения отправки #
# таких сообщений нужно задать значение “no”. Ранее эта #
# опция называлась KeepAlive. Стоит заметить, что #
# существуют более защищенные способы проверки состояния #
# соединения (см. ниже). #
# #
TCPKeepAlive yes
# #
## ClientAliveCountMax #####################################
# #
# Задает количество сообщений к клиентам, которые sshd #
# посылает подряд, не получая какого либо ответа от #
# клиента. Если пороговое значение будет достигнуто, а #
# клиент так и не ответил - sshd отключит клиента, прервав #
# ssh сессию. Стоит отметить, что использование таких #
# сообщений в корне отличается от директивы TCPKeepAlive. #
# Сообщения к/от клиентов посылаются по зашифрованному #
# каналу и поэтому не подвержены спуфингу.
Сообщения же #
# TCPKeepAlive спуфингу подвержены. Механизм client alive #
# особо ценен в тех случаях, когда серверу и клиенту нужно #
# знать когда соединение стало неактивным. По умолчанию #
# значение равно 3. В случае, если ClientAliveInterval #
# задан равным 15 и ClientAliveCountMax оставлен по #
# умолчанию, неотвечающие клиенты будут отключены примерно #
# через 45 секунд. Эта директива работает только для #
# протокола ssh3. #
# #
## ClientAliveInterval #####################################
# #
# Задает временной интервал в секундах. Если в течении #
# этого интервала не было обмена данными с клиентом, sshd #
# посылает сообщение по зашифрованному каналу, #
# запрашивающее ответ от клиента. По умолчанию - 0, т.е. #
# не посылать таких сообщений. Эта директива работает #
# только для протокола ssh3.:max_bytes(150000):strip_icc()/keyauth_1-5c462295c9e77c0001af2b92.jpg)
#
# #
############################################################
################ Общие опции аутентификации ################
############################################################
# #
## AuthorizedKeysFile ######################################
# #
# Указывает файл, в котором содержатся публичные ключи, #
# используемые для аутентификации пользователей. Директива #
# может содержать маркеры вида %М, которые подставляются в #
# процессе установки соединения. #
# Определены следующие маркеры: #
# %% - заменяется литералом '%' #
# %h - заменяется домашней директорией #
# аутентифицируещегося пользователя #
# %u - заменяется именем аутентифицируещегося пользователя #
# Таким образом, файл с ключами может быть задан как #
# абсолютным путем (т.
е. один общий файл с ключами), так и #
# динамически - в зависимости от пользователя (т.е. по #
# файлу на каждого пользователя). #
# По умолчанию - “.ssh/authorized_keys”. #
# Пример для файла ключа в домашней папке пользователя: #
# AuthorizedKeysFile %h/.ssh/authorized_key #
# Пример для общего файла: #
# AuthorizedKeysFile /etc/ssh/authorized_keys #
# См. описание файла authorized_keys для большей #
# информации. #
# #
## ChallengeResponseAuthentication #########################
# #
# Указывает, разрешить ли аутентификацию вида вопрос-ответ #
# (challenge-response authentication). Поддерживаются все #
# виды аутентификации из login.conf По умолчанию - “yes”, #
# т.е. разрешить. #
# В Ubuntu - выключена по соображениям безопасности.
#
# #
ChallengeResponseAuthentication no
# #
## HostbasedUsesNameFromPacketOnly #########################
# #
# Указывает, как сервер должен получать имя хоста клиента #
# при схеме аутентификации, основанной на проверке хоста. #
# Если задать "yes" - при проверке соответствия в файлах #
# ~/.shosts, ~/.rhosts или /etc/hosts.equiv sshd будет #
# использовать имя хоста, предоставленное клиентом. #
# (выполняя реверсивное DNS распознование) Если задать "no"#
# - sshd будет ресолвить имя из самого TCP соединения. #
# По умолчанию - "no". #
# #
## IgnoreRhosts ############################################
# #
# Запрещает использование файлов .rhosts и .
shosts #
# в процессе аутентификации, основанной на проверке хоста. #
# (RhostsRSAAuthentication или HostbasedAuthentication). #
# Файлы /etc/hosts.equiv и /etc/ssh/shosts.equiv все еще #
# используются. #
# По умолчанию - “yes”. #
# #
IgnoreRhosts yes
# #
## IgnoreUserKnownHosts ####################################
# #
# Указывает должен ли sshd игнорировать пользовательские #
# "известные хосты" - файл ~/.ssh/known_hosts в процессе #
# аутентификации, основанной на проверке хоста #
# (RhostsRSAAuthentication или HostbasedAuthentication). #
# По умолчанию - “no”. #
# #
## PermitBlacklistedKeys ###################################
# #
# Указывает, стоит ли sshd принимать ключи, занесенные в #
# черный список как скомпрометированные (known-compromised #
# keys (см.
ssh-vulnkey)). Если задано значение “yes” - #
# попытки аутентификации с такими ключами будут занесены в #
# журнал и приняты, если значение “no” - попытки #
# аутентификации будут отвергнуты. #
# По умолчанию - “no”. #
# #
## PermitEmptyPasswords ####################################
# #
# В случае разрешенной аутентификации с помощью пароля, #
# указывает, возможен ли вход с пустым паролем. #
# По умолчанию - “no”. #
# #
PermitEmptyPasswords no
# #
## PermitRootLogin #########################################
# #
# Указывает, возможен ли ssh-вход под суперпользователем #
# (root). Может принимать значения: #
# “yes” - суперпользователь может зайти.
Применяется #
# текущая глобальная схема аутентификации. #
# #
# “without-password” - суперпользователь может зайти. #
# Парольная аутентификация для него будет отключена. #
# #
# “forced-commands-only” - суперпользователь сможет зайти, #
# пользуясь аутентификацией на основе публичного ключа и #
# только если передаст необходимую к исполнению комнаду. #
# Это удобно для осуществления резервного копирования, #
# даже в том случае, когда нормальный (т.е. не через ssh) #
# вход суперпользователя запрещен. Все остальные методы #
# аутентификации для суперпользователя будут заблокированы.#
# #
# “no” - суперпользователь не может использовать ssh для #
# входа в систему. #
# #
# Значение по умолчанию - “yes”.
#
# #
PermitRootLogin yes
# #
## Protocol ################################################
# #
# Указывает, какой протокол должен использовать sshd. #
# Возможные значения ‘1’ и ‘2’ - ssh2 и ssh3 #
# соответственно. Возможна одновременная запись, при #
# которой значения следует разделять запятыми. #
# По умолчанию - “2,1”. #
# Стоит отметить, что порядок следования протоколов в #
# записи не задает приоритет, т.к. клиент выбирает какой #
# из нескольких предложенных сервером протоколов ему #
# использовать.Запись "2,1" абсолютно идентична #
# записи "1,2". #
# #
Protocol 2
# #
## UsePAM ##################################################
# #
# Включает интерфейс PAM (Pluggable Authentication Module #
# interface).
Если задано значение "yes" - для всех типов #
# аутентификации помимо обработки модуля сессии и аккаунта #
# PAM будет использоваться аутентификация на основе #
# запроса-ответа (ChallengeResponseAuthentication и #
# PasswordAuthentication) Т.к. аутентификация #
# запросов-ответов в PAM обычно выполняет ту же роль, #
# что и парольная аутентификация, вам следует отключить #
# либо PasswordAuthentication, либо #
# ChallengeResponseAuthentication. Стоит отметить, что #
# если директива UsePAM включена - вы не сможете запустить #
# sshd от имени пользователя, отличного от root. #
# Значение по умолчанию - “no”. #
# #
UsePAM yes
# #
## PasswordAuthentication ##################################
# #
# Указывает, разрешена ли аутентификация с использованием #
# пароля.
#
# По умолчанию - “yes”. #
# #
## HostKey #################################################
# #
# Указывает файл, содержащий закрытый хост-ключ, #
# используемый SSH. По умолчанию - /etc/ssh/ssh_host_key #
# для протокола ssh2 и /etc/ssh/ssh_host_rsa_key и #
# /etc/ssh/ssh_host_dsa_key для протокола ssh3. Стоит #
# отметить, что sshd не станет пользоваться файлом, #
# который доступен кому либо, кроме пользователя. Можно #
# использовать несколько файлов с ключами, ключи “rsa1” - #
# для протокола ssh2 и “dsa”/“rsa” для протокола ssh3. #
# #
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# #
############################################################
########## Опции протокола SSH версии 1 (ssh2) #############
############################################################
# Настоятельно НЕ РЕКОМЕНДУЕТСЯ использовать протокол ssh2.
#
# Протокол ssh3 намного более безопасен, чем ssh2 #
############################################################
# #
## KeyRegenerationInterval #################################
# #
# Для протокола ssh2 - раз в определенное время #
# автоматически генерируется новый временный ключ сервера #
# (если он был использован). Это сделано для #
# предотвращения расшифровки перехваченных сеансов,с целью #
# позже зайти с параметрами этих сеансов на машину и #
# украсть ключи. Такой ключ нигде не хранится (хранится в #
# оперативной памяти). Данная директива указывает период #
# "жизни" ключа в секундах, после которого он будет #
# сгенерирован заново. Если значение задать равным 0 - #
# ключ не будет генерироваться заново. #
# По умолчанию значение - 3600 (секунд). #
# #
KeyRegenerationInterval 3600
# #
## RhostsRSAAuthentication #################################
# #
# Указывает, нужна ли аутентификация на основе файлов #
# rhosts или /etc/hosts.
equiv совместно с успешной #
# аутентификацией хоста через RSA. #
# Актуально только для протокола ssh2. #
# По умолчанию - “no”. #
# #
RhostsRSAAuthentication no
# #
## RSAAuthentication #######################################
# #
# Указывает, разрешена ли "чистая" RSA-аутентификация. #
# Актуально только для протокола ssh2. #
# По умолчанию - “yes”. #
# #
RSAAuthentication yes
# #
## ServerKeyBits ###########################################
# #
# Определяет число бит во временном ключе сервера для #
# протокола ssh2.
Минимальное значение 512. #
# Значение по умолчанию - 1024. #
ServerKeyBits 768
# #
############################################################
########### Опции протокола SSH версии 2 (ssh3) ############
############################################################
# #
## Ciphers #################################################
# #
# Указывает алгоритмы шифрования, разрешенные для #
# протокола ssh3. Несколько алгоритмов должны быть #
# разделены запятыми. Поддерживаемые алгоритмы: #
# “3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, #
# “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “arcfour128”, #
# “arcfour256”, “arcfour”, “blowfish-cbc”, “cast128-cbc”. #
# По умолчанию используются: #
# aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, #
# arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr, #
# aes192-ctr,aes256-ctr #
# #
## HostbasedAuthentication #################################
# #
# Указывает, разрешена ли аутентификация, основанная на #
# проверке хоста.
Проверяется rhosts или /etc/hosts.equiv, #
# и в случае успеха, совместного с успешной проверкой #
# публичного ключа, доступ разрешается. Данная директива #
# одинакова с директивой RhostsRSAAuthentication и #
# подходит только для протокола ssh3. #
# По умолчанию - "no". #
# #
HostbasedAuthentication no
# #
## MACs ####################################################
# #
# Указывает допустимый алгоритм MAC (message #
# authentication code). Алгоритм MAC используется #
# протоколом ssh3 для защиты целостности данных. Несколько #
# алгоритмов должны быть разделены запятыми. #
# По умолчанию используются: #
# hmac-md5,hmac-sha1,
Актуально только для протокола ssh3. #
# По умолчанию - “yes”. #
# #
PubkeyAuthentication yes
############################################################
#################### Опции GSSAPI ##########################
############################################################
# #
############ Применимо только для протокола ssh3 ###########
# #
## GSSAPIAuthentication ####################################
# #
# Указывает, разрешена ли аутентификация пользователя на #
# основе GSSAPI. По умолчанию - "no", т.е. запрещена. #
# #
## GSSAPIKeyExchange #######################################
# #
# Указывает, разрешен ли обмен ключами, основанный на #
# GSSAPI.
Обмен ключам при помощи GSSAPI не полагается на #
# ssh ключи при верификации идентичности хоста. #
# По умолчанию - "no" - т.е. обмен запрещен. #
# #
## GSSAPICleanupCredentials ################################
# #
# Указывает, нужно ли автоматически уничтожать #
# пользовательский кеш аутентификационных полномочий при #
# завершении сеанса. #
# По умолчанию - "yes" - т.е. нужно уничтожать. #
# #
## GSSAPIStrictAcceptorCheck ###############################
# #
# Указывает, насколько строгой должна быть проверка #
# идентичности клиента при аутентификации через GSSAPI. #
# Значение "yes" заставляет клиента аутентифицироваться в #
# принимающей хост-службе на текущем хосте.
Значение "no" #
# позволяет клиенту аутентифицироваться при помощи любого #
# ключа служб. #
# Значение по умолчанию - "yes". #
# Стоит заметить, что задание значения "no" может #
# сработать только с редкими библиотеками Kerberos GSSAPI. #
# #
############################################################
################### Опции Kerberos #########################
############################################################
# #
## KerberosAuthentication ##################################
# #
# Указывает, требует ли пароль, предоставленный #
# пользователем для аутентификации #
# (PasswordAuthentication) валидации в Kerberos KDC. #
# Для использования этой опции серверу нужно #
# удостовериться в истинности KDC.
(Тhe server needs a #
# Kerberos servtab which allows the verification of the #
# KDC’s identity) #
# По умолчанию - “no”. #
# #
## KerberosGetAFSToken #####################################
# #
# Если активен AFS и пользователь получил Kerberos 5 TGT, #
# пытаться ли получить AFS токен до того, как пользователь #
# получит доступ к своей домашней папке. #
# По умолчанию - “no”. #
# #
## KerberosOrLocalPasswd ###################################
# #
# Указывает, как поступать в случае, если аутентификация #
# через Kerberos завершилась неудачей. Если #
# значение = "yes" - пароль будет проверен при помощи #
# любого дополнительного локального механизма авторизации, #
# например - /etc/passwd.
#
# По умолчанию - “yes”. #
# #
## KerberosTicketCleanup ###################################
# #
# Указывает, нужно ли автоматически уничтожать файл с #
# кешем тикета пользователя по завершению сеанса. #
# По умолчанию - “yes”. #
# #
############################################################
################# Опции перенаправления ####################
############################################################
# #
## AllowAgentForwarding ####################################
# #
# Указывает, разрешить или запретить перенаправление #
# ssh-agent'а. По умолчанию - “yes”, т.е. разрешить.
#
# Стоит заметить, что отключение перенаправления не #
# увеличит безопасности пока пользователям также не будет #
# запрещен shell доступ, т.к. они всегда смогут установить #
# свои собственные аналоги агента. #
# #
## AllowTcpForwarding ######################################
# #
# Указывает, разрешить или запретить перенаправление TCP. #
# По умолчанию - “yes”, т.е. разрешить. Стоит заметить, #
# что как и в случае с AllowAgentForwarding отключение #
# перенаправления не увеличит безопасности, пока у #
# пользователей будет консольный доступ, т.к. они смогут #
# установить свои аналоги. #
# #
# #
## GatewayPorts ############################################
# #
# Указывает, разрешать ли удаленным хостам доступ к #
# перенаправленным портам.
По умолчанию, sshd слушает #
# соединения к перенаправленным портам только на локальном #
# интерфейсе (loopback). Это не дает другим удаленным #
# хостам подсоединяться к перенаправленным портам. Можно #
# использовать GatewayPorts, чтобы разрешить sshd это #
# делать. Директива может принимать 3 значения: #
# "no" - только loopback. #
# "yes"- любые адреса. #
# "clientspecified" - адреса указанные клиентом. #
# #
## PermitOpen ##############################################
# #
# Указывает куда разрешено перенаправление TCP портов. #
# Указание перенаправления должно принимать одну из #
# следующих форм: #
# PermitOpen host:port #
# PermitOpen IPv4_addr:port #
# PermitOpen [IPv6_addr]:port #
# Несколько записей можно задать, разделяя их пробелами.
#
# Аргумент “any” можно использовать для снятия всех #
# запретов на перенаправление портов. По умолчанию любое #
# перенаправление разрешено. #
# #
## PermitTunnel ############################################
# #
# Указывает, разрешено ли перенаправление tun-устройств. #
# Может принимать значения: #
# “yes” #
# “point-to-point” (3-й сетевой уровень) #
# “ethernet” (2-й сетевой уровень) #
# “no” #
# Значение “yes” разрешает одновременно и “point-to-point” #
# и “ethernet”. По умолчанию - “no”. #
# #
############################################################
################## Опции журналирования ####################
############################################################
# #
## SyslogFacility ##########################################
# #
# Задает код объекта журнала для записи сообщений в #
# системный журнал от sshd.
Возможные значения: #
# DAEMON #
# USER #
# AUTH #
# LOCAL0 #
# LOCAL1 #
# LOCAL2 #
# LOCAL3 #
# LOCAL4 #
# LOCAL5 #
# LOCAL6 #
# LOCAL7 #
# По умолчанию используется AUTH. #
# #
SyslogFacility AUTH
# #
## LogLevel ################################################
# #
# Задает уровень детальности журнала sshd.
#
# Возможные варианты: #
# SILENT #
# QUIET #
# FATAL #
# ERROR #
# INFO #
# VERBOSE #
# DEBUG #
# DEBUG1 #
# DEBUG2 #
# DEBUG3 #
# По умолчанию - INFO. #
# DEBUG и DEBUG1 эквивалентны друг другу. #
# DEBUG2 и DEBUG3 задают самые высокие уровни отладочного #
# вывода. Запись логов с уровнем DEBUG угрожает #
# приватности пользователей и не рекомендована. #
# #
LogLevel INFO
# #
############################################################
################### Перенаправление X11 ####################
############################################################
# #
## X11Forwarding ###########################################
# #
# Указывает, разрешено ли перенаправление графической #
# подсистемы X11.
Может принимать значения “yes” или “no”. #
# По умолчанию - “no”. #
# Внимание - включение простого перенаправления Х11 - #
# большой риск как для сервера, так и для клиентов, т.к. в #
# случае такого перенаправления прокси-дисплей sshd #
# принимает соединения с любых адресов. Используйте #
# директиву X11UseLocalhost для ограничения доступа к #
# серверу перенаправления "иксов". Стоит отметить, что #
# отключение перенаправления не даст гарантии, что #
# пользователи не смогут перенаправлять Х11, т.к. имея #
# консольный доступ они всегда установить свой #
# перенаправлятель. Перенаправление Х11 будет #
# автоматически отключено, если будет задействована #
# директива UseLogin. #
# #
X11Forwarding yes
# #
## X11UseLocalhost #########################################
# #
# Указывает, должен ли sshd ограничить область #
# перенаправления Х11 локальным loopback адресом, или #
# должен разрешить любые адреса.
По умолчанию - sshd #
# "сажает" сервер перенаправления Х11 на локальный адрес #
# и задает часть переменной окружения DISPLAY, отвечающую #
# за имя хоста как “localhost”. Стоит заметить, что #
# некоторые старые клиенты Х11 могут не работать с такими #
# настройками. По умолчанию - "yes", т.е. перенаправление #
# ограничено локалхостом, значение - “no” - отключает #
# ограничения. #
# #
## XAuthLocation ###########################################
# #
# Указывает полный путь к программе xauth. #
# По умолчанию - /usr/bin/X11/xauth. #
# #
## X11DisplayOffset ########################################
# #
# Указывает номер первого дисплея, доступного sshd в #
# качестве перенаправления X11.
Это сделано для того, #
# чтобы перенаправленные "иксы" не пересекались с #
# реальными. По умолчанию - 10. #
# #
X11DisplayOffset 10
# #
############################################################
################### Различные опции ########################
############################################################
# #
## LoginGraceTime ##########################################
# #
# Время, по прошествии которого сервер отключает #
# пользователя, если тот не смог удовлетворительно #
# залогиниться. Значение 0 - разрешает пользователю #
# логиниться бесконечно. По умолчанию - 120 (секунд). #
# #
LoginGraceTime 120
# #
## MaxAuthTries ############################################
# #
# Указывает максимальное число попыток аутентификации, #
# разрешенное для одного соединения.
#
# Как только число неудачных попыток превысит половину #
# заданного значения, все последующие попытки будут #
# заноситься в журнал. Значение по умолчанию - 6. #
# #
## MaxSessions #############################################
# #
# Указывает максимальное число одновременных подключений #
# для каждого сетевого соединения. По умолчанию - 10. #
# #
## MaxStartups #############################################
# #
# Указывает максимальное число одновременных #
# неавторизованных подключений к sshd. В случае, если #
# число подключений превысит лимит - все дополнительные #
# подключения будут сброшены до тех пор, пока текущие #
# подключения не завершатся либо успешной авторизацией, #
# либо истечением периода времени указанного в директиве #
# LoginGraceTime.
Значение по умолчанию - 10. #
# Дополнительно, можно задать ранний сброс соединений, #
# указав в качестве параметра три значения, разделенные #
# двоеточием “start:rate:full” (например: "10:30:60"). #
# sshd отклонит попытку соединения с вероятностью равной #
# “rate/100” (т.е. в нашем примере - 30%), если уже #
# имеется “start” (10) неавторизованных соединений. #
# Вероятность увеличивается линейно и любые попытки #
# соединения будут отклонены, если число неавторизованных #
# соединений достигнет значения “full” (60). #
# #
## Compression #############################################
# #
# Указывает, разрешено ли сжатие данных. Может быть #
# "yes" - сжатие разрешено. #
# "delayed" - сжатие отложено до тех пор, пока #
# пользователь успешно не аутентифицируется.
#
# "no" - сжатие запрещено. #
# По умолчанию - "delayed". #
# #
## UseLogin ################################################
# #
# Указывает, должен ли использоваться login для #
# интерактивного сеанса. Значение по умолчанию - “no”. #
# Стоит отметить, что login никогда не использовался для #
# выполнения удаленных команд. Так же заметим, что #
# использование login сделает невозможным использование #
# директивы X11Forwarding, потому что login не знает, что #
# ему делать с xauth. Если включена директива #
# UsePrivilegeSeparation - она будет отключена после #
# авторизации. #
# #
## UsePrivilegeSeparation ##################################
# #
# Указывает, должен ли sshd разделять привилегии.
Если да #
# - то сначала будет создан непривилегированный дочерний #
# процесс для входящего сетевого трафика. После успешной #
# авторизации будет создан другой процесс с привилегиями #
# вошедшего пользователя. Основная цель разделения #
# привилегий - предотвращение превышения прав доступа. #
# Значение по умолчанию - “yes”. #
# #
UsePrivilegeSeparation yes
# #
## StrictModes #############################################
# #
# Указывает должен ли sshd проверить режимы доступа и #
# владения пользовательских папок и файлов перед тем, как #
# дать пользователю войти. Обычно это объясняется тем, что #
# новички часто делают свои файлы доступными для записи #
# всем подряд.По умолчанию - “yes”. #
# #
StrictModes yes
# #
## AcceptEnv ###############################################
# #
# Указывает, какие переменные окружения, переданные #
# клиентом будут приняты.
См. опцию SendEnv в клиенте. #
# Стоит заметить, что передача переменных возможна только #
# для протокола ssh3. Переменные указываются по имени, #
# можно использовать маски (‘*’ и ‘?’). Можно указывать #
# несколько переменных через пробел, или разбить на #
# несколько строк AcceptEnv. Будьте осторожны - некоторые #
# переменные окружения могут быть использованы для обхода #
# запрещенных пользовательских окружений. Пользуйтесь этой #
# директивой аккуратно. По умолчанию никакие #
# пользовательские переменные окружения не принимаются. #
# #
AcceptEnv LANG LC_*
# #
## PermitUserEnvironment ###################################
# #
# Указывает, должен ли sshd воспринимать #
# ~/.ssh/environment и опцию environment= в #
# ~/.ssh/authorized_keys. По умолчанию - “no”.
Стоит #
# заметить, что разрешение обработки окружения может дать #
# пользователям возможность обойти ограничения в некоторых #
# конфигурациях, использующих такие механизмы, как #
# LD_PRELOAD. #
# #
# #
## PidFile #################################################
# #
# Указывает файл, содержащий идентификатор процесса #
# (process ID, PID) демона SSH. #
# По умолчанию - /var/run/sshd.pid #
# #
# #
## PrintLastLog ############################################
# #
# Указывает, должен ли sshd выводить на экран дату и время #
# последнего севнса при интерактивном входе пользователя.
#
# По умолчанию - “yes”. #
# #
PrintLastLog yes
# #
## PrintMotd ###############################################
# #
# Указывает, должен ли sshd выводить на экран /etc/motd #
# при интерактивном входе пользователя. На некоторых #
# системах (например в Ubuntu) эта информация так же #
# выводится на экран оболочкой. #
# Значение по умолчанию - “yes”. #
# #
PrintMotd no
# #
## Banner ##################################################
# #
# Указывает какой файл содержит текстовый баннер, который #
# будет показан пользователю ПЕРЕД процедурой #
# аутентификации.
Опция доступна только для протокола ssh3.#
# По умолчанию - не показывает ничего. #
# В Ubuntu файл issue.net содержит фразу Ubuntu {version}, #
# например, для karmic это "Ubuntu 9.10". Можно #
# использовать для дезориентации возможных атакующих, #
# написав туда например "My D-Link Interet Router" =) #
# #
Banner /etc/issue.net
# #
## ChrootDirectory #########################################
# #
# Если указан - предоставляет путь, по которому будет #
# выполнен chroot после аутентификации. Путь и все его #
# содержимое должны соответствовать принадлежащим #
# суперпользователю папкам и быть не доступными для #
# записи другими пользователями. #
# В пути могут быть указаны метки, подставляемые в #
# процессе аутентификации: #
# %% - заменяется литералом '%' #
# %h - заменяется домашней директорией #
# аутентифицируещегося пользователя #
# %u - заменяется именем аутентифицируещегося пользователя #
# chroot-папка должна содержать все необходимые файлы и #
# папки для пользовательского сеанса.
Для интерактивного #
# сеанса нужны как минимум: #
# оболочка, обычно - sh #
# базовые устройства в /dev, такие как: #
# null, zero, stdin, stdout, stderr, arandom и tty #
# для сеанса передачи данных при помощи sftp никаких #
# дополнительных настроек не нужно, если используется #
# внутренний процесс sftp сервера. См. Subsystem для #
# большей информации. По умолчанию chroot не выполняется. #
# #
## ForceCommand ############################################
# #
# Заставляет выполняться указанную команду. Игнорирует #
# любые команды переданные клиентом или записанные в #
# ~/.ssh/rc. Команда вызывается из пользовательской #
# оболочки с опцией -с. Подходит для запуска оболочки, #
# команды или подсистемы. Наиболее полезна внутри блока #
# Match.
Команда, изначально переданная клиентом, хранится #
# в переменной окружения SSH_ORIGINAL_COMMAND. Если #
# указать команду "internal-sftp", будет запущен #
# внутренний sftp сервер, которому не нужны дополнительные #
# файлы и папки, описанные в директиве ChrootDirectory. #
# #
## Subsystem ###############################################
# #
# Определяет и настраивает внешнюю подсистему (например #
# демона передачи файлов - file transfer daemon). #
# Аргументами служат имя и команда (с возможными #
# аргументами), которая будет выполнена во время запроса #
# на подсистемы. Команда sftp-server запускает “sftp” - #
# подсистему передачи файлов. Дополнительно можно указать #
# в качестве подсистемы “internal-sftp” - что запустит #
# внутренний sftp сервер. Это может значительно упростить #
# настройку в случае использования директивы #
# ChrootDirectory По умолчанию никаких подсистем #
# не вызывается.
Актуально только для протокола ssh3. #
# #
Subsystem sftp /usr/lib/openssh/sftp-server
# #
############################################################
##################### Блок Match ###########################
############################################################
# #
# Специально вынес в конец файла, чтобы было удобнее #
# писать Match правила. #
# MadKox. #
# #
# Директива Match представляет собой начало условного #
# блока. Если выполнены все критерии, указанные в строке #
# Match, директивы в последующих строках блока выполняются,#
# позволяя обойти значения глобальных директив файла #
# sshd_config для случая, являющегося критерием директивы #
# Match.
Блоком считаются все строки, идущие после строки #
# с критерием (Match - строки) до следующей match-строки #
# или до конца файла. Аргумент директивы Match - одна или #
# несколько пар записей критериев. Возможные виды записей: #
# User #
# Group #
# Host #
# Address #
# Записи могут содержать как одиночные значения #
# (например User=user), так и несколько значений, #
# разделенные запятыми (User=user1,user2). Так же могут #
# быть использованы регулярные выражения, описанные в #
# секции PATTERNS файла ssh_config. Записи в критерии #
# Address могут содержать адреса в нотации CIDR #
# (Адрес/Длинна маски, например “192.0.2.0/24” или #
# “3ffe:ffff::/32”). Стоит заметить, что представленная #
# длинна маски должна соответствовать адресу, и слишком #
# длинные/короткие для адреса не будут работать.
#
# В качестве директив Match может использовать только #
# определенный набор директив: #
# AllowTcpForwarding #
# Banner #
# ChrootDirectory #
# ForceCommand #
# GatewayPorts #
# GSSAPIAuthentication #
# HostbasedAuthentication #
# KbdInteractiveAuthentication #
# KerberosAuthentication #
# MaxAuthTries #
# MaxSessions #
# PasswordAuthentication #
# PermitOpen #
# PermitRootLogin #
# RhostsRSAAuthentication #
# RSAAuthentication #
# X11DisplayOffset #
# X11Forwarding #
# X11UseLocalHost # Можно скопировать приведенный выше текст в ваш собственный sshd_config и использовать в дальнейшем для настройки.
Рекомендуемые параметры. Безопасность
Сам по себе, неправильно настроенный SSH-сервер — огромная уязвимость в безопасности системы, т. к. у возможного злоумышленника есть возможность получить практически неограниченный доступ к системе. Помимо этого, у sshd есть много дополнительных полезных опций, которые желательно включить для повышения удобства работы и безопасности3).
Port, ListenAddress и AddressFamily
Эти три параметра определяют, на каких портах и адресах ваш сервер будет ждать входящие соединения. Во-первых, имеет смысл по возможности ограничить семейство обрабатываемых адресов реально используемыми, т. е. если вы используете только IPv4 — отключите IРv6, и наоборот. Сделать это можно при помощи параметра AddressFamily, например (для разрешения IPv4 и запрета IPv6):
AddressFamily inet
Во-вторых, желательно сменить стандартный порт (22) на котором слушает sshd. Это связано с тем, что многочисленные сетевые сканеры постоянно пытаются соединиться с 22-м портом и как минимум получить доступ путем перебора логинов/паролей из своей базы.
Даже если у вас и отключена парольная аутентификация — эти попытки сильно засоряют журналы и (в большом количестве) могут негативно повлиять на скорость работы ssh сервера. Если же вы по какой либо причине не желаете изменить стандартный порт вы можете использовать как различные внешние утилиты для борьбы брутфорсерами, например fail2ban, так и встроенные, такие как MaxStartups.
Задать порт можно как абсолютным значением для всех интерфейсов при помощи директивы Port, так и конкретным значением для каждого интерфейса, при помощи директивы ListenAddress. Например:
Port 2002
или
ListenAddress 192.168.0.1:2003 ListenAddress 192.168.1.1:2004
Запрещение удаленного доступа для суперпользователя
По умолчанию root-доступ запрещен по паролю (по ключу — можно) — опция PermitRootLogin установлена в without-password4). Но, при условии, что по умолчанию в Ubuntu пользователь, добавленный при установке системы имеет возможность решать все административные задачи через sudo, создавать возможность root доступа к системе через ssh — выглядит неразумно (даже при аутентификации по ключу).
Рекомендуется совсем отключить. эту опцию, или применять ее только в режиме forced-commands-only. Отключить root-доступ можно так:
PermitRootLogin no
Парольная аутентификация
Разрешенная по умолчанию парольная аутентификация является практически самым примитивным способом авторизации в sshd. С одной стороны это упрощает конфигурацию и подключение новых пользователей (пользователю достаточно знать свой системный логин/пароль), с другой стороны пароль всегда можно подобрать, а пользователи часто пренебрегают созданием сложных и длинных паролей. Специальные боты постоянно сканируют доступные из интернета ssh сервера и пытаются авторизоваться на них путем перебора логинов/паролей из своей базы. Настоятельно не рекомендуется использовать парольную аутентификацию. Отключить ее можно так:
PasswordAuthentication no
Если по каким либо причинам вам все таки хочется использовать парольную аутентификацию — позаботьтесь о том, чтобы никто не мог авторизоваться с пустым паролем.
Для этого задайте директиву PermitEmptyPasswords:
PermitEmptyPasswords no
Протоколы SSh2 и SSh3
Как уже было сказано, sshd может работать с протоколами SSh2 и SSh3. При этом использование небезопасного SSh2 крайне не рекомендуется. Заставить sshd работать только с протоколом SSh3 можно так:
Protocol 2
Аутентификация на основе SSh3 RSA-ключей
Наиболее предпочтительным способом авторизации является аутентификация на основе SSh3 RSA-ключей. При таком способе пользователь генерирует на своей стороне пару ключей, из которой один ключ является секретным, а другой публичным. Публичный ключ копируется на сервер и служит для проверки идентичности пользователя. Более подробно про создание пары ключей и способы размещения их на сервере см. в описании SSH-клиента.
Включить аутентификацию по публичному ключу можно так:
PubkeyAuthentication yes
Сервер должен знать, где ему следует искать публичный ключ пользователя.
Для этого применяется специальный файл authorized_keys. Синтаксис его может быть следующим:
# Коментарии записываются только с новой строки # общий вид записей в файле authorized_keys # [опции] тип_ключа(ssh-rsa или ssh-dss) очень_длинная_строка_непонятная_простому_человеку [логин@хост] ssh-rsa AAAAB3Nza...LiPk== [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected] command="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== example.net permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss AAAAB5...21S== tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== [email protected]
Можно указать как один общий файл с ключами, так и по файлу на каждого пользователя. Последний способ является более удобным и безопасным, т. к. можно во-первых указывать разные комбинации ключей для каждого пользователя5), а во-вторых ограничить доступ к публичному ключу пользователя. Задать файл с ключами можно при помощи директивы AuthorizedKeysFile:
AuthorizedKeysFile %h/.
ssh/my_keys для схемы пользователь — файл
или
AuthorizedKeysFile /etc/ssh/authorized_keys
для схемы с общим файлом. По умолчанию SSH-клиент ищет ключи в файле ~/.ssh/authorized_keys .
Еще про безопасность
Дополнительные настройки
Пользователи и группы.
Если у вас на сервере «живет» много пользователей, а доступ через ssh вы хотите разрешить только нескольким из них — вы можете использовать директивы DenyUsers, AllowUsers, DenyGroups, и AllowGroups. Более подробно про эти директивы см. комментарии в примере sshd_config.
Опции определения состояния соединения
По умолчанию из способов определения состояния соединения включен только способ проверки TCP соединения — TCPKeepAlive, однако, sshd умеет определять состояния соединения и более удобными и безопасными способами.
Подробнее см. соответствующий раздел в примере sshd_config.
Производительность. MaxStartups
Перенаправление портов
Перенаправление X11
На сервере в файле /etc/ssh/sshd_config выставить параметр (по умолчанию включено):
ForwardX11 yes
На клиенте в файле /etc/ssh/ssh_config выставить параметры (по умолчанию выключено):
ForwardAgent yes ForwardX11 yes
Запускать на клиенте можно так ssh yurauname@serverip firefox . Или сначала заходим ssh yurauname@serverip потом запускаем, например sudo synaptic .
SFTP
В sshd по умолчанию встроен SFTP-сервер. Протокол SFTP (SSH File Transfer Protocol) — SSH-протокол для передачи файлов. Он предназначен для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения.
Как правило, в качестве базового протокола, обеспечивающего соединение, и используется протокол SSh3.
Для того чтобы включить поддержку SFTP добавьте в sshd_config строку
Subsystem sftp /usr/lib/openssh/sftp-server
По умолчанию поддержка SFTP включена.
Использование критериев. Директива Match
Настройка SSH-клиента
Наиболее безопасным считается вход по ключу, и в большинстве случаев на стороне сервера такая возможность включена, так что для её использования никаких прав суперпользователя не требуется. На клиентской машине генерируем ключ:
ssh-keygen -t rsa
Получаем предложение ввести пароль для защиты файла ключа (оказывается полезным при попадании файла в чужие руки). Если мы собираемся по SSH выполнять скрипты, то оставляем пустым.
Передаём публичный ключ на сервер командой
ssh-copy-id -i ~/.ssh/id_rsa.pub user@server
Всё, можно заходить.
Когда ssh работает на нестандартном порту:
ssh-copy-id -i ~/.ssh/id_rsa.pub "-p port user@server"
Если возникает ошибка:
Bad port 'umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys'
попробуйте взять параметры в кавычки:
ssh-copy-id '-i /home/user/.ssh/id_rsa.pub "-p port user@server"'
Удобно при подключени на удалённой системе пользоваться утилитой screen.
Настройка удаленной ssh-директории в Nautilus
Монтирование удаленной директории с помощью sshfs
Монтирование удаленного каталога в локальный каталог
sshfs [email protected]:/home/userdir ~/sshfsdir
Размонтирование
fusermount -u ~/sshsfdir
SSH aliases
При использовании нескольких серверов с различными параметрами доступа (нестандартный порт, длинное имя хоста, логин отличный от локального, и т.п.) порой утомительно вводить все настройки подключения каждый раз заново.
Для облегчения этого можно использовать aliases.
Настройки хранятся в ~/.ssh/config для одного пользователя и в /etc/ssh/ssh_config глобально для всех пользователей.
Пример конфига. Описано может быть множество серверов. Подробнее в man ssh_config (не путать с sshd_config)
Host AliasName # Произвольное имя хоста HostName 1.2.3.4 # Можно указывать как IP, так и hostname (если работает DNS) User YourUserName # Если пользователь не совпадает с локальным пользователем Port YourSSHPort # Если нестандартный порт
После этого можно подключаться к серверу командой
ssh AliasName
ssh-agent
Диагностика проблем подключения
ssh -vvv user@host
Расположение конфигурационных файлов можно узнать из
man ssh man sshd
1. Создание сертификата и экспорт открытого ключа, а также клиентская часть на Windows + Putty SC описано на сайте:
http://habrahabr.
ru/post/88540/
Описанное там дополнение Key Manager доступно только в старых версиях Firefox. Проверено на версии 3.5 для Windows.
Прямая ссылка на дополнение: https://addons.mozilla.org/ru/firefox/addon/key-manager/
2. Подготовка сервера. Вам необходимо убедиться что в конфигурации sshd разрешена аутентификация при помощи публичных ключей. Для этого необходимо в файле «sshd_config» указать значение параметра «PubkeyAuthentication» в «yes».
Затем в файл «~/.ssh/authorized_keys» добавляем наш публичный ключ полученный ранее (одной строкой). Обратите внимание, файл «.ssh/authorized_keys» находится в домашнем каталоге того пользователя, который потом будет логиниться по публичному ключу.
3. Клиентская часть на Linux. Потребуется пересборка пакета OpenSSH без параметров. Рекомендуется только указать префиксы каталогов, например –prefix=/usr. Также следует учесть, что файлы конфигов будут в /usr/etc.
Перед началом необходимы пакеты: opensc-lite-devel, zlib-devel, openssl-devel.
Устанавливаем драйвер смарт-карты.
Для удобства в конфиге ssh_config (не путать с sshd_config) указать путь к библиотеке pkcs:
PKCS11Provider=<путь к библиотеке>
4. На клиенте запускаем
ssh user@host
Если смарт-карта (токен) подключена, будет запрошен пароль и выполнен вход в сессию SSH.
Привычная комбинация клавиш Ctrl+S, используемая во многих редакторах для сохранения исправлений, при работе в терминале с ssh-cервером приведёт к выполнению команды XOFF что внешне напоминает зависание сессии. Однако это не так. Сервер продолжает принимать вводимые символы и команды, но не выводит это на экран. Что бы выйти из такого затруднительного положения достаточно применить комбинацию Ctrl+Q, тем самым включив режим XON обратно.
Ссылки
Эта статья не окончена. Пожалуйста, если вы располагаете соответствующими знаниями
и небольшим количеством свободного времени, попробуйте улучшить эту статью.
MadKox
Повышение безопасности SSH | Википедия серверов и хостинга
Возможность подключиться к серверу либо компьютеру, физически находясь на другом конце города, страны, земного шара, является неоспоримым благом. Однако, как это часто бывает, преимущества получают не только законные пользователи, но и злоумышленники. Удаленный доступ с помощью SSH подключения не стал исключением.
Что же представляет собой этот способ связи с сервером и как сделать подключение максимально безопасным?
Что собой являет SSH соединение
SSH (Secure shell) — сетевой протокол, предназначенный для получения безопасного удаленного доступа к операционной системе и управления ею.
В Linux системах подключение по защищенному протоколу осуществляется с помощью следующей команды:
ssh user_name@remote_host
Под удаленным хостом в данном случае подразумевается IP-адрес либо домен, к которому хотите подключиться.
Для входа на сервер система запросит ввести пароль авторизации. После успешного подключения вы получите доступ к управлению устройством через командную оболочку.
Для того, чтобы прервать соединение и вернуться к локальной сессии, достаточно ввести в консоли exit.
В случае использования операционной системы Windows, можно воспользоваться SSH-клиентом PuTTy, работа с которым описана в нашей статье.
Настройка параметров подключения к SSH
Необходимо понимать, что использование такого блага как ssh-соединение влечет за собой и риск подвергнуться хакерской атаке. Злоумышленники могут попытаться проникнуть на ваш удаленный сервер, используя логин и пароль. Чтобы свести вероятность успешной атаки к минимуму, воспользуемся доступными нам средствами, а именно — изменением настроек подключения.
Есть несколько основных параметров, настройка которых поможет сделать ваше подключение более безопасным.
На всякий случай создаем резервную копию конфигурационного файла с настройками:
cp /etc/ssh/sshd_config{,.
bak}
Приставка {,.bak} позволяет скопировать файл с указанным именем и расширением bak, которое присваивается резервным копиям.
Теперь через текстовый редактор, например, vim, emacs, nano, открываем файл /etc/ssh/sshd_config и вносим в него основные правки. В целях повышения безопасности SSH соединения нас интересуют следующие параметры:
- PermitRootLogin
- AllowUsers, AllowGroups
- DenyUsers, DenyGroups
- Port
- ListenAddress
- Login GraceTime
- ClientAliveInterval
- HostbasedAuthentication.
Дальше поговорим о том, какие значения необходимо установить для указанных выше параметров, чтобы усложнить злоумышленникам доступ к серверу.
PermitRootLogin
Этот параметр устанавливает разрешение на вход в систему как root пользователь. Для повышения безопасности соединения рекомендуется отключить такую возможность, т.е. изменить установленное в файле значение “Yes” на “No”:
PermitRootLogin no
При таких условиях выполнять команды с правами суперпользователя после входа на сервер можно будет с помощью функций su либо sudo.
AllowUsers, AllowGroups
Когда в системе создано много пользователей, то, согласно первоначальных настроек, каждый из них имеет возможность удаленного доступа по SSH. Чтобы разрешить доступ только для определенного круга лиц (и, соответственно, запретить его для всех остальных), существуют параметры AllowUsers и AllowGroups. Запись в конфигурационном файле имеет, соответственно, вид:
AllowUsers user1 user2 user3 AllowGroups group1 group2 group3
где через пробел перечислены имена пользователей и названия групп, которым разрешено подключение к серверу по SSH.
DenyUsers, DenyGroups
Когда пользователей в системе много и нужно предоставить удаленный доступ большинству из них, при этом запретив его отдельным лицам и группам, в sshd_config файле вносят правки в параметры DenyUsers, DenyGroups. Напротив этих параметров, аналогично примеру с AllowUsers, AllowGroups, перечисляем имена пользователей и групп, которым будет отказано в доступе на сервер по SSH.
DenyUsers user1 user2 DenyGroups group1 group2
В предыдущих пунктах речь шла о настройках, которые позволят распознать неавторизованного пользователя и запретить подключение. Однако злоумышленники часто используют метод подбора логина и пароля, пытаются попасть на сервер путем ввода ранее украденных данных.
Port
Чтобы усложнить задачу хакерам, стоит позаботиться о хорошей маскировки своего ssh-порта.
По умолчанию ssh-соединение осуществляться через 22-й порт. Чтобы порт для подключения не был так очевиден, смените порт SSH на любой другой, желательно наименее стандартный, например:
Port 22540
ListenAddress
Кроме того, что ssh-соединения настроено на определенном порте, подключение осуществляется на различных сетевых интерфейсах. Иными словами сервер слушает множество IP-адресов. Есть возможность указать в конфигурационном файле конкретные адреса интерфейсов для входа на сервер с помощью параметра ListenAddress.
Например:
ListenAddress 192.168.1.2
Login GraceTime
По умолчанию, при подключении к серверу по ssh у пользователя есть 2 минуты для ввода логина и пароля. Такого промежутка более чем достаточно, причем не только для авторизованного пользователя, но и для хакера. Поэтому время ожидания ввода этих данных стоит ограничить до 30-60 секунд, в зависимости от ваших предпочтений.
Login GraceTime 30
ClientAliveInterval
Этот параметр призван определить время бездействия пользователя, по истечении которого соединение автоматически разрывается. Период ожидания необходимо указать в секундах, например:
ClientAliveInterval 300
HostbasedAuthentication
Также стоит отключить авторизацию пользователя на основе хоста с помощью директивы:
HostbasedAuthentication no
Лучше воспользоваться аутентификацией на основе ключей.
Кроме перечисленных в конфигурационном файле настроек, защитить свое openSSH-соединение поможет хороший пароль, не связанный с персональными данными, но содержащий при этом большие и маленькие буквы, цифры и знаки. Сменить пароль на сервере можно множеством способов. Если не хотите составлять пароль самостоятельно, используйте генератор случайных паролей.
Закрытие порта SSH
Еще одной преградой для взлома вашего сервера является закрытие SSH-порта, или port knocking. Особенно актуально использовать данную технологию для серверов, не предназначенных для всеобщего доступа (например, серверы хранения конфиденциальных данных компании и т.п.).
Суть port knocking заключается в том, что изначально все порты сервера закрыты для внешних подключений. Открытие порта и возможность доступа к нему осуществляется за счет применения определенной последовательности стуков. Эта технология используется как дополнение к приведенным выше настройкам, применению паролей и ключей.
Механизм работы port knocking довольно прост. Вы устанавливаете на сервер демон knockd, настраиваете необходимую последовательность стуков в файле /etc/knockd.conf и получаете незамысловатый в использовании, но надежный на практике инструмент противодействия хакерам. Дело в том, что в интернет-пространстве насчитывается около 60000 свободных портов, через которые можно осуществить SSH-подключение. Для доступа к порту используют, как правило, последовательность из 3 стуков. Это означает, что подобрать правильный набор портов случайным образом или как-либо их просчитать становится очень сложно, а это именно то, чего мы добиваемся.
Итак, устанавливаем knockd демон:
sudo apt-get install knockd — для Ubuntu
sudo aptitude install knockd — для Debian
Теперь в конфигурационном файле /etc/knockd.conf настраиваем последовательность стуков, которая будет открывать наш порт. Для этого в секции sequence перечисляем через запятую без пробела номера портов, например:
sequence= 6240,7000,8490
Когда вы пытаетесь “достучаться” до порта, передача данных осуществляется по протоколу TCP. Однако, для повышения уровня безопасности соединения можно добавить другие протоколы, например, UDP:
sequence= 6240,7000:udp,8490
Пакеты TCP, которые приходят на сервер, требуют различных действий со стороны системы. Чтобы избежать ненужной нагрузки и отфильтровать лишнее, используют параметр TCPFlags, который также прописывают в файле /etc/knockd.conf:
tcpflags= syn
Флаг SYN означает запрос на соединение. Т.е. демон knockd будет сканировать только те приходящие пакеты, которые содержат запрос на соединение с сервером.
Выше мы говорили о том, что SSH-подключение осуществляется на различных сетевых интерфейсах. По умолчанию, knockd рассчитан на работу с eth0. Чтобы дать возможность демону контролировать другие интерфейсы, например, eth2, в файл /etc/knockd.conf добавим строчку:
Interface=eth2
Чтобы “постучать” в порт, нужно определенное время. Если вы точно знаете, какую последовательность требуется ввести, достаточно 15-30 секунд. Именно этим пределом стоит ограничить максимальное время, необходимое для завершения последовательности стуков:
seq_timeout= 20
Согласно примеру, по истечении 20 секунд система считывает введенную информацию. Соответственно, если правильная последовательность не была завершена до истечения этого времени, вам будет отказано в доступе и порт не откроется.
Поскольку логин и пароль авторизации могут быть похищены злоумышленниками, будет не лишним по аналогии с seq_timeout установить ограничение на время их ввода:
cmd_timeout= 30
Соответственно, через 30 секунд порт закроется, если данные для авторизации не будут успешно введены.
Мы уже настроили последовательность стуков для открытия нужного SSH порта, указали ограничения по времени. Однако, чтобы корректно работать, knockd должен знать, какие действия ему необходимо выполнить, если стуки были правильными, а также, если в доступе нужно отказать.
Для этого существуют команды start_command и stop_command, соответственно.
Если последовательность стуков верна, демон должен открыть порт SSH, через который необходимо осуществить подключение. Для этого в конфигурационном файле /etc/knockd.conf прописываем команду для start_command:
start_command= /usr/sbin/iptables -A INPUT -s %IP% -p tcp --dport 22716 -j ACCEPT
В случае, когда стуки были неправильными либо пользователь не успел ввести ее полностью до истечения отведенного времени, knockd делает порт недоступным (невидимым).
stop_command= /usr/sbin/iptables -D INPUT -s %IP% -p tcp --dport 22716 -j ACCEPT
Фактически, мы настраиваем правила iptables (брандмауэра), где:
— INPUT означает входящий пакет
— A и D — добавление и удаление правила, соответственно
— s — IP источника пакета
— %IP% — адрес, с которого идет запрос на открытие порта
— p — протокол (в данном случае tcp)
— dport — SSH-порт, который мы хотим открыть
— j — ключ, указывающий на действие над пакетом (accept — принять)
Когда все настроено и готово к работе, запускаем демон в фоновом режиме с помощью команды knockd -d.
Теперь мы можем получить удаленный доступ к серверу по SSH, указав в консоли правильную последовательность портов через пробел. После этого вы увидите открывшийся порт и предложение ввести пароль своей учетной записи:
knock адрес_сервера 6240 7000:udp 8490 ssh адрес_сайта -p 22716 -o ConnectTimeout=30 Password:
Как видите, на ввод данных дается 30 секунд.
Адрес сервера, к которому вы подключаетесь, может быть выражен двумя способами:
— IP-адресом
— хостнеймом.
В первом случае запрос на подключение будет выглядеть следующим образом:
ssh -p 22716 [email protected]
Если подключение идет к серверу через hostname, запрос имеет следующий вид:
ssh -p 22716 [email protected]
Часто доступность системы для хакеров связана с уязвимостью самой операционной системы. Разработчики регулярно проверяют наличие слабых мест в своем продукте и выпускают более совершенные версия, закрывая подобные лазейки для злоумышленников. Поэтому не забывайте своевременно обновлять ПО и утилиты.
Правильная настройка SSH на Ubuntu Server
Сегодня в статье поговорим о правильной настройке SSH на Ubuntu Server 18.04 LTS.
Практически сразу после запуска сервера на порту 22 наблюдается бурная активность ботов-брутфорсчиков. Для того чтобы защититься от их атак и снизить нагрузку на сервер первым делом устанавливаем и настраиваем Fail2Ban для SSH.
Далее переходим к настройке конфигурационного файла ssh
Настройка sshd_config
Открываем в терминале конфигурационный файл SSH
sudo nano /etc/ssh/sshd_configПервое что нужно сделать, так это сменить порт ssh с 22 на любой другой. Ищем строку Port 22 и заменяем её например на Port 2222
Port 2222Порты 21, 22, 80, 139, 443, 1194, 3306, 8080 — советую не использовать.
Второе — ограничим тип адресов для подключения (IPv6 либо IPv4). Если у вас на сервере не используется IPv6, то дописываем в файл:
AddressFamily inetТретье — запретим root авторизацию
PermitRootLogin noЧетвертое — разрешаем подключение только под определенным логином:
AllowUsers userгде список пользователей пишется через пробел.
Пятое — запрещаем попытку входа с пустым паролем:
PermitEmptyPasswords noШестое — настраиваем вход по ключу.
PubkeyAuthentication yesДалее на машине с который будете подключаться к серверу набираем следующие команды:
ssh-keygen Будет предложено указать место размещения пары ключей, парольная фраза на них и их название. Можете оставить все как есть просто нажимая Enter.
Далее копируем наш публичный ключ на сервер:
ssh-copy-id ваш_user@IP_сервера.ru
Проверьте, что можете зайти на сервер по ключу, без ввода пароля!!!
ssh ваш_user@IP_сервера.ruСедьмое — запрещаем вход по паролю
PasswordAuthentication noНе забываем до выполнения этого пункта настроить вход по ключу, иначе можете остаться без сервера!!!
Восьмое — сохраняем правки и перезапускаем ssh демон:
sudo /etc/init.d/ssh restartСоединение по SSH с сервером
Теперь можем перезайти с новыми параметрами на ваш сервер. В терминале набираем:
ssh -p 2222 user@sshserverНа всякий случай посмотрим открытые порты:
netstat -tupln | grep LISTENВы должны увидеть порт 2222
В случае ошибок полезно бывает смотреть лог /var/log/secure либо использовать опции -v, -vv или -vvv для вывода детального лога соединения:
ssh -vvv user@sshserverЕсли есть вопросы, то пишем в комментариях.
Также можете помочь проекту, заранее всем СПАСИБО!!!
.
RSS
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
0
0
vote
Рейтинг статьи
Настройка сервера SSH (теория и практика) — Статьи по Linux и Open Source (nixp.ru)
Аутентификация пользователя по его публичному ключу.
Аутентификация удаленного пользователя по ключу идентична проверке ключа хоста (с посылкой рандомной строки) за тем исключением, что проверяется не адрес клиентской машины, а ключ клиента и имя пользователя. Данному пользователю на сервере может соответствовать его публичный ключ, тогда клиент, имея секретный ключ сможет заходить на сервер без пароля. Механизм работы я только что описал, поэтому сразу же расскажу, каким образом аутентифицировать пользователей по ключу (предполагается, что используется клиент и сервер openssh):
Для генерации пары ключей используйте программу ssh-keygen. Для указания типа ключа укажите ssh-keygen -t {RSA DSA}, например, ssh-keygen -t rsa создаст пару ключей RSA длиной 1024 бита. Для указания файла, в котором следует сохранить ключи, можно использовать опцию -f (традиционно используются файлы $HOME/.ssh/id_rsa и $HOME/.ssh/id_dsa для ключей rsa и dsa соответственно), для указания длины ключа в битах используйте опцию -b:
ssh-keygen -t rsa -b 2048 -f $HOME/.ssh/id_rsa
В результате работы программа запросит ввод пароля для шифрования секретного ключа, чтобы исключить использование его при попадании к посторонним лицам, не знающим пароля (пароль желательно выбирать не короче 10-и символов). После этого вам будет необходимо вводить данный пароль каждый раз при использовании секретного ключа (далее я расскажу, как избежать этого при помощи программы ssh-agent). После работы ssh-keygen создается пара ключей: один секретный (зашифрованный введенным паролем), а другой публичный с расширением .pub (id_rsa.pub). Публичный ключ вам необходимо будет скопировать в домашнюю директорию сервера $HOME/.ssh/authorized_keys. После этого сервер будет знать ключ данного пользователя и сможет аутентифицировать вас без пароля. Файл authorized_keys может содержать несколько публичных ключей, допустимых для данного пользователя: просто поместите их в данный файл по порядку. После этих операций вы сможете входить, имея секретный ключ, на сервер, где размещен ваш публичный ключ, причем под тем пользователем, в чьем домашнем каталоге данный ключ находится. Пароля удаленного пользователя не требуется, необходимо только знать пароль расшифровки секретного ключа. Для переноса своего публичного ключа на сервер надо использовать только безопасные источники, иначе ваш ключ могут подменить. Для переноса публичного ключа клиента служит программа ssh-copy-id. Для начала необходимо сделать следующее:
# ssh-copy-id -i public_key_file user@machine
После соединения с севером machine и передачей имени пользователя user (необходимо указывать, если удаленное имя отличается от локального) происходит парольная аутентификация заданного пользователя(или текущего) на удаленной машине, затем происходит копирование ключа public_key_file (или $HOME/.ssh/identity.pub, если имя файла не указано) на сервер в $HOME/.ssh/authorized_keys. После этого можно входить на сервер, не используя пароль пользователя. При выполнении данной операции учтите, что вы должны скопировать на удаленную машину ПУБЛИЧНЫЙ ключ, иначе все будет очень печально (думаю, ясно, почему).
Обычная парольная аутентификация.
Тут можно отметить только одно: в любом случае вначале идет обмен асимметрическими ключами, и хеш пароля передается в зашифрованном виде. Парольная аутентификация используется наиболее часто, но, честно говоря, ssh предлагает более удобные методы аутентификации, и пользоваться ими IMHO можно, если к ssh есть все заплатки. И, конечно же, протокол версии 1 необходимо вырубить вообще. Итак, начинаем настройку… Я заметил, что большинство администраторов просто оставляет конфиги клиента и сервера по умолчанию, чтобы руки не марать. Но это неправильно: в разных системах эти конфиги различаются очень существенно, и это приводит к неразберихе и непониманию работы сервера, что создает дополнительную угрозу безопасности (свой сервак — потемки). Для этого я решил описать файлы конфигурации ssh на примерах ssh_config и sshd.conf для клиента и сервера соответственно. Для конфигурации клиента используется файл $HOME/.ssh/config или /etc/ssh/ssh_config (для всей системы). Файл имеет следующий формат: определение адреса хоста и параметры для него. В адресе можно использовать обычные шаблоны * и ?, все имена параметров и их значения должны быть набраны в том же регистре, что и в примере (иначе параметр воспринят не будет). Вот пример ssh_config, который содержит наиболее полезные опции (на самом деле описывать некоторые параметры конфигурации ssh не имеет смысла, т.к. употребляются они очень редко):
# Определение хоста, в данном случае включает все хосты домена test.ru, можно # использовать одиночный символ * чтобы указать параметры доступа к любому хосту Host *.test.ru # Эта опция определяет, будет ли ssh использовать передачу данных от удаленного # X сервера через свой безопасный канал. Далее будет описано, каким образом # организуются безопасные туннели через ssh. Данная возможность позволяет # защищать по идее небезопасные протоколы(X, pop, smtp, ftp) шифрованием ssh. По # умолчанию данная опция no ForwardX11 yes # Список предпочтительных методов аутентификации через ssh версии 2. Первым # стоит самый предпочтительный протокол, думаю, значения данного параметра ясны PreferredAuthentications hostbased,publickey,keyboard-interactive # Этот параметр определяет, будет ли производится стандартная парольная проверка # По умолчанию yes PasswordAuthentication yes # Число попыток ввода пароля перед тем, как клиент отсоединяется от сервера. По # умолчанию пароль можно вводить трижды NumberOfPasswordPrompts 3 # Список допустимых пользователей для данного сервера. Можно применять два # формата: список пользователей, разделенных пробелом, и список пользователей и # хостов, разделенных пробелом(USER@HOST - разрешает данному пользователю доступ # только с данного адреса). Можно использовать выражения * и ?. Подобное же # назначение имеют опции AllowGroups, DenyUsers и DenyGroups(для групп нельзя # указывать адрес клиента) AllowUsers *@*.test.ru DenyUsers xakep lamer DenyGroups x* # Использование ssh(2 версия) аутентификации через rhosts и RSA ключи. По # умолчанию no. HostbasedAuthentication yes # Будет ли клиент пытаться работать по rsh, если ssh недоступен или по каким-то # причинам работает неправильно. По умолчанию no FallBackToRsh no # Используем ли rsh. По умолчанию no UseRsh no # Режим скрипта, когда не спрашиваются пароли с терминала. По умолчанию no BatchMode no # Дополнительно проверяется ключ хоста удаленной машины в # known_hosts, что исключает подмену ip. По умолчанию yes. CheckHostIP yes # Данный параметр означает, будет ли клиент доверять полученным от серверов # ключам. Параметр может принимать следующие значения: yes - ключи никогда # автоматически не помещаются в known_hosts, ask - ключ может быть помещен в # known_hosts только после подтверждения пользователя, no - все ключи # автоматически размещаются в known_hosts(небезопасно). По умолчанию ask. StrictHostKeyChecking ask # Следующие параметры определяют секретные ключи ssh различных форматов: # rsa и dsa IdentityFile $HOME/.ssh/id_rsa IdentityFile $HOME/.ssh/id_dsa # Порт, на удаленной машине используемый ssh. По умолчанию 22 Port 22 # Версии протоколов, используемые клиентом в порядке убывания приоритета. Protocol 2 # Протокол шифрования для версии 1 протокола ssh Cipher 3des # Возможные протоколы шифрования в порядке убывания приоритета для протокола # версии 2 Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc # Значение escape-символа, сигнализирующего, что идущие за ним символы # необходимо воспринимать специальным образом(например ~. вызовет немедленное # отключение клиента от сервера) при передаче двоичных данных необходимо # установить этот параметр в none, что выключает escape последовательности. По # умолчанию ~ EscapeChar ~ # Управление работой компрессии зашифрованнного трафика. Полезный параметр для # медленных сетей, т.к. зашифрованные данные обычно увеличиваются в размере за # счет фиксированной длины ключа. Компрессия позволяет уменьшить количество # данных, передаваемых через сеть, но увеличит время работы самого протокола. # Так что включать этот параметр желательно на медленных соединениях. По # умолчанию no. Compression yes # Управляет посылкой сообщений о доступности клиента серверу, что позволяет # нормально разорвать соединение, если произошла неполадка в сети или иная, # приведшая к разрыва соединения. Если связь плохая, то лучше эту опцию # отключить, чтобы дисконнект не происходил после каждой ошибки сети. По # умолчанию yes. KeepAlive yes
Я думаю, что в данном примере все объяснено достаточно подробно и скажу только вот что: в большинстве случаев опции по умолчанию работают неплохо, необходимо только отключить поддержку ssh версии 1 и настроить необходимые методы аутентификации (кроме парольной) и указать пути доступа к ключам. На этом закончим с настройкой клиента и настроим сервер. Файл конфигурации сервера sshd находится в /etc/ssh/sshd_config, и многие его параметры совпадают с аналогичными в ssh_config, но здесь нет определений хостов, как это было в ssh_config. Я все же приведу пример sshd_config, чтобы далее не возникало вопросов:
# Номер порта и версия протокола Port 22 Protocol 2
# Адреса, на которых слушает сервер, можно также указывать # порт (server.test.ru:2022), но назначение ssh нестандартного порта # нецелесообразно, т.к. заинтересует потенциальных взломщиков("А чего это там # они прячут?") ListenAddress server.test.ru
# Ключ сервера для протокола версии 1 HostKey /etc/ssh/ssh_host_key # Ключи rsa и dsa для ssh версии 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key
# Данные значения определяют длину ключа сервера и его время жизни для # использования ssh версии 1(данный ключ будет заново генерироваться через # заданное время) #KeyRegenerationInterval 3600 #ServerKeyBits 768
# Далее определяем методы аутентификации для данного сервера и ее параметры
# Сервер отсоединяется по происшествии данного времени в секундах, если клиент # не проходит аутентификацию LoginGraceTime 600 # Разрешаем заходить по ssh руту. Долгое время эта тема обсуждалась на форуме, # но я думаю все же, что со внутренней сети рут может заходить и по ssh (для # этого надо настроить должным образом iptables). Также можно запретить руту # входить по паролю: without-password, разрешая вход только по публичному ключу PermitRootLogin yes # Проверка sshd прав доступа и владельцев домашних каталогов. Полезно для тех # пользователей, что дают права всему 0777. Хотя таких болванов лучше держать на # расстоянии от сервера(лучше всего это делать бревном, подвешенным в серверной # к потолку, чтобы придать нежеланному гостю должное ускорение, и не забудьте # оббить конец бревна какой-нибудь железкой, иначе бревна придется менять # слишком часто ;) StrictModes yes
# Аутентификация через RSA (версия 1) RSAAuthentication yes # Аутентификация пользователя по ключу (версия 2) PubkeyAuthentication yes # Определяет публичный ключ пользователя для аутентификации по ключу. Можно # применять шаблоны: %u - имя пользователя, %h - домашний каталог пользователя. AuthorizedKeysFile .ssh/authorized_keys
# Не используем аутентификацию rhosts RhostsAuthentication no # Можно также игнорировать rhosts и shosts при hostbased autentification, # используя только known_hosts файл. #IgnoreRhosts yes # Используем ли аутентификацию через known_hosts совместно с .rhosts или # .shosts. Опция действительна только для протокола версии 1. RhostsRSAAuthentication no # То же самое, что и предыдущее только для версии 2 HostbasedAuthentication yes # Если нет доверия к known_hosts, то их можно не использовать при hostbased # autentification. По умолчанию no IgnoreUserKnownHosts no
# Чтобы запретить посылку хешей паролей через туннель ssh задайте значение # данной опции no. По умолчанию аутентификация по паролю разрешена PasswordAuthentication yes # Можно также разрешить пустые пароли, но это полный отстой, т.к. это огромная # дыра на сервере, через которую можно наделать много гадостей! Поэтому должно # быть no (по умолчанию) PermitEmptyPasswords no
# Аутентификация через механизм PAM. PAMAuthenticationViaKbdInt no
# Передача протокола иксов через туннель ssh X11Forwarding yes # Используем в качестве x-сервера данный, т.е. клиент, запуская у себя x-клиента # будет фактически использовать наш сервер, но все данные от сервера к клиенту # будут шифроваться, что есть хорошо! X11UseLocalhost yes # При логине пользователя выводим /etc/motd: в некоторых системах это отменено в # целях безопасности PrintMotd yes # Сообщаем пользователю время и место последнего логина, ситуация, аналогичная # предыдущей PrintLastLog yes # Посылать клиенту сообщения о доступности KeepAlive yes # Максимальное число возможных соединений, где не произошло аутентификации. Если # клиентов, не прошедших аутентификацию больше, то новые соединения не будут # обрабатываться MaxStartups 10 # Путь к файлу, который будет отображаться при входе клиента ДО аутентификации Banner /etc/ssh_message # Проверка соответствия ip адреса клиента и его символического имени в backzone, # затем снова сравнение имени с ip адресом. Таким образом (извращенным) # проверяется подлинность ip, но метод этот достаточно тормозной и по умолчанию # он отключен VerifyReverseMapping no
# Новые системы, работающие через ssh. В данном примере определяется # "безопасный" ftp сервер - sftp, аналогичный доступ пользователя, но с # возможностью передачи файлов(т.е. пользователь получает доступ ко всем своим # файлам и нет возможности настройки разрешений и виртуальных пользователей, # как, например в proftpd). По сути дела подсистемы ssh могут обеспечивать # прохождение других протоколов по сети, но под "крылышком" ssh. Например, для # sftp сервера есть одноименный sftp клиент. Его интерфейс полностью идентичен # оригинальному ftp, но с одним отличием: происходит та же самая аутентификация # пользователя на удаленном сервере(методами ssh), но вместо оболочки с # пользователем взаимодействует подсистема, в данном случае sftp. Subsystem sftp /usr/lib/ssh/sftp-server
Ну вот, вроде бы все настроено! Теперь я бы хотел поговорить о некоторых фичах, работающих в ssh. Для начала я бы хотел рассказать о туннелях. SSH имеет встроенную возможность передавать данные с локального порта на удаленный, используя сетевой туннель, причем данные, передаваемые через данный туннель будут шифроваться. То есть происходит аутентификация на удаленной системе, а затем начинается перенаправление трафика через туннель. Таким образом, можно перенаправлять любой трафик, а протокол иксов может работать в интерактивном режиме, для этого необходимо включить соответствующие опции в файлах конфигурации сервера и клиента(это было описано ранее). Для других же портов необходимо вызывать ssh с параметром -L{LOCAL_PORT}:{LOCAL_ADDRESS}:{REMOTE_PORT}:
# ssh -L10101:localhost:101 server.test.ru
Такой туннель довольно быстро умирает, т.к. сервер автоматически убивает «ленивых» клиентов. Поэтому можно применить метод, который позволяет устанавливать произвольное время удержания туннеля: выполнить sleep на удаленном сервере:
# ssh -f -L10101:loclahost:101 server.test.ru sleep 100
Данная команда держит туннель 100 секунд, чего достаточно для любого соединения. И еще одна вещь: когда по туннелю передаются данные, то он не уничтожается, что хорошо для реализации безопасного ftp-, smtp- и pop3-протоколов (впрочем, sftp-сервер имеется уже и в поставке openssh, применение его не должно вызвать затруднений sftp [user@]hostname, т.к. фактически это особая реализация ssh протокола и механизм работы sftp абсолютно идентичен механизму ssh). Чтобы отключить перенаправление портов, необходимо установить опцию sshd AllowTcpForwarding в no. Использование длительной задержки ssh-туннеля несколько уменьшает безопасность, т.к. во время ожидания злоумышленник имеет больше шансов на атаку (но механизм ssh версии 2 позволяет избежать подобной ситуации подписыванием передаваемых сообщений).
Вот что сделал бы я для безопасного ssh. Для начала создал бы rsa-ключ длиной 4096 бит:
# ssh-keygen -t rsa -b 4096
Затем скопировал бы данный ключ с помощью флешки или ssh-copy-id на удаленный сервер(а):
# ssh-copy-id -i $HOME/.ssh/id_rsa remote_host
После этого запретил бы парольную и всякую host-based аутентификацию в sshd_config:
IgnoreHosts yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes HostbasedAutentification no PasswordAuthentication no PermitEmptyPasswords no UseLogin no PermitRootLogin without-password
И отключим потокол версии 1 (по умолчанию Protocol 2,1 и сервер падает к ssh 1, при неудаче ssh 2):
Protocol 2
Ну, вот, теперь, чтобы зайти на сервак по ssh надо ввести нехилый (а он должен быть нехилый!) пароль секретного ключа. Немножко неудобно, не правда ли? Можно хранить пароль для секретного ключа в памяти на протяжении работы некоторой программы (например, bash) и при запросе его ssh клиентом доставать из памяти. Для этой цели служит программа ssh-agent (агент аутентификации ssh). Агент запускает необходимую программу и ждет добавления новых секретных ключей (ssh-agent хранит расшифрованные секретные ключи). Для этой цели есть другая программа — ssh-add, которая добавляет в агент ключи $HOME/.ssh/id_rsa, id_dsa, identity. Если необходимо добавить другие ключи, то надо запустить ssh-add с именем файла: ssh-add filename. Учтите, что при добавлении ключа в агент ssh-add вам все равно необходимо ввести пароль для его расшифровки, но пока агент находится в памяти (пока вызванная им программа не завершилась), вводить пароль секретного ключа не надо: ключ берется из ssh-agent. Причем контакт с ssh-agent может устанавливать только программа, запущенная им (и все ее дочерние процессы), т.к. устанавливаются переменные окружения. Обычный метод запуска ssh-agent:
# ssh-agent bash # ssh-add Enter passphrase for '.ssh/id_rsa': Enter passphrase for '.ssh/id_dsa': .ssh/identity : No such file or directory
После завершения работы оболочки ssh-agent завершается, а ключи удаляются из памяти. Ну, и наконец можно разрешить доступ определенных пользователей с определенных машин. Это делается полем AllowUsers в sshd_config или правилами iptables. Думаю, этого достаточно для нормальной и безопасной работы на удаленном сервере через ssh. Особо мнительные могут запретить доступ рута по ssh (PermitRootLogin no) и делегировать часть его прав с помощью sudo. Ну, и использовать протокол версии 2 (такие плюсы, как алгоритм вычисления симметрического ключа на основании пары асимметрических, и подписывание сообщений, передаваемых по сети, а также 2 версия протокола ssh быстрее первой). Существует множество клиентов ssh, работающих на разных ОС. Для Windows выделю putty, а для Mac — NiftyTelnet 1.1 SSH.
Хороший список ссылок по ssh находится на www.heimhardt.com, полезным мне показался также сайт www.openssh.com, ну, и есть документация по ssh (правда, версии 1) на сайте www.opennet.ru.
Настройка ssh Linux — синтаксис и примеры
ssh (Secure Shell — «безопасная оболочка») – это протокол прикладного уровня в операционной системе «Линукс», который обеспечивает удаленный доступ управления персональным компьютером. Чаще всего такой протокол используется при удаленном управлении серверами с помощью терминала.
Если вы являетесь администратором на нескольких серверах, обладаете обширными знаниями в области веб-программирования, команда SSH должна быть знакома. Для осуществления поставленных задач в системе «Линукс» применяется сервер, установленный на машине, и клиент, из которого к ней подключаются.
Утилита ssh отличается широким функционалом, дает пользователю большие возможности. С помощью утилиты можно подключиться к серверу, а также передавать файлы, выполнять скрипты удаленным способом, управлять сервером без предварительного ввода пароля.
Синтаксис
Рассмотрим синтаксис команды.
ssh [опция] [пользователь]@[название хоста] [команда]
Стоит отметить, что утилита ssh способна работать с помощью двух версий протокола, они так и называются протокол 1 и протокол 2. Второй вариант является наилучшим, так как поддерживает значительно больше способов шифрования, а также аутентификаций. Именно поэтому протокол 2 применяется пользователями чаще всего.
Основные опции:
- «g» — для разрешения удаленной машине пользоваться определенным локальным портом.
- «l» — для изменения/введения имя пользователя в определенной системе.
- «f» — аргумент переводит режим работы в фоновый.
- «n» — для перенаправления классического вывода.
- «p» — для изменения/введения данных о локальном порту SSH, используемом на удаленной машине.
- «q» — для исключения вероятности показа сообщений о возникающих ошибках.
- «v» — для включения специального режима отладки.
- «x» — для отключения перенаправления X11.
- «X» — для включения перенаправления Х11.
- «C» — для включения сжатия.
Представленный выше список является неполным. На самом деле команда ssh поддерживает в разы больше опций, а описанные варианты используются чаще всего. Стоит заметить, что большинство настроек можно водить с использованием файла «ssh/config».
Настройка
Для осуществления поставленной перед пользователем задачи первоначально требуется обратиться к файлу «/etc/ssh/sshd_config». Здесь имеется множество настроек, большинство из которых применяются редко. Именно поэтому рекомендуется рассмотреть те, которые пользователи вводят чаще всего.
Строка Port
Утилита работает согласно стандартным установкам на основе порта 22. Это поведение не является безопасным, так как мошенникам известен этот порт. Они могут организовать атаку Bruteforce, чтобы перебить имеющийся пароль. Требуемый порт задается с помощью строки «Port 22». Потребуется в обязательном порядке изменить показатели порта на необходимые вам данные.
Строка — Protocol 2,1
На сервере команда ssh согласно стандартным установкам используются две версии протоколов. Они предназначены для совмещения. К примеру, если потребуется использование только второго протокола, потребуется раскомментировать (удалить #) строку «Protocol 2,1» и убрать цифру 1.
Запрет входа root через ssh
В команде ssh согласно стандартным установкам разрешается Root-доступ. Данное поведение также небезопасно. Именно поэтому пользователю потребуется обязательно раскомментировать строку:
PermitRootLogin no
Если в конфиге нет строчки PermitRootLogin no, необходимо довать ее в конец файла.
Вход только одному пользователю
В файле конфигурации sshd_config можно добавить две директивы:
- Allowusers;
- AllowGroups.
Они позволяют разрешить пользоваться ssh только конкретным пользователям или группам.
AllowUsers имя пользователя1, имя пользователя2
AllowGroups группа1, группа2
Особенности выполнения приложений Х11
Не каждый современный пользователь знает, что утилиту SSH можно применить для полноценного запуска приложений Х11. Чтобы появилась возможность использования такой функции, потребуется разрешить ее со стороны сервера. Для этих целей необходимо ввести:
X11Forwarding yes
Для вступления изменений, внесенных в утилиту ssh, необходим обязательный перезапуск сервиса. Для этого потребуется ввести специальную команду:
service sshd restart
Или можно перезагрузить всю машину:
reboot
Примеры
Существует большое количество методов использования утилиты. Большинство из них неизвестны современному пользователю операционной системы Линукс.
Рассмотрим подключение к серверу.
При присоединении с использованием утилиты в командной строке потребуется ввести:
ssh user@imya-servera
Например, нам надо подключиться к компьютеру в локальной сети debian, под пользователем slon.
ssh slon@debian
ВАЖНО! Вместо доменного имени компьютера в сети можно написать IP-адрес.
Все современные пользователи первоначально присоединяются к удаленной хосту (компьютеру). Только после этого они вводят требуемые команды. Утилита ssh дает возможность выполнить необходимую задачу без обязательного запуска терминала на удаленной машине.
Предположим нам надо запустить команду top на удаленном компьютере.
ssh slon@debian top
К примеру, требуется запустить скрипт bash на удаленном компьютере. Сам файл bash.sh находится на локальном компьютере . Для этих целей необходимо провести перенаправление ввода bash.
ssh slon@debian 'bash -s'< bash.sh
С использованием утилиты пользователю предоставляется возможность сохранить бекап локального диска на удаленной серверной машине. Для этих целей нужно перенаправлять вывод dd с использованием оператора перенаправления. Далее вывод dd сохраняется в файле copiadiska.img.
sudo dd if=/dev/sdb | ssh [email protected] 'dd of=copiadiska.img'
Для восстановления прежнего состояния локального диска используется созданная ранее копия. Для этого в командной строке нужно ввести:
ssh [email protected] 'dd if=copiadiska.img' | dd of=/dev/sdb»
Стоит отметить, что в данном случае «/dev/sdb» — это название вашего жесткого диска.
При использовании команды ssh для входа в удаленный сервер нередко требуется пароль. Это создает дополнительные неудобства, но дает возможность обезопасить вас от злоумышленников. Несмотря на защиту, пароль можно подобрать.
Наиболее надежным методом аутентификации является использование нескольких ключей RSA. Один из них хранится на ПК, а второй является публичным. Он применяется пользователем при авторизации.
Это поведение весьма просто настроить. Изначально необходимо задать ключ. Для этого потребуется ввести:
ssh-keygen -t rsa
При создании ключа пользователю необходимо ответить на определённый перечень вопросов. Если вы желаете присоединиться к удаленной машине без обязательного введения пароля, в области «Passphare» нужно оставить пустое место.
Далее ключ отправляется на удаленную машину, вводится:
ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]
После этого ключ будет сохранен. Если попробовать присоединиться к серверу повторно, вы увидите, что введение пароля уже не требуется.
Стоит отметить, размещать пароли в обыденных текстовых файлах не стоит. Ими могут воспользоваться злоумышленники Но если это потребуется, такой вариант возможен. Чтобы сохранить пароль, необходимо воспользоваться оператором, используемым при перенаправлении Bash. Введите в командной строке:
ssh [email protected] < localnyi_file
При запуске команды ssh на экране монитора нередко всплывает приветствие. Допускается его изменение. За такую функцию отвечает специальный файл «/etc/issue». Вам потребуется просто открыть данный файл и указать необходимо приветствие. Для этого вводится команда:
nano /etc/issue
В некоторых случаях пользователю ОС Линукс может потребоваться информация о неудачных попытках подключения к утилите. Вы можете посмотреть IP-адреса, с которых совершалось данное действие.
Все запросы о входах концентрируются в «/var/log/secure».
cat /var/log/secure
Чтобы отфильтровывать информацию в терминале по запросу «Failed password» необходимо добавит grep
cat /var/log/secure | grep Failed password
Нередко пользователям требуется запустить определенное приложение с графической оболочкой на удаленном компьютере.
Для осуществления поставленной задачи не нужно использовать VNC, достаточно применить команду ssh. Программа запустится со стороны удаленной машины, пользователю транслируется лишь окно, в котором можно увидеть все, что ему необходимо.
Стоит отметить, что все получаемые данные могут шифроваться. Чтобы такая опция заработала, потребуется включить поддержку со стороны удаленного сервера. Далее выполняется команда, позволяющая загрузить графическую программу. Для этого потребуется ввести в командную строку «ssh -XC user@remotehost «eclipse»».
Нередко при использовании нестабильного соединения с сетью возможно возникновение сбоев в работе утилиты. Если соединение случайным образом было разорвано, потребуется принудительное завершение сессии. Для активации поддержки необходимо добавить в файл:
EscapeChar
Теперь можно завершить сессию простой командой:
~
В завершении можно сказать, что утилита ssh имеет существенно больший функционал, чем это кажется с первого взгляда. Пользоваться такой командой можно как при программировании, так и в повседневной работе.
11.4.2. Настройка и использование SSH. Linux: Полное руководство
11.4.2. Настройка и использование SSH
Что такое SSH
SSH (Secure Shell — защищенная оболочка) — это протокол, обеспечивающий защищенную передачу данных. SSH использует криптографию открытого ключа для шифрования соединения между двумя машинами, а также для опознавания (аутентификации) пользователей. Протокол SSH можно использовать для безопасной регистрации на удаленном сервере или копирования данных между двумя машинами. Ом позволяет предотвращать атаки способом присоединения посередине (session hijacking) и обмана сервера имен (DNS spoofing).
Протокол SSH поддерживает следующие алгоритмы шифрования:
? BlowFish — 64-разрядная схема шифрования. Этот алгоритм часто используется для высокоскоростного шифрования данных больших объемов.
? Тройной DES (Data Encryption Standard) — довольно старый стандарт шифрования данных, который в наше время рекомендуется использовать только для несекретных данных.
? IDEA (International Data Encryption Algorithm) — международный алгоритм шифрования информации. Этот алгоритм работает со 128-разрядным ключом и поэтому он более защищен, чем BlowFish и DES.
? RSA (Rivest-Shamir-Adelman algorithm) — алгоритм Ривеста-Шамира-Адельмана. Представляет собой схему шифрования с открытым и секретным ключами.
Поддержка нескольких алгоритмов шифрования позволяет обеспечивать наибольшую безопасность, так как в случае обнаружения уязвимости в одном алгоритме SSH переориентируется на использование других алгоритмов.
На данный момент существует две версии протокола SSH:
? Протокол SSH версия 1. У каждого узла есть свой RSA-ключ (обычно 1024 бит), который используется для идентификации узла. Этот ключ еще называется открытым. Дополнительно, при запуске демона, генерируется еще один RSA-ключ — ключ сервера (обычно 768 бит). Этот ключ создается заново каждый час и никогда не сохраняется на диске. Каждый раз при установке соединения с клиентом демон отправляет ему в ответ свой открытый ключ и ключ сервера. Клиент сравнивает полученный открытый ключ со своей базой данных, чтобы проверить, не изменился ли он. Затем клиент случайным образом генерирует 256-разрядное число и кодирует его, используя одновременно два ключа — открытый ключ и ключ сервера. Обе стороны используют этот случайный номер как ключ сессии, который используется для кодирования всех передаваемых во время сессии данных. Затем клиент пытается аутентифицировать себя, используя .rhosts-аутентификацию, аутентификацию RSA или же аутентификацию с использованием пароля. Обычно .rhosts-аутентификация небезопасна, поэтому она отключена.
? Протокол SSH версия 2. Версия 2 работает аналогично первой: каждый узел имеет определенный RSA-ключ, который используется для идентификации узла. Однако при запуске демона ключ сервера не генерируется. Безопасность соединения обеспечивается благодаря соглашению Диффи-Хелмана (Diffie-Hellman key agreement). Кроме того, в SSh3 были исправлены недостатки SSh2. Сессия может кодироваться следующими методами: 128-разрядный AES, Blowfish, 3DES, CAST128, Arcfour, 192-разрядный AES или 256-разрядный AES.
Программные пакеты, использующие эти протоколы, так и называются: ssh2 и ssh3. Сервером SSH служит демон sshd, который запускается на UNIX-машине, а клиентом — программа ssh, которая распространяется как для Linux, так и для Windows. Клиент ssh служит для обеспечения защищенной регистрации на удаленном компьютере. В пакет ssh входит еще и третья программа — scp, служащая для безопасного копирования файлов с локального компьютера на удаленный. Однако основным назначением SSH является все-таки авторизация пользователя при регистрации его на удаленном компьютере.
Оба программных продукта (SSh2 и SSh3) являются коммерческими и стоят денег. Хотя в какой-то момент разработчики одумались и сделали бесплатной SSh3 для Linux и *BSD, было уже поздно. Открытым обществом разработчиков на основе обоих протоколов SSH, с добавлением дополнительных возможностей и исправлением некоторых ошибок, был разработан ее бесплатный вариант OpenSSH.
Первая версия OpenSSH вышла еще в декабре 2001 года. В дистрибутив Fedora Core 3 включена третья версия этого продукта. Компьютеры, на которых установлена OpenSSH, прекрасно взаимодействуют с компьютерами, на которых установлены коммерческие SSh2 или SSh3, то есть продукты полностью совместимы.
В дальнейшем, когда я буду говорить о SSH, я буду иметь в виду именно OpenSSH, которая поставляется со всеми современными дистрибутивами Linux. В целях безопасности рекомендуется отслеживать обновления и скачивать последнюю версию (в мае 2005 г. вышла четвертая) с сайта www.openssh.org.
Свободно распространяемая версия SSH состоит из следующих пакетов:
? openssh — основные файлы;
? openssh-clients — программа-клиент;
? openssh-server — ssh-сервер.
Чтобы служба SSH начала работать, необходимо запустить демон sshd на той машине, к которой предполагается подключение. Желательно добавить команду запуска в сценарий загрузки системы. Демон sshd работает по 22 порту (см. листинг 11.2). Можно запускать его из-под супердемона xinetd/inetd, но обычно sshd запускается самостоятельно — в режиме standalone.
Настройка SSH на сервере
Конфигурационный файл сервера sshd называется /etc/ssh/sshd_config. Справку по его синтаксису вы можете получить по команде man 5 sshd_config. В пакете openssh-server находится конфигурационный файл с типовыми настройками.
Чтобы оградить ваш компьютер от нежелательных вторжений извне, рекомендую вписать в этот файл директиву allowedadress, перечислив через пробел IP-адреса тех машин, с которых разрешен вход клиентов:
allowedadress 10.1.1.1 10.1.2.1 10.1.3.1
Листинг 11.2. Примерный файл конфигурации /etc/ssh/sshd_config
Port 22
# Сначала пытаемся работать по протоколу SSH 2, а потом,
# если та сторона не поддерживает вторую версию, — по SSH 1
Protocol 2,1
# Ключ для протокола SSH версии 1
HostKey /etc/openssh/ssh_host_key
# Ключи для протокола SSh3 — RSA и DSA
HostKey /etc/openssh/ssh_host_rsa_key
HostKey /etc/openssh/ssh_host_dsa_key
# Время жизни и размер ключа ssh версии 1
KeyRegenerationInterval 3600
# По умолчанию используется размер 768 бит,
# лучше установить 1024
ServerKeyBits 1024
# Время, через которое ключи сервера будут созданы заново.
# Периодическая смена ключей повышает безопасность системы.
KeyRegenerationInterval 1h
# Запрещаем регистрацию пользователя root по ssh.
# Это не исключает возможности удаленного
# администрирования: просто руту придется зайти под
# обычным пользователем, а затем выполнить команду su.
# Зато злоумышленнику понадобится украсть
# не один, а два пароля: и root, и обычного пользователя.
PermitRootLogin no
# Протоколирование (раскомментируйте, если нужно
# вести журнал с помощью системы syslog)
#SyslogFacility AUTH
#LogLevel INFO
# Аутентификация
# Включает парольную аутентификацию
# и запрещает пустые пароли
PasswordAuthentication yes
PermitEmptyPasswords no
#StrictModes yes
# используем RSA-аутентификацию
RSAAuthentication yes
PubkeyAuthentication yes
# Аутентификация rhosts — обычно не используется,
# поэтому запрещаем ее:
# пользовательские файлы ~/.rhosts и ~/.shosts не
# будут использоваться
RhostsAuthentication no
IgnoreRhosts yes
# НЕ использовать РАМ аутентификацию
PAMAuthenticationViaKbdInt no
# Дополнительное время клиенту на то, чтобы
# аутентифицировать себя.
# Если за это время клиент не смог ввести пароль,
# соединение будет прекращено
LoginGraceTime 2m
# Следующие параметры нужны для того, чтобы заставить
# систему X Window работать по ssh. Подробнее вы
# сможете прочитать в документации по ssh
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#Compression yes
# Путь к баннеру
Banner /some/path
# подсистема sftp-сервера
Subsystem sftp /usr/libexec/openssh/sftp-server
Запуск демона sshd
Перед первым запуском sshd необходимо сгенерировать файлы, содержащие ключи кодирования. В сценариях, осуществляющих запуск сервера sshd, обычно предусмотрена проверка наличия этих файлов. В случае их отсутствия они генерируются автоматически.
Ключи, с которыми можно запускать sshd, перечислены в таблице 11.4.
Ключи сервера sshd Таблица 11.4
Ключ
Назначение
-b биты
Определяет число битов для ключа сервера (по умолчанию 7681. Эту опцию можно использовать, только если вы используете протокол SSH версии 1
-d
Режим отладки (DEBUG). В этом режиме сервер не переходит в фоновый режим, обрабатывает только одно соединение и подробно протоколирует свои действия в системном журнале. Ключ отладки особенно полезен для изучения работы сервера
-D
Так же, как и при использовании предыдущего ключа, сервер sshd не будет переходить в фоновый режим. Однако а отличие от -d ключ -D не переводит сервер в режим отладки
-e
Отправлять отладочные сообщения не в системный журнал, а на стандартный поток ошибок
-f файл
Задает альтернативный файл конфигурации вместо /etc/ssh/sshd_config
-g время
Предоставляет клиенту, не прошедшему аутентификацию, дополнительное время на ввод пароля. Значение 0 интерпретируется как бесконечное ожидание
-h файл_ключа
Задает альтернативным файл открытого ключи (ключ узла). По умолчанию используется файл /etc/ssh/ssh_host_key. Этот ключ может понадобиться, чтобы запускать sshd от имени непривилегированного пользователя. Также ключ -h часто применяется при запуске sshd из сценариев, задающих различные настройки в зависимости от времени суток (в рабочее и нерабочее время)
-i
Используется, если нужно запускать sshd через суперсервер xinetd. Обычно демон sshd запускается отдельно при загрузке системы. Связано это с тем, что демону sshd требуется некоторое время для генерирования ключа сервера, прежде чем он сможет ответить на запросы клиентов. При запуске через суперсервер при каждом соединении суперсервер будет заново вызывать sshd, а тот — заново генерировать ключ. Однако на современных компьютерах задержка практически не заметна. Поэтому вполне можно запускать sshd и через суперсервер
-k время
Задает время, спустя которое ключ сервера будет создан заново. По умолчанию время составляет 1 час. Эту опцию можно использовать только с протоколом SSH версии 1
-p порт
Указывает альтернативный порт, который демон sshd будет прослушивать вместо порта 22
-q
«Тихий ражим», не протоколировать сессию. Обычно протоколируется начало аутентификации. результат аутентификации и время окончания сессии
-t
Тестовый ражим. Применяется для проверки корректности файла конфигурации
-4
Разрешается использовать IP-адреса только в формате IPv4
-6
Разрешается использовать IP-адреса только в формате IPv6
Использование SSH-клиента
Клиентская программа ssh находится в пакете openssh-clients вместе с типовым конфигурационным файлом /etc/ssh/ssh_config. Настройки можно задавать и из командной строки, запуская ssh с соответствующими ключами. Основные ключи и аргументы перечислены в таблице 11.5.
Ключи программы ssh Таблица 11.5
Ключ
Назначение
-а
Отключает перенаправление аутентификации агента соединения
-А
Включает перенаправление аутентификации агента соединения
-с blowfish|3des|des
Позволяет выбрать алгоритм шифрования при использовании первой версии протокола SSH. Можно указать blowfish, 3des или des
-c
Задает использование сжатия всех данных во всех выходных потоках с использованием gzip.
-f
Данная опция переводит ssh в фоновый режим после аутентификации пользователя. Рекомендуется использовать для запуска программы X11. Например: ssh -f host xterm
-i идент_файл
Задает нестандартный идентификационный файл (для нестандартной RSA/DSA-аутентификации)
-l логин_имя
Указывает, от имени какого пользователя будет осуществляться регистрации на удаленной машине
-p порт
Определяет порт, к которому подключится программа ssh (по умолчанию используется порт 22)
-q
Переводит программу ssh в «тихий режим>>. При этом будут отображаться только сообщения о фатальных ошибках. Все прочив предупреждающие сообщения а стандартный выходной поток выводиться не будут
-V
Включает отображение всей отладочной информации
-x
Отключить перенаправление X11
-X
Включить перенаправление X11
-1
Использовать только первую версию протокола SSH (принудительно)
-2
Использовать только вторую версию протокола SSH (принудительно)
-4
Разрешается использовать IP-адреса только в формате IPv4
-6
Разрешается использовать IP-адреса только в формате IPv6
Формат команды:
ssh [ключи] [ключи_с_аргументами] [логин_имя@]хост.домен [команда]
Если последним аргументом указана команда, то после успешного входа пользователя она выполняется на удаленной машине вместо командной оболочки по умолчанию. Таким образом можно работать не в командной строке, а запустить на удаленной машине графический сеанс.
Аутентификация средствами SSH
Аутентификация в SSH может производиться одним из следующих четырех способов:
? По принципу доверия. При этом способе проверяется, внесено ли имя компьютера, с которого производится доступ, в файл ~/.rhosts (или ~/.shosts). Если его имя (IP-адрес) внесено, то пользователю разрешается доступ без проверки пароля. Этот способ очень уязвим для разнообразных атак (подмены IP-адреса и т.п.), так что использовать его категорически не рекомендуется. Для того, чтобы разрешить этот способ, нужно установить значение no для директивы IgnoreRHosts и yes для RhostsAuthentication в файле /etc/openssh/sshd_conf, а чтобы запретить — значения для этих директив поменять на противоположные.
? Усиленная аутентификация по принципу доверия. Этот способ в принципе повторяет предыдущий, за тем лишь исключением, что проверка имени компьютера (IP-адреса) производится в защищенном режиме. При этом используется шифрование открытым ключом. За включение и отключение данного механизма аутентификации отвечают директивы RhostsRSAAuthentication и IgnoreRHosts. Несмотря на некоторые усовершенствования, этот способ по-прежнему является небезопасным.
? Аутентификация самого пользователя с использованием шифрования с открытым ключом. На момент регистрации у пользователя должен быть доступ к файлу своего секретного ключа, и он должен предоставить пароль для его дешифровки. Этот способ аутентификации является самым надежным, но и самым неудобным. Кроме того, он вынуждает пользователей постоянно иметь под рукой файл с ключом. За включение и отключение этого способа отвечает директива PubkeyAulhentication (или RSAAuthentication в зависимости от версии).
? Аутентификация с помощью пароля. Это оптимальный способ: он удобен в использовании и в то же время достаточно безопасен. Именно он и используется в большинстве случаев. В отличие от telnet, пароль здесь передается в зашифрованном виде. Основной недостаток данного метода заключается в относительной слабости паролей (их длина зачастую составляет менее 8 символов). Это позволяет подбирать их с помощью специальных программ. За включение и отключение этого способа отвечает директива PasswordAnthentication.
Какой способ использовать — решать вам. Однако настоятельно не рекомендуется применение первых двух способов. Их использование допустимо лишь в исключительных случаях и в особых условиях.
Бесплатный SSH-клиент для Windows можно скачать у автора, Роберта Каллагана, сайт http://www.zip.com.au/~roca/ttssh.html.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Установка и настройка SSH. Регистрация в удаленной системе с помощью SSH
Установка и настройка SSH. Регистрация в удаленной системе с помощью SSH
Большинство профессиональных системных администраторов Linux не используют графическую систему на своих интернет-серверах. Таким образом, если вы хотите получить доступ к другим компьютерам для удаленного администрирования, вам придется какое-то время работать в командной строке. К счастью, существует множество функциональных Linux-команд, которые помогут в этом.
Утилиты, связанные с безопасным командным процессором (SSH), не только позволяют получать удаленный доступ и передавать файлы, но и предоставляют функцию шифрования данных, чтобы ваша работа по удаленному администрированию была безопасной. С помощью таких утилит, как Virtual Network Computing (VNC), вы сможете запустить Рабочий стол удаленного сервера на вашем локальном компьютере. Эти и другие функции по удаленному администрированию описаны в данной главе.
Регистрация в удаленной системе и туннелирование с помощью SSH
Старшая сестра Linux — система UNIX — создавалась в университетских сетях. В то время пользователями таких изолированных друг от друга сетей были профессора и студенты, поэтому необходимости в безопасности таких сетей не было.
Приложения и протоколы, созданные в то время (1970-1980-е годы), отражают недостаточное внимание, уделяемое шифрованию и процессу регистрации в удаленной системе. SMTP является отличным примером данного явления. То же можно сказать и об утилитах для удаленной работы первого поколения: telnet, ftp (протокол FTP), rsh (удаленный интерпретатор команд), гср (удаленное копирование), гехес (удаленное выполнение) и rlogin (удаленный вход в систему). Эти утилиты посылали данные о пользователе и трафик посредством обычного текста. По этой причине их опасно использовать в общественно доступных сетях, таких как сегодняшний Интернет. По большей части всеми этими средствами уже не пользуются — их заменили команды SSH (команды ssh, scp, sftp и родственные сервисы).
Хотя для устаревших команд по работе с удаленным доступом все еще находится применение (см. врезку «Использование устаревших средств коммуникации»), большая часть этой главы посвящена SSH-командам, с помощью которых можно удовлетворить все ваши потребности в области удаленной связи.
Использование устаревших средств коммуникации
Несмотря на тот факт, что SSH предоставляет более совершенные средства удаленной коммуникации, устаревшие команды (их иногда называют r-команды) до сих пор включаются во все крупные дистрибутивы Linux. Некоторые из этих инструментов будут работать быстрее, чем соответствующие им команды SSH, так как им не надо проводить шифрование данных. Некоторые администраторы UNIX старой закалки могут иногда пользоваться ими в личных сетях или все еще включать в свои сценарии. Хотя по большей части вы будете просто оставлять в стороне устаревшие команды удаленного доступа, в некоторых случаях tel net может быть полезной.
Команда telnet все еще применяется для связи с некоторыми сетевыми устройствами (маршрутизаторы, переключатели, UPS и пр.), у которых нет мощности для запуска демона ssh. Хотя она несет в себе некоторый риск, связанный с безопасностью, некоторые производители все еще включают поддержку tel net в свои устройства.
Отличным способом применения команды telnet является устранение неполадок связанных с интернет-протоколами POP3, SMTP, HTTP и др. На самом деле данные текстовые протоколы — это автоматические сессии tel net, в течение которых клиент (например, браузер или почтовая программа пользователя) обменивается текстом с сервером. Единственным отличием является используемый TCP-порт. Вот пример использования telnet через HTTP-порт (80) веб-сервера:
Подобно этому, вы можете настроить команду telnet на работу с портом 25 почтового сервера (SMTP) и 110 (РОРЗ) и использовать необходимые команды для устранения неполадок с электронной почтой. Более подробно применение telnet для устранения неполадок с сетевыми протоколами описывается в книге Linux Troubleshooting Bible (Wiley Publishing, 2004).
Если вы хотите выйти из telnet-сессии, задействуйте ESC-последо-вательность (Ctrl+] по умолчанию). Это прекратит посылку информации с вашей клавиатуры на удаленный компьютер и выведет окно командной строки tel net, где вы можете напечатать qui t для выхода или ?, чтобы увидеть все параметры.
Настройка SSH
На сегодняшний день настоящим многофункциональным инструментом сетевых администраторов является SSH. Команды и сервисы SSH заменяют все старые средства для удаленного доступа и добавляют отличное шифрование данных, открытые ключи и другие функции. Наиболее распространенным воплощением SSH в мире Linux является OpenSSH (http://www.openssh.com) — программа, обслуживаемая проектом OpenBSD. В OpenSSH входят клиентская и серверная части. Для установки сервера OpenSSH выполните следующую команду:
apt-get install openssh-server
Рассмотрим некоторые новые особенности SSH.
-В среде Windows можно использовать утилиты SSH из Linux с помощью Cygwin (http://www.cygwin.com). Если вы уже используете Cygwin (эмулятор среды Linux для Windows), то мы рекомендуем PuTTY (http://www.chiark.greenend.org/uk/sgatatham/ putty). PuTTY — это мощный Telnet/SSH-клиент с открытым кодом доступа.
-Используйте SHH версии 2, где это возможно, так как она наиболее хорошо защищена. Некоторые сетевые устройства, поддерживающие SHH, могут работать только с более ранними, менее безопасными версиями. OpenSSH поддерживает все версии. Некоторые предыдущие версии Ubuntu принимали подключения SSH 1 и SSH 2. Однако новые выпуски работают с версией 2 по умолчанию.
-В Ubuntu выполните команду /etc/init.d/ssh start, чтобы запустить сервис SSH (демон sshd). Для настройки сервиса отредактируйте файл /etc/ssh/ sshd_config.
-Чтобы настроить клиент ssh, отредактируйте файл /etc/ssh/ssh_config.
Если вы предпочитаете использовать графические утилиты для администрирования удаленной Linux-системы, то можете активировать Х11-туннелирование (его также называют X11 Port Forwarding). С включенным X11-туннелированием (как на сервере, так и на клиенте) вы можете запустить приложение X на сервере, и оно будет отображаться на клиенте. Вся передаваемая через это подключение информация зашифрована.
В Ubuntu переадресация портов X11 включена (X11Forwarding yes) на сервере посредствам демона sshd. Вам все же необходимо включать ее на стороне клиента. Чтобы включить переадресацию X11 на клиенте в рамках одной сессии, подключитесь с помощью следующей команды:
ssh -x blabla(login)@server
Чтобы включить переадресацию XII на постоянной основе для всех пользователей, добавьте строку ForwardXll yes в файл /etc/ssh/ssh_config. Чтобы переадресация X11 постоянно была активна для определенного пользователя, добавьте строку в файл этого пользователя ~.ssh/config. Как только эти установки были заданы, параметр -X больше не нужен для запуска X11-туннелирования. Выполните команду ssh, как обычно, для подключения к удаленной системе. Для проверки работы туннелирования после установки соединения с удаленной машиной с помощью ssh запустите команду xclock, и данное приложение запустится на Рабочем столе вашего клиента.
SSH-туннелирование — это отличный способ безопасного использования удаленных графических утилит!
Использование команды ssh для удаленного входа в систему
Для безопасного входа в удаленную систему вы можете использовать один из двух возможных синтаксисов указания имени пользователя:
ssh -i blabla(login) server
или
ssh blabla(login)@server
Однако команды scp и sftp, поддерживают только синтаксис user@server, поэтому мы рекомендуем привыкнуть именно к нему. Если вы не укажете имя пользователя, то ssh попытается подключиться с тем именем, под которым вы находитесь в системе. Если во время подключения вы захотите самостоятельно прервать ssh-сессию, наберите ESC-последовательность (- ).
Доступ к SSH через другой порт
По причинам, связанным с безопасностью, удаленный хост-компьютер может указать другой порт для работы SSH-сервиса, нежели порт 22, который используется по умолчанию. При таких обстоятельствах используйте параметр -р для связи с этим сервисом:
ssh -p 1245 blabla@server подключение идет по порту 1245
Использование SSH для туннелирования (X11 Port Forwarding)
Если SSH-туннелирование настроено, как показано выше, то сервис SSH перенаправляет клиенты X Window System на ваш локальный монитор. Однако тунне-лирование можно использовать и с другими TCP-протоколами.
Туннелирование для удаленного администрирования принтеров CUPS. X11
это не единственный протокол, который работает с переадресацией. Вы можете задать переадресацию на любой TCP-порт с помощью SSH. Это отличный способ быстрой и легкой настройки безопасных туннелей. На стороне сервера не требуется никакой настройки.
Туннелирование для клиентов X11. Следующая последовательность команд демонстрирует запуск SSH-сессии, а затем открытие нескольких Х-приложений, которые должны появиться в вашей локальной рабочей области:
Например, myserver является сервером принтеров с включенным пользовательским веб-интерфейсом сервиса CUPS (работающим через порт 631). Этот графический интерфейс доступен только с локальной машины. На текущем клиентском компьютере мы создаем туннель к этому сервису с помощью команды ssh со следующими параметрами:
ssh -L 1245:localhost:631 server
Этот пример устанавливает переадресацию порта 1234 клиентской части на порт 631 на сервере. Теперь мы можем открыть http://localhost:1234 на компьютере-клиенте. Этот запрос будет перенаправлен команде cupsd, которая ожидает сигнала через порт 631 на сервере.
Переадресация интернет-сервисов. Рассмотрим еще один пример использования SSH-туннелирования. Когда ваша локальная машина не имеет доступа к Интернету, но может подключиться к другому компьютеру (myserver) с активным интернет-соединением. Следующий пример позволяет посетить сайт Google.com (HTTP, TCP порт 80) через SSH-подключение к компьютеру по имени myserver, который подключен к Интернету:
ssh -L 1245:google.com:80 server
При использовании этого примера любое подключение к локальному порту 12345 переадресовывается через SSH-туннель к myserver, который, в свою очередь, открывает подключение к Google.com через порт 80. Теперь вы можете зайти на http://localhost:12345 и использовать myserver как ретранслятор сайта Google.com. Поскольку вы используете команду shh для переадресации порта, а не для получения интерпретатора команд на сервере, то можете добавить параметр -N, чтобы предотвратить выполнение удаленных команд:
ssh -L 1245:google.com:80 -N server
Применение SSH в качестве прокси-сервера SOCKS
Предыдущий пример демонстрирует, что вы можете переадресовать порт от клиента к компьютеру, отличному от сервера. В реальности лучшим способом вывести трафик браузера из вашей локальной сети через кодируемый туннель является использование встроенной в SSH функции прокси-сервера SOCKS. Например:
ssh -D 1245 server
Динамический параметр (-D) ssh позволяет войти в myserver (как обычно). Пока подключение активно, все запросы, отправленные порту 12345, переадресовываются на myserver. Далее установите прокси-сервер SOCKS v5 в браузере как localhost: 12345, и вы будете готовы к его использованию. Не вводите ничего в поля HTTP и других протоколов. Они все работают через SOCKS. На рисунке показано окно настройки подключений Firefox.
Используйте окно настройки подключений FIrefox для определения параметров прокси-сервера
Для проверки настроек отключите сессию ssh и зайдите на любой сайт. Браузер должен выдать сообщение об ошибке прокси-сервера.
Выбрав команду Connection > SSH > Tunnels (Подключение > SSH > Туннели) в Putty, вы можете реализовать такую же переадресацию и в среде Windows.
SSH-аутентификация с использованием открытого ключа
До сих пор мы использовали команду ssh с аутентификацией по умолчанию. Команда также поддерживает аутентификацию с использованием открытого ключа. Это имеет несколько преимуществ.
-Автоматический вход в систему для сценариев и процессов стоп. Установив пустую фразу-пароль, вы можете использовать ssh в сценариях для автоматического входа в систему. Хотя это и удобно, но небезопасно, так как любой, кто получит доступ к вашему файлу с ключом, может подключиться к любой машине, к которой вы имеете доступ. Настройка автоматического входа в систему также может осуществляться с помощью фразы-пароля и агента по работе с ключами. Как показано ниже, это компромисс между удобством и безопасностью.
-Двухфакторная аутентификация. При использовании ключа с фразой-паролем для интерактивного входа в систему аутентификация проводится по двум факторам (ключ и фраза-пароль) вместо одного.
-Вход в систему с использованием открытых ключей. Рассмотрим процесс установки связи между двумя Linux-системами на основе ключа. В следующих примерах мы используем пустые фразы-пароли, не применяя имя пользователя и пароль. Если вы желаете защитить ключ с помощью пароля, то просто введите его во время первого шага (создание пары ключей).
Запустите следующую команду ssh-keygen на компьютере-клиенте для создания пары ключей, когда находитесь в системе под именем пользователя, которому необходимо установить связь:
Обратите внимание, что при каждом приглашении к действию вы нажимали Enter для создания файла ключа, используемого по умолчанию и для ввода (подтверждения) пароля. Теперь у вас есть частный ключ, который должен храниться в безопасном месте, в особенности если он не был защищен паролем.
Кроме того, у вас есть открытый ключ (id_rsa.pub), который был создан предыдущей командой. Открытый ключ должен быть установлен на хост-компьютерах, к которым вы хотите подключаться. Содержимое файла ~/.ssh/id_rsa.pub нужно скопировать (безопасно) в -/.ssh/authorized_keys2 для пользователя, который будет использовать ssh на удаленном компьютере. Файл authorized_keys2 может содержать несколько ключей, если несколько пользователей использовали ssh для подключения к этой учетной записи.
Войдите в удаленную серверную систему под именем пользователя, от имени которого хотите использовать ssh с ключом. Если у вас все еще нет папки -/.ssh, то первым делом необходимо создать ее:
cd
mkdir .ssh
chmod 700 .ssh
Далее копируйте (безопасно) файл открытого ключа с клиента и поместите в файл авторизированных ключей на сервере. Это можно сделать с помощью команды scp. Предположим, что имя клиентской системы — myclient, а пользователь — chris. Введите на сервере следующее:
Эта процедура также может быть выполнена путем редактирования текстового файла -/.ssh/authorized_keys2 на сервере и копирования/вставки открытого ключа с компьютера клиента. Убедитесь, что передача происходит безопасно через ssh, и не вставляйте никаких переносов на новую строку при записи ключа. Полный ключ должен помещаться на одной строке, даже если он выходит за пределы экрана.
Затем вы можете просто выполнять команду ssh с компьютера-клиента (применяя учетные записи пользователей, для которых проводили настройку), и сервер будет использовать ключ. Если вы установите фразу-пароль, то у вас будут ее требовать, как обычный пароль.
Сохранение частных ключей для их использования с Flash-носителя. Если вы хотите хранить свой частный ключ в более безопасном месте, нежели жесткий диск, то можете использовать Flash-носитель (его также называют флеш-кой):
Использование ключей с фразами-паролями более безопасно, чем применение обычных паролей, но и более затруднительно. Для облегчения работы можно использовать команду ssh-agent, чтобы хранить разблокированные ключи на время текущей сессии. Добавив разблокированный ключ в запущенный ssh-agent, вы сможете запускать команду ssh с ключом, но у вас теперь не будут каждый раз запрашивать фразу-пароль.
Чтобы увидеть, что делает команда ssh-agent, запустите ее без параметров. После запуска появится трехстрочный bash-сценарий:
Первые две строки вывода должны быть выполнены вашим интерпретатором команд. Скопируйте эти строки в командную оболочку (shell) прямо сейчас. Вы можете избежать этих действий, запустив ssh-agent и приказав интерпретатору команд bash выполнить результат работы команды. Это достигается следующим образом:
Далее вы можете добавить ключ, хранящийся на флешке:
Теперь можно разблокировать ключи и добавлять их в запущенный агент. Допустим, вы уже создали ключ командой ssh-keygen. Теперь добавим ключ, используемый по умолчанию, с помощью команды shh-add:
Для вывода списка всех ключей, хранящихся в агенте, используйте параметр -1:
Чтобы удалить один ключ из агента, например находящийся на флешке, запустите команду ssh-add с параметром -d:
Для удаления всех ключей, хранящихся в агенте, используйте параметр -D:
Ubuntu Linux установить сервер OpenSSH
Как установить сервер OpenSSH в Ubuntu Linux?
Введение : sshd (OpenSSH Daemon или server) — это программа-демон для клиента ssh. Это бесплатный ssh-сервер с открытым исходным кодом. ssh заменяет небезопасные rlogin и rsh и обеспечивает безопасную зашифрованную связь между двумя ненадежными хостами в незащищенной сети, такой как Интернет. Рабочий стол Ubuntu и минимальный сервер Ubuntu не поставляются с установленным sshd. Однако вы можете легко установить SSH-сервер в Ubuntu, выполнив следующие действия.
Как установить SSH-сервер в Ubuntu
Процедура установки ssh-сервера в Ubuntu Linux выглядит следующим образом:
- Откройте приложение терминала для рабочего стола Ubuntu.
- Для удаленного сервера Ubuntu вы должны использовать инструмент BMC, KVM или IPMI, чтобы получить доступ к консоли
- Введите sudo apt-get install openssh-server
- Включите службу ssh, набрав sudo systemctl enable ssh
- Запустите службу ssh, набрав sudo systemctl start ssh
- Протестируйте его, войдя в систему, используя ssh user @ server-name
Давайте подробно рассмотрим все шаги установки сервера Ubuntu OpenSSH с параметрами конфигурации.
1. Войдите на удаленный сервер, используя bmc / ipmi / kvm через IP (необязательно)
Я использую систему на базе OpenPOWER под названием Talos II от Raptor Computing Systems. Это архитектура на основе PowerPC (ppc / ppc64le). После новой установки Ubuntu Linux (ppc64le) я обнаружил, что SSH-сервер не установлен по умолчанию. Итак, вот как войти на сервер bmc, чтобы получить доступ к последовательной консоли:
$ ssh root @ power9-bmc
Запустите obmc-console-client, чтобы получить консольный доступ к консоли сервера Ubuntu:
# obmc-console -клиент
2.Ubuntu Linux устанавливает сервер OpenSSH
Сначала обновите систему с помощью команды apt или apt-get:
$ sudo apt update
$ sudo apt upgrade
Установка sshd-сервера в Ubuntu Linux
Чтобы установить пакет openssh-server, выполните:
$ sudo apt install openssh-server
Щелкните, чтобы увеличить изображение
3. Убедитесь, что служба ssh работает под номером
Введите следующую команду systemctl:
$ sudo systemctl status ssh
Если не запущен, включите сервер ssh и запустите его следующим образом, набрав команду systemctl:
$ sudo systemctl enable ssh
$ sudo systemctl start ssh
Состояние синхронизации ssh.service с помощью служебного скрипта SysV с / lib / systemd / systemd-sysv-install. Выполнение: / lib / systemd / systemd-sysv-install enable ssh Создана символическая ссылка /etc/systemd/system/sshd.service? /lib/systemd/system/ssh.service.
4. Настройте брандмауэр и откройте порт 22
Вы должны настроить брандмауэр Ubuntu Linux под названием ufw. Вот как открыть или разрешить порт 22 при использовании ufw в Ubuntu:
$ sudo ufw allow ssh
$ sudo ufw enable
$ sudo ufw status
Дополнительные сведения см. В нашем руководстве «Настройка брандмауэра ufw на Ubuntu».
5. Проверьте это
Теперь вы можете войти в систему со своего настольного компьютера под управлением Linux, * BSD, macOS, MS-Windows (клиент putty) или Unix-подобной системы, используя команду ssh:
$ ssh vivek @ server-ip
$ ssh vivek @ power9
Вы можете установить копию и установить открытый ключ с помощью команды ssh-copy-id для входа без пароля:
$ ssh-copy-id vivek @ power9
См. «Аутентификация на основе открытого ключа SSH в Linux / Unix. сервер »для получения дополнительной информации.
Файл конфигурации Ssh
Можно создать ярлыки для параметров входа / клиента ssh.Например, создайте файл с именем ~ / .ssh / config следующим образом:
$ nano ~ / .ssh / config
ИЛИ
$ vi $ HOME / .ssh / config
Добавьте следующее, чтобы войти в мой EC2 Ubuntu сервер в облаке AWS:
Хост web01
Имя хоста aws-ec2-www-server1.cyberciti.biz
Порт 22
IdentityFile ~ / .ssh / AWS_EC2_Virginia_US_East_Ubuntu_Boxes.pem
Пользователь ubuntu Для входа просто введите:
ssh web01
См. «Примеры файла конфигурации OpenSSH» для получения дополнительной информации.
Заключение
В этом руководстве вы узнаете, как установить серверное приложение OpenSSH из командной строки. Хотя инструкции протестированы для архитектуры Power9 (ppc64le), они также должны работать на сервере Intel AMD64 или ARAM64. Для получения дополнительной информации см. Домашнюю страницу OpenSSH здесь и руководство по защите сервера OpenSSH здесь.
Как настроить аутентификацию на основе ключей SSH на сервере Linux
Введение
SSH, или безопасная оболочка, — это зашифрованный протокол, используемый для администрирования и связи с серверами.При работе с сервером Linux есть вероятность, что вы будете проводить большую часть своего времени в сеансе терминала, подключенном к вашему серверу через SSH.
Хотя существует несколько различных способов входа на сервер SSH, в этом руководстве мы сосредоточимся на настройке ключей SSH. Ключи SSH обеспечивают простой, но чрезвычайно безопасный способ входа на ваш сервер. По этой причине мы рекомендуем этот метод всем пользователям.
Как работают ключи SSH?
Сервер SSH может аутентифицировать клиентов, используя множество различных методов.Самый простой из них — это аутентификация по паролю, которая проста в использовании, но не является самой безопасной.
Хотя пароли отправляются на сервер безопасным способом, они, как правило, не являются сложными или достаточно длинными, чтобы противостоять повторяющимся и постоянным атакам. Современная вычислительная мощность в сочетании с автоматическими скриптами делает возможной грубую подделку учетной записи, защищенной паролем. Хотя есть и другие методы добавления дополнительной безопасности ( fail2ban и т. Д.), Ключи SSH оказались надежной и безопасной альтернативой.
Пары ключей
SSH — это два криптографически безопасных ключа, которые можно использовать для аутентификации клиента на сервере SSH. Каждая пара ключей состоит из открытого и закрытого ключей.
Закрытый ключ остается у клиента и должен храниться в полной тайне. Любая компрометация закрытого ключа позволит злоумышленнику войти на серверы, на которых настроен связанный открытый ключ, без дополнительной аутентификации. В качестве дополнительной меры предосторожности ключ можно зашифровать на диске с помощью парольной фразы.
Связанный открытый ключ может быть передан бесплатно без каких-либо негативных последствий. Открытый ключ может использоваться для шифрования сообщений, которые только может расшифровать частный ключ. Это свойство используется как способ аутентификации с использованием пары ключей.
Открытый ключ загружен на удаленный сервер, на который вы хотите войти по SSH. Ключ добавляется в специальный файл в учетной записи пользователя, в которую вы будете входить, под названием ~ / .ssh / authorized_keys .
Когда клиент пытается аутентифицироваться с использованием ключей SSH, сервер может проверить клиента, владеет ли он закрытым ключом. Если клиент может доказать, что он владеет закрытым ключом, запускается сеанс оболочки или выполняется запрошенная команда.
Как создать ключи SSH
Первым шагом для настройки аутентификации по ключу SSH на сервере является создание пары ключей SSH на локальном компьютере.
Для этого мы можем использовать специальную утилиту ssh-keygen , которая входит в стандартный набор инструментов OpenSSH.По умолчанию это создаст 2048-битную пару ключей RSA, что подходит для большинства случаев.
На локальном компьютере сгенерируйте пару ключей SSH, набрав:
ssh-keygen
Создание пары ключей открытого и закрытого типа RSA.
Введите файл, в котором нужно сохранить ключ (/home/username/.ssh/id_rsa):
Утилита предложит вам выбрать место для ключей, которые будут сгенерированы. По умолчанию ключи хранятся в каталоге ~ / .ssh в домашнем каталоге вашего пользователя.Закрытый ключ будет называться id_rsa , а связанный открытый ключ будет называться id_rsa.pub .
Обычно на этом этапе лучше придерживаться местоположения по умолчанию. Это позволит вашему SSH-клиенту автоматически находить ваши SSH-ключи при попытке аутентификации. Если вы хотите выбрать нестандартный путь, введите его сейчас, в противном случае нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
Если вы ранее сгенерировали пару ключей SSH, вы можете увидеть запрос, который выглядит следующим образом:
/ главная / имя пользователя /.ssh / id_rsa уже существует.
Перезаписать (да / нет)?
Если вы решите перезаписать ключ на диске, вы больше не сможете , аутентифицироваться с использованием предыдущего ключа. Будьте очень осторожны при выборе «да», так как это разрушительный процесс, который нельзя обратить вспять.
Создан каталог /home/username/.ssh.
Введите кодовую фразу (пусто, если кодовая фраза отсутствует):
Введите ту же парольную фразу еще раз:
Далее вам будет предложено ввести парольную фразу для ключа.Это необязательная кодовая фраза, которую можно использовать для шифрования файла закрытого ключа на диске.
Вам может быть интересно, какие преимущества дает SSH-ключ, если вам все же нужно ввести кодовую фразу. Некоторые из преимуществ:
- Закрытый ключ SSH (часть, которая может быть защищена парольной фразой) никогда не отображается в сети. Парольная фраза используется только для расшифровки ключа на локальном компьютере. Это означает, что сетевой брутфорс для парольной фразы невозможен.
- Закрытый ключ хранится в закрытом каталоге. Клиент SSH не распознает закрытые ключи, которые не хранятся в каталогах с ограниченным доступом. Сам ключ также должен иметь ограниченные разрешения (чтение и запись доступны только владельцу). Это означает, что другие пользователи системы не могут отслеживать.
- Любой злоумышленник, надеющийся взломать парольную фразу закрытого ключа SSH, должен уже иметь доступ к системе. Это означает, что у них уже будет доступ к вашей учетной записи пользователя или учетной записи root.Если вы находитесь в этом положении, кодовая фраза может помешать злоумышленнику немедленно войти на другие ваши серверы. Мы надеемся, что это даст вам время для создания и внедрения новой пары ключей SSH и удаления доступа к скомпрометированному ключу.
Поскольку закрытый ключ никогда не отображается в сети и защищен правами доступа к файлу, этот файл никогда не должен быть доступен никому, кроме вас (и пользователя root). Парольная фраза служит дополнительным уровнем защиты в случае нарушения этих условий.
Парольная фраза — необязательное дополнение. Если вы введете его, вам придется вводить его каждый раз, когда вы используете этот ключ (если вы не используете программное обеспечение агента SSH, которое хранит расшифрованный ключ). Мы рекомендуем использовать парольную фразу, но если вы не хотите устанавливать парольную фразу, вы можете просто нажать клавишу ВВОД, чтобы обойти это приглашение.
Ваш идентификатор был сохранен в /home/username/.ssh/id_rsa.
Ваш открытый ключ был сохранен в /home/username/.ssh/id_rsa.pub.
Ключевой отпечаток пальца:
a9: 49: 2e: 2a: 5e: 33: 3e: a9: de: 4e: 77: 11: 58: b6: 90: 26 имя пользователя @ remote_host
Изображение ключа randomart:
+ - [RSA 2048] ---- +
| ..o |
| E o =. |
| о. о |
| .. |
| ..S |
| о о. |
| = о. +. |
|, = ++ .. |
| о = ++. |
+ ----------------- +
Теперь у вас есть открытый и закрытый ключи, которые вы можете использовать для аутентификации. Следующим шагом является размещение открытого ключа на вашем сервере, чтобы вы могли использовать аутентификацию по ключу SSH для входа в систему.
Как встроить свой открытый ключ при создании сервера
Если вы запускаете новый сервер DigitalOcean, вы можете автоматически встроить свой открытый ключ SSH в корневую учетную запись вашего нового сервера.
Внизу страницы создания капли есть возможность добавить ключи SSH к вашему серверу:
Если вы уже добавили файл открытого ключа в свою учетную запись DigitalOcean, вы увидите его здесь как выбираемый вариант (в приведенном выше примере есть два существующих ключа: «Рабочий ключ» и «Домашний ключ»). Чтобы встроить существующий ключ, просто нажмите на него, и он выделится. Вы можете встроить несколько ключей на один сервер:
Если у вас еще нет открытого ключа SSH, загруженного в вашу учетную запись, или если вы хотите добавить новый ключ в свою учетную запись, нажмите кнопку «+ Добавить SSH-ключ».Это будет расширено до приглашения:
В поле «Содержимое ключа SSH» вставьте содержимое открытого ключа SSH. Предполагая, что вы сгенерировали свои ключи с помощью описанного выше метода, вы можете получить содержимое открытого ключа на локальном компьютере, набрав:
кот ~ / .ssh / id_rsa.pub
SSH-RSA AAAAB3NzaC1yc2EAAAADAQABAAABAQDNqqi1mHLnryb1FdbePrSZQdmXRZxGZbo0gTfglysq6KMNUNY2VhzmYN9JYW39yNtjhVxqfW6ewc + eHiL + IRRM1P5ecDAaL3V0ou6ecSurU + t9DR4114mzNJ5SqNxMgiJzbXdhR + j55GjfXdk0FyzxM3a5qpVcGZEXiAzGzhHytUV51 + YGnuLGaZ37nebh4UlYC + KJev4MYIVww0tWmY + 9GniRSQlgLLUQZ + FcBUjaqhwqVqsHe4F / woW1IHe7mfm63GXyBavVc + llrEzRbMO111MogZUcoWDI9w7UIm8ZOTnhJsk7jhJzG2GpSXZHmly / а / buFaaFnmfZ4MYPkgJD имя пользователя @ пример.com
Вставьте это значение целиком в большее поле. В поле «Комментарий (необязательно)» вы можете выбрать метку для ключа. Это будет отображаться как имя ключа в интерфейсе DigitalOcean:
.
При создании дроплета выбранные вами общедоступные ключи SSH будут помещены в файл ~ / .ssh / authorized_keys учетной записи пользователя root. Это позволит вам войти на сервер с компьютера с вашим закрытым ключом.
Как скопировать открытый ключ на свой сервер
Если у вас уже есть доступный сервер и вы не внедрили ключи при создании, вы все равно можете загрузить свой открытый ключ и использовать его для аутентификации на своем сервере.
Используемый метод во многом зависит от имеющихся у вас инструментов и деталей вашей текущей конфигурации. Все следующие методы дают одинаковый конечный результат. Самый простой и автоматизированный метод — это первый, а последующие за каждым из них требуют дополнительных ручных действий, если вы не можете использовать предыдущие методы.
Копирование вашего открытого ключа с помощью SSH-Copy-ID
Самый простой способ скопировать ваш открытый ключ на существующий сервер — использовать утилиту ssh-copy-id .Этот метод рекомендуется из-за его простоты, если он доступен.
Инструмент ssh-copy-id включен в пакеты OpenSSH во многих дистрибутивах, поэтому он может быть доступен в вашей локальной системе. Чтобы этот метод работал, у вас уже должен быть SSH-доступ на основе пароля к вашему серверу.
Чтобы использовать утилиту, вам просто нужно указать удаленный хост, к которому вы хотите подключиться, и учетную запись пользователя, к которой у вас есть доступ по паролю SSH. Это учетная запись, в которую будет скопирован ваш публичный SSH-ключ.
Синтаксис:
ssh-copy-id имя пользователя @ remote_host
Вы можете увидеть такое сообщение:
Подлинность хоста 111.111.11.111 (111.111.11.111) не может быть установлена.
Отпечаток ключа ECDSA: fd: fd: d4: f9: 77: fe: 73: 84: e1: 55: 00: ad: d6: 6d: 22: fe.
Вы уверены, что хотите продолжить подключение (да / нет)? да
Это просто означает, что ваш локальный компьютер не распознает удаленный хост. Это произойдет при первом подключении к новому хосту.Введите «да» и нажмите ENTER, чтобы продолжить.
Затем утилита просканирует вашу локальную учетную запись на предмет ключа id_rsa.pub , который мы создали ранее. Когда он найдет ключ, он запросит у вас пароль учетной записи удаленного пользователя:
/ usr / bin / ssh-copy-id: INFO: попытка входа в систему с новым ключом (ключами), чтобы отфильтровать все, что уже установлено
/ usr / bin / ssh-copy-id: ИНФОРМАЦИЯ: осталось установить 1 ключ (и) - если вам будет предложено сейчас установить новые ключи
имя пользователя @ 111.111.11.111 пароль:
Введите пароль (ваш ввод не будет отображаться в целях безопасности) и нажмите ENTER. Утилита подключится к учетной записи на удаленном хосте, используя введенный вами пароль. Затем он скопирует содержимое вашего ключа ~ / .ssh / id_rsa.pub в файл в домашнем каталоге удаленной учетной записи ~ / .ssh с именем authorized_keys .
Вы увидите результат, который выглядит следующим образом:
Количество добавленных ключей: 1
Теперь попробуйте войти в систему, используя: "ssh 'username @ 111.111.11.111 '"
и убедитесь, что добавлены только те ключи, которые вам нужны.
На этом этапе ваш ключ id_rsa.pub был загружен в удаленную учетную запись. Вы можете перейти к следующему разделу.
Копирование вашего открытого ключа с помощью SSH
Если у вас нет ssh-copy-id , но у вас есть SSH-доступ на основе пароля к учетной записи на вашем сервере, вы можете загрузить свои ключи, используя обычный метод SSH.
Мы можем сделать это, выведя содержимое нашего открытого ключа SSH на наш локальный компьютер и направив его через соединение SSH на удаленный сервер.С другой стороны, мы можем убедиться, что каталог ~ / .ssh существует под учетной записью, которую мы используем, а затем вывести содержимое, которое мы передали по конвейеру, в файл с именем authorized_keys внутри этого каталога.
Мы будем использовать символ перенаправления >> для добавления содержимого вместо его перезаписи. Это позволит нам добавлять ключи, не разрушая ранее добавленные ключи.
Полная команда будет выглядеть так:
кот ~ / .ssh / id_rsa.паб | ssh username @ remote_host "mkdir -p ~ / .ssh && cat >> ~ / .ssh / authorized_keys"
Вы можете увидеть такое сообщение:
Подлинность хоста 111.111.11.111 (111.111.11.111) не может быть установлена.
Отпечаток ключа ECDSA: fd: fd: d4: f9: 77: fe: 73: 84: e1: 55: 00: ad: d6: 6d: 22: fe.
Вы уверены, что хотите продолжить подключение (да / нет)? да
Это просто означает, что ваш локальный компьютер не распознает удаленный хост. Это произойдет при первом подключении к новому хосту.Введите «да» и нажмите ENTER, чтобы продолжить.
После этого вам будет предложено ввести пароль учетной записи, к которой вы пытаетесь подключиться:
[email protected] пароль:
После ввода пароля содержимое ключа id_rsa.pub будет скопировано в конец файла authorized_keys учетной записи удаленного пользователя. Если это удалось, перейдите к следующему разделу.
Копирование открытого ключа вручную
Если у вас нет доступа к серверу по SSH по паролю, вам придется выполнить описанный выше процесс вручную.
Содержимое вашего файла id_rsa.pub нужно будет каким-то образом добавить в файл по адресу ~ / .ssh / authorized_keys на вашем удаленном компьютере.
Чтобы отобразить содержимое ключа id_rsa.pub , введите это на свой локальный компьютер:
кот ~ / .ssh / id_rsa.pub
Вы увидите содержание ключа, которое может выглядеть примерно так:
SSH-RSA AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh2TmWWv11q5O3pISj2ZFl9Hgh2JLknLLx44 + tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q + bqgZ8SeeM8wzytsY + dVGcBxF6N4JS + zVk5eMcV385gG3Y6ON3EG112n6d + SMXY0OEBIcO6x + PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B + ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G / 12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE + ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77 + xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X / vh3xPff6SQ1BL / zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi / uS66 + PujOO + х / 2FWYepz6ZlN70bRly57Q06J + ZJoc9FfBCbCyYH7U / ASsmY095ywPsBo1XQ9PqhnN1 / YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8 / lERo9oxRm5JFX6TCmj6kmiFqv + Ow9gI0x8GvaQ == демо @ тест
Доступ к удаленному хосту любым доступным способом.Например, если у вас сервер DigitalOcean Droplet, вы можете войти в систему с помощью веб-консоли на панели управления:
После того, как вы получите доступ к своей учетной записи на удаленном сервере, убедитесь, что каталог ~ / .ssh создан. Эта команда при необходимости создаст каталог или ничего не сделает, если он уже существует:
mkdir -p ~ / .ssh
Теперь вы можете создать или изменить файл authorized_keys в этом каталоге.Вы можете добавить содержимое вашего файла id_rsa.pub в конец файла authorized_keys , создав его при необходимости, используя это:
echo public_key_string >> ~ / .ssh / authorized_keys
В приведенной выше команде замените public_key_string выводом команды cat ~ / .ssh / id_rsa.pub , которую вы выполнили в своей локальной системе. Он должен начинаться с ssh-rsa AAAA ... .
Если это сработает, вы можете перейти к попытке аутентификации без пароля.
Аутентификация на вашем сервере с помощью ключей SSH
Если вы успешно выполнили одну из описанных выше процедур, вы сможете войти на удаленный хост без пароля удаленной учетной записи.
Основной процесс тот же:
ssh имя пользователя @ remote_host
Если вы подключаетесь к этому хосту впервые (если вы использовали последний метод выше), вы можете увидеть что-то вроде этого:
Подлинность хоста 111.111.11.111 (111.111.11.111) 'не может быть установлен.
Отпечаток ключа ECDSA: fd: fd: d4: f9: 77: fe: 73: 84: e1: 55: 00: ad: d6: 6d: 22: fe.
Вы уверены, что хотите продолжить подключение (да / нет)? да
Это просто означает, что ваш локальный компьютер не распознает удаленный хост. Введите «да» и нажмите ENTER, чтобы продолжить.
Если вы не указали кодовую фразу для своего закрытого ключа, вы немедленно войдете в систему. Если вы указали парольную фразу для закрытого ключа при создании ключа, вам потребуется ввести ее сейчас.После этого для вас должен быть создан новый сеанс оболочки с учетной записью в удаленной системе.
В случае успеха продолжите поиск, чтобы узнать, как заблокировать сервер.
Отключение аутентификации по паролю на вашем сервере
Если вам удалось войти в свою учетную запись с помощью SSH без пароля, значит, вы успешно настроили аутентификацию на основе ключа SSH для своей учетной записи. Однако ваш механизм аутентификации на основе пароля по-прежнему активен, а это означает, что ваш сервер по-прежнему подвержен атакам грубой силы.
Перед выполнением шагов, описанных в этом разделе, убедитесь, что у вас настроена аутентификация на основе ключей SSH для учетной записи root на этом сервере или, предпочтительно, что у вас есть аутентификация на основе ключей SSH, настроенная для учетной записи на этом сервере с sudo доступа. Этот шаг заблокирует вход на основе пароля, поэтому важно убедиться, что у вас все еще есть возможность получить административный доступ.
После выполнения вышеуказанных условий войдите на удаленный сервер с ключами SSH, либо как root, либо с учетной записью с привилегиями sudo .Откройте файл конфигурации демона SSH:
Судо нано / и т. Д. / Ssh / sshd_config
Внутри файла найдите директиву PasswordAuthentication . Это можно закомментировать. Раскомментируйте строку и установите значение «нет». Это отключит вашу возможность входить в систему через SSH, используя пароли учетной записи:
Пароль Нет аутентификации
Сохраните и закройте файл, когда закончите. Чтобы действительно реализовать только что внесенные изменения, необходимо перезапустить службу.
На машинах Ubuntu или Debian вы можете ввести эту команду:
sudo service ssh перезапуск
На машинах CentOS / Fedora демон называется sshd :
sudo service sshd перезапуск
После завершения этого шага вы успешно перевели ваш демон SSH так, чтобы он отвечал только на ключи SSH.
Заключение
Теперь у вас должна быть настроена и запущена аутентификация на основе ключей SSH на вашем сервере, что позволяет вам входить в систему без предоставления пароля учетной записи.Отсюда вы можете двигаться по многим направлениям. Если вы хотите узнать больше о работе с SSH, ознакомьтесь с нашим руководством по основам SSH.
Как настроить SSH-вход без пароля
Secure Shell (SSH) — это криптографический сетевой протокол, используемый для безопасного соединения между клиентом и сервером и поддерживающий различные механизмы аутентификации. Двумя наиболее популярными механизмами являются аутентификация на основе паролей и аутентификация на основе открытого ключа.
В этом руководстве мы покажем вам, как настроить аутентификацию на основе ключа SSH, а также как подключиться к вашему серверу Linux без ввода пароля.
Настройка SSH-входа без пароля #
Чтобы настроить SSH-вход без пароля в Linux, все, что вам нужно сделать, — это сгенерировать открытый ключ аутентификации и добавить его в файл удаленных хостов ~ / .ssh / authorized_keys .
Следующие шаги описывают процесс настройки входа по SSH без пароля:
Проверьте существующую пару ключей SSH.
Перед созданием новой пары ключей SSH сначала проверьте, есть ли у вас уже ключ SSH на клиентском компьютере, потому что вы не хотите перезаписывать существующие ключи.
Выполните следующую команду ls, чтобы проверить, присутствуют ли существующие ключи SSH:
ls -al ~ / .ssh / id _ *. PubЕсли есть существующие ключи, вы можете использовать их и пропустить следующий шаг или создайте резервную копию старых ключей и создайте новый.
Если вы видите
Нет такого файла или каталогаилисовпадений не найдено, это означает, что у вас нет ключа SSH, и вы можете перейти к следующему шагу и сгенерировать новый.Создайте новую пару ключей SSH.
Следующая команда сгенерирует новую 4096-битную пару ключей SSH с вашим адресом электронной почты в качестве комментария:
ssh-keygen -t rsa -b 4096 -C "[email protected]"Нажмите
Введитечтобы принять расположение файла и имя файла по умолчанию:Введите файл, в котором следует сохранить ключ (/home/yourusername/.ssh/id_rsa):Затем инструмент
ssh-keygenпопросит вас ввести безопасный пароль. Независимо от того, хотите ли вы использовать кодовую фразу, решать вам, если вы решите использовать кодовую фразу, вы получите дополнительный уровень безопасности.В большинстве случаев разработчики и системные администраторы используют SSH без парольной фразы, поскольку они полезны для полностью автоматизированных процессов. Если вы не хотите использовать кодовую фразу, просто нажмите, введите.Введите кодовую фразу (пусто, если кодовая фраза отсутствует):Все взаимодействие выглядит следующим образом:
Чтобы быть уверенным, что ключи SSH сгенерированы, вы можете перечислить свои новые закрытые и открытые ключи с помощью:
ls ~ / .ssh / id_ */ home / yourusername /.ssh / id_rsa /home/yourusername/.ssh/id_rsa.pubСкопируйте открытый ключ
Теперь, когда вы сгенерировали пару ключей SSH, чтобы иметь возможность войти на свой сервер без пароля, который вам нужен чтобы скопировать открытый ключ на сервер, которым вы хотите управлять.
Самый простой способ скопировать открытый ключ на сервер — использовать команду
ssh-copy-id. Тип терминала на вашем локальном компьютере:ssh-copy-id remote_username @ server_ip_addressВам будет предложено ввести
remote_usernameпароль:remote_username @ server_ip_address пароль:После аутентификации пользователя открытый ключ будет добавлен к файлу удаленного пользователя
authorized_keys, и соединение будет закрыто.Если по какой-либо причине утилита
ssh-copy-idнедоступна на вашем локальном компьютере, вы можете использовать следующую команду для копирования открытого ключа:cat ~ / .ssh / id_rsa.pub | ssh remote_username @ server_ip_address "mkdir -p ~ / .ssh && chmod 700 ~ / .ssh && cat >> ~ / .ssh / authorized_keys && chmod 600 ~ / .ssh / authorized_keys"Войдите на свой сервер, используя SSH keys
После выполнения описанных выше шагов вы сможете войти на удаленный сервер без запроса пароля.
Чтобы проверить это, просто попробуйте войти на свой сервер через SSH:
ssh remote_username @ server_ip_addressЕсли все прошло хорошо, вы сразу же войдете в систему.
Отключение аутентификации по паролю SSH #
Чтобы добавить дополнительный уровень безопасности к вашему серверу, вы можете отключить аутентификацию по паролю для SSH.
Перед отключением парольной аутентификации SSH убедитесь, что вы можете войти на свой сервер без пароля, а пользователь, с которым вы входите, имеет права sudo.
Следующие руководства описывают, как настроить доступ sudo:
Войдите на удаленный сервер с ключами SSH, либо как пользователь с привилегиями sudo, либо как пользователь root:
ssh sudo_user @ server_ip_addressОткройте SSH файл конфигурации
/ etc / ssh / sshd_config, найдите следующие директивы и измените их следующим образом:/ etc / ssh / sshd_config
PasswordAuthentication no ChallengeResponseAuthentication нет UsePAM noПо завершении сохраните файл и перезапустите службу SSH.
На серверах Ubuntu или Debian выполните следующую команду:
sudo systemctl restart sshНа серверах CentOS или Fedora выполните следующую команду:
sudo systemctl restart sshd
Заключение №
В этом руководстве вы узнали, как настроить аутентификацию на основе ключей SSH, позволяющую входить на удаленный сервер без ввода пароля пользователя. Вы можете добавить один и тот же ключ к нескольким удаленным серверам.
Мы также показали вам, как отключить аутентификацию по паролю SSH и добавить дополнительный уровень безопасности на ваш сервер.
Если у вас есть вопросы или отзывы, не стесняйтесь оставлять комментарии.
Как настроить и использовать SSH в Linux
Если вы какое-то время использовали Linux, вы, несомненно, слышали об инструменте, известном как SSH. SSH (или безопасная оболочка) — это зашифрованный сетевой инструмент, позволяющий пользователям безопасно входить в систему на различные типы компьютеров удаленно по сети.В этой статье мы покажем вам, как настроить и использовать SSH в Linux.
Установка SSH
Для начала нам нужно установить SSH-сервер. Вы можете найти и установить пакет openssh-server в Центре программного обеспечения или в диспетчере пакетов. В качестве альтернативы, если вы работаете на сервере (или просто предпочитаете использовать терминал), откройте терминал и введите следующую команду:
# Ubuntu / Debian sudo apt установить openssh-server # Fedora / CentOS / REHL sudo dnf установить openssh-server
Включить SSH в Linux
После того, как сервер OpenSSH будет установлен на вашем компьютере, вам нужно будет запустить и включить модуль systemd.Для этого вы можете просто ввести в терминал следующую команду:
sudo systemctl enable --now ssh
Подключение через SSH через локальную сеть
Подключиться к удаленной системе через SSH очень просто. Сначала определите IP-адрес сервера. Для этого введите в терминал следующую команду и нажмите ввод:
После того, как вы определите IP-адрес машины, вы сможете войти в систему. Вернитесь к машине, с которой вы пытаетесь войти, и введите следующую команду:
Примечание. измените «username» на имя пользователя, которым вы пытаетесь стать в удаленной системе.
Оттуда вам будет предложено ввести пароль того же пользователя, и вы будете в бизнесе. Вы можете получить какое-то страшное предупреждение о том, что удаленная система является ненадежным пользователем, но если вы знаете, что это ваша собственная система, просто введите yes .
Вы вошли в систему! Вы заметите, что ваша подсказка изменилась в терминале — это признак успеха.
Создание ключей
Создание ключей SSH и настройка входа в систему с помощью ключа — это немного сложнее, чем просто вход с паролем, но это, безусловно, выполнимо и делает вход в систему намного более безопасным.Ключ, который находится на вашем устройстве, — это то, что аутентифицирует вас, поэтому вы можете отключить аутентификацию по паролю в удаленной системе и просто войти в систему с помощью ключей.
Для этого вам необходимо создать новую пару ключей в своей клиентской системе, скопировать открытый ключ в удаленную систему и убедиться, что ключ в удаленной системе является доверенным. В целом это очень простой процесс.
В системе, которую вы используете для входа в удаленную систему, выполните следующую команду:
ssh-keygen -t rsa -f ~ /.ssh / id_rsa
Вам будет предложено создать кодовую фразу. Я настоятельно рекомендую сделать один безопасный, который вы также запомните. Вот как вы будете входить в систему на компьютере, поэтому сделайте его максимально безопасным. Он будет сохранен в папке, которую программа SSH знает, что искать.
Теперь, все еще находясь в вашей основной системе, используйте команду ssh-copy-id для передачи вашего открытого ключа в удаленную систему.
ssh-copy-id -n -i ~ / .ssh / id_rsa ИМЯ ПОЛЬЗОВАТЕЛЯ @ IP-АДРЕС
Измените имя пользователя и IP-адрес на те, которые вы использовали ранее.Это покажет вам ключи, которые были бы переданы, если бы вы действительно выполнили команду. Если он похож на нужный вам ключ, удалите флаг -n , и команда запустится.
Теперь вы можете войти в удаленную систему без ввода пароля.
Теперь, когда вы настроили и использовали SSH, следующее, что вам нужно сделать, это защитить конфигурацию SSH. Кроме того, если вы используете Windows, узнайте, как вы можете сгенерировать пару ключей SSH в Windows.
Связанный:
Джон Перкинс
Джон — молодой технический специалист, стремящийся обучать пользователей наилучшим способам использования их технологий.Он имеет технические сертификаты по различным темам, от компьютерного оборудования до кибербезопасности и системного администрирования Linux.
Эта статья полезна?
да
Нет
Файл конфигурации
SSH для клиента OpenSSH
Эта страница посвящена настройке клиента OpenSSH.Для конфигурации сервера OpenSSH см. Sshd_config. Для настройки Tectia SSH см. Руководство администратора сервера Tectia SSH. Для настройки аутентификации с открытым ключом без пароля см. Ssh-keygen.
Программа ssh на хосте получает свою конфигурацию либо из командной строки, либо из файлов конфигурации ~ / .ssh / config и / etc / ssh / ssh_config .
Параметры командной строки имеют приоритет над файлами конфигурации. Пользовательский файл конфигурации ~ /.Далее используется ssh / config . Наконец, используется глобальный файл / etc / ssh / ssh_config . Будет использовано первое полученное значение для каждого параметра конфигурации.
Часто используемые параметры конфигурации
Доступно множество вариантов конфигурации. На практике изменяются лишь некоторые из них, а файлы конфигурации для конкретных пользователей используются редко. В большинстве случаев редактируется просто / etc / ssh / ssh_config .
Включение пересылки X11 и пересылки агентов
Разработчики, студенты и исследователи часто хотят включить пересылку X11 и пересылку агентов SSH.Это позволяет удаленно запускать графические приложения и избавляет от необходимости вводить пароль при переходе с одного сервера на другой, соответственно. Установка этих параметров в / etc / ssh / ssh_config упрощает жизнь конечным пользователям, сокращает накладные расходы и снижает нагрузку на поддержку. Однако они увеличивают риск распространения атаки со скомпрометированного сервера на рабочий стол пользователя, поэтому в наиболее критичных для безопасности средах можно оставить их отключенными. Обычно нет причин включать их на производственных серверах предприятий.
ForwardAgent да
ForwardX11 да Перенаправление портов
Перенаправление локальных и удаленных портов можно использовать для туннелирования приложений, доступа к веб-службам интрасети из дома, туннелирования доступа к базе данных и многих других целей. Инструкции по настройке переадресации портов см. На странице конфигурации переадресации портов. Однако обратите внимание, что переадресация портов также может использоваться для туннелирования трафика из внешнего Интернета в корпоративную интрасеть. Иногда сотрудники делают это, чтобы иметь возможность работать из дома, даже если политика компании этого не допускает.Хакеры используют его, чтобы оставить постоянный бэкдор. См. Страницу о SSH-туннелировании для получения дополнительной информации.
Настройка аутентификации с открытым ключом
Публичная аутентификация используется для входа между системами без пароля. Он часто используется для автоматизированных процессов, таких как резервное копирование, управление конфигурацией и передача файлов. Он также используется опытными конечными пользователями и системными администраторами для единого входа. См. Аутентификацию с открытым ключом для ее настройки.
Когда пользователь создал более одного ключа SSH для аутентификации, параметр командной строки -i может быть полезен для указания того, какой ключ использовать.В файле конфигурации клиента это можно указать с помощью параметров IdentityFile .
Аутентификация на основе сертификатов
Сертификаты
OpenSSH могут использоваться для аутентификации либо с помощью ssh-agent, либо путем указания опции CertificateFile в файле конфигурации клиента. См. Дополнительные сведения в сертификатах SSH.
Формат файла конфигурации клиента SSH
ssh_config
Файл конфигурации клиента ssh_config имеет следующий формат.И глобальный / etc / ssh / ssh_config , и индивидуальный ~ / ssh / config имеют одинаковый формат.
Пустые строки и строки, начинающиеся с символа «#», являются комментариями.
Каждая строка начинается с ключевого слова, за которым следуют аргументы.
Параметры конфигурации могут быть разделены пробелом или необязательным пробелом и ровно одним =.
Аргументы можно заключать в двойные кавычки («), чтобы указать аргументы, содержащие пробелы.
Список опций конфигурации клиента
Следующие ключевые слова могут использоваться в файлах конфигурации клиента SSH. Ключевые слова нечувствительны к регистру, а аргументы чувствительны к регистру. Любые имена алгоритмов или методов, содержащие знак (@), предназначены только для экспериментального использования и не рекомендуются для производства.
Хост
Ограничивает следующие объявления только для тех хостов, которые соответствуют одному из шаблонов, указанных после ключевого слова.Шаблон сопоставляется с именем хоста, указанным в командной строке.
Match
Ограничивает применение следующих объявлений только к узлам, которые соответствуют указанным критериям. Для получения подробной информации см. Справочную страницу SSH.
AddressFamily
Указывает, какое семейство адресов использовать при подключении. Допустимые аргументы: любой , inet , inet6 .
BatchMode
Если установлено значение да , запрос парольной фразы / пароля будет отключен.Это полезно для запуска клиента ssh из сценария оболочки, у которого нет интерактивного пользователя, и предотвращает случайную блокировку при запросе пароля.
BindAddress
Задает использование указанного адреса на локальном компьютере в качестве исходного адреса соединения.
ChallengeResponseAuthentication
Указывает, следует ли использовать аутентификацию запрос-ответ. Это в основном устаревший метод, который был заменен на KbdInteractiveAuthentication .
CheckHostIP
Указывает ssh на дополнительную проверку IP-адреса хоста в файле known_hosts .
Cipher
Определяет шифр, который будет использоваться для шифрования сеанса в версии протокола 1. Обратите внимание, что использование протокола 1 не рекомендуется.
Шифры
Задает шифрование, разрешенное для версии протокола 2, в порядке предпочтения. Несколько шифров должны быть разделены запятыми. Команду ssh -Q cipher можно использовать для запроса поддерживаемых шифров.В OpenSSH 6.7 поддерживается следующий список:
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
[email protected]
aes128-ctr
aes192-ctr
aes256-ctr
[email protected]
[email protected]
[email protected] ClearAllForwardings
Задает очистку всех локальных, удаленных и динамических перенаправлений портов, указанных в файлах конфигурации или в командной строке.
Сжатие
Указывает, следует ли использовать сжатие. да включает сжатие.
CompressionLevel
Определяет уровень сжатия, который будет использоваться, если сжатие включено.
ConnectionAttempts
Задает количество попыток перед выходом.
ConnectTimeout
Указывает время ожидания (в секундах), используемое при подключении к серверу SSH, вместо использования системного тайм-аута TCP по умолчанию.
ControlMaster
Обеспечивает совместное использование нескольких сеансов через одно сетевое соединение.
ControlPath
Укажите путь к управляющему сокету, используемому для совместного использования соединения, как описано в разделе ControlMaster выше, или строку none , чтобы отключить совместное использование соединения.
DynamicForward
Указывает, что TCP-порт на локальном компьютере будет перенаправлен по безопасному каналу, а затем протокол приложения используется для определения того, куда подключиться с удаленного компьютера.
EscapeChar
Устанавливает escape-символ.
ExitOnForwardFailure
Определяет, должен ли ssh завершать соединение, если он не может установить все запрошенные динамические, туннельные, локальные и удаленные переадресации портов.
ForwardAgent
Указывает, будет ли соединение с агентом аутентификации перенаправляться на удаленный компьютер.
ForwardX11
Указывает, будут ли соединения X11 автоматически перенаправляться по защищенному каналу и заданы параметры DISPLAY.
ForwardX11Trusted
Если для этого параметра установлено значение да , удаленные клиенты X11 будут иметь полный доступ к исходному дисплею X11.
GatewayPorts
Указывает, разрешено ли удаленным хостам подключаться к локальным перенаправленным портам.
GlobalKnownHostsFile
Задает файл, который будет использоваться для глобальной базы данных ключей хоста вместо / etc / ssh / ssh_known_hosts .
GSSAPIAuthentication
Указывает, разрешена ли аутентификация пользователя на основе GSSAPI.GSSAPI обычно используется для аутентификации Kerberos, например, с Active Directory.
GSSAPIKeyExchange
Указывает, может ли использоваться обмен ключами на основе GSSAPI.
GSSAPIClientIdentity
Если установлено, задает идентификатор клиента GSSAPI, который ssh должен использовать при подключении к серверу.
GSSAPIDelegateCredentials
Пересылать (делегировать) учетные данные на сервер.
GSSAPIRenewalForcesRekey
Если установлено значение да , то обновление учетных данных клиента GSSAPI приведет к смене ключей для ssh-соединения.
GSSAPITrustDns
Установите значение да , чтобы указать, что DNS доверяет надежно канонизировать имя хоста, к которому выполняется подключение. Если нет , имя хоста, введенное в командной строке, будет передано в библиотеку GSSAPI без изменений.
HashKnownHosts
Указывает, что ssh должен хэшировать имена и адреса хостов, когда они добавляются в ~ / .ssh / known_hosts . Эти хешированные имена могут обычно использоваться ssh и sshd, но они не раскрывают идентифицирующую информацию в случае раскрытия содержимого файла.
HostbasedAuthentication
Указывает, следует ли пробовать аутентификацию на основе rhosts с аутентификацией с открытым ключом, используя файлы .rhosts или .shosts в домашнем каталоге пользователя и /etc/hosts.equiv и / etc / shosts.equiv в глобальной комплектации.
HostKeyAlgorithms
Задает алгоритмы ключей хоста версии 2 протокола, которые клиент хочет использовать в порядке предпочтения.В OpenSSH 6.7 поддерживаются следующие значения:
ssh-ed25519
[email protected]
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
HostKeyAlias
Задает псевдоним, который следует использовать вместо реального имени хоста при поиске или сохранении ключа хоста в файлах базы данных ключей хоста.
HostName
Указывает реальное имя хоста для входа. Это можно использовать для указания псевдонимов или сокращений для хостов. По умолчанию используется имя, указанное в командной строке. Также разрешены числовые IP-адреса (как в командной строке, так и в спецификациях HostName).
IdentitiesOnly
Указывает, что ssh должен использовать только ключи идентификации, настроенные в файлах ssh_config , даже если ssh-agent предлагает больше идентификаторов.
IdentityFile
Задает файл, из которого считывается идентификационный ключ пользователя при использовании аутентификации с открытым ключом. Значение по умолчанию для версии протокола 1 — ~ / .ssh / identity ; и ~ / .ssh / id_rsa или ~ / .ssh / id_dsa для версии протокола 2.
KbdInteractiveAuthentication
Указывает, использовать ли интерактивную аутентификацию с клавиатуры. Это распространенный метод аутентификации по паролю, одноразовых паролей и многофакторной аутентификации.
KbdInteractiveDevices
Задает список методов, используемых при интерактивной аутентификации с помощью клавиатуры.
LocalCommand
Задает команду для выполнения на локальном компьютере после успешного подключения к серверу.
LocalForward
Указывает, что TCP-порт на локальном компьютере будет перенаправлен по защищенному каналу на указанный хост и порт с удаленного компьютера. Первый аргумент должен быть [bind_address:] порт , а второй аргумент должен быть host: port .
LogLevel
Определяет уровень детализации сообщений журнала от ssh. Возможные значения: QUIET , FATAL , ERROR , INFO , VERBOSE , DEBUG , DEBUG1 , DEBUG2 и DEBUG3 .
MAC
Определяет алгоритмы MAC (код аутентификации сообщения) в порядке предпочтения. Команду ssh -Q mac можно использовать для запроса поддерживаемых алгоритмов MAC.В OpenSSH 6.7 поддерживается следующий список:
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
hmac-ripemd160
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected] NoHostAuthenticationForLocalhost
Этот параметр можно использовать, если домашний каталог является общим для всех компьютеров.В этом случае localhost будет ссылаться на разные машины на каждой из машин, и пользователь получит множество предупреждений об изменении ключей хоста.
PreferredAuthentication
Определяет порядок, в котором клиент должен пробовать методы аутентификации по протоколу 2.
Протокол
Задает версии протокола в порядке предпочтения. Возможные значения: «1» и «2». Несколько версий следует разделять запятыми. Использование протокола версии 1 НЕ РЕКОМЕНДУЕТСЯ из соображений безопасности.Есть основания полагать, что он может быть уязвим для атак «злоумышленник посередине».
ProxyCommand
Задает команду, которая будет использоваться для подключения к серверу. Клиент SSH взаимодействует с командой прокси, используя свой стандартный ввод и стандартный вывод, а команда прокси должна передавать сообщение на сервер SSH.
PubkeyAuthentication
Указывает, следует ли пробовать аутентификацию с открытым ключом с использованием ключей SSH. Допустимые значения: да и нет .Когда в производственной среде используется аутентификация с открытым ключом, также должна быть внедрена надлежащая система управления ключами SSH.
RemoteForward
Указывает, что TCP-порт на удаленном компьютере будет перенаправлен по защищенному каналу на указанный хост и порт с локального компьютера. Первый аргумент должен быть: [адрес_вязывания:] порт , а второй аргумент должен быть хост: порт . SSH-туннелирование — мощный инструмент, но ознакомьтесь с соображениями безопасности при SSH-туннелировании.
RhostsRSAAuthentication
Указывает, следует ли пробовать аутентификацию на основе Rhosts с аутентификацией хоста RSA. Это только для протокола версии 1 и не рекомендуется.
RSAAuthentication
Указывает, следует ли пробовать проверку подлинности RSA. Это только для протокола версии 1 и не рекомендуется.
SendEnv
Задает, какие переменные среды должны быть отправлены на сервер.
ServerAliveCountMax
Устанавливает количество сообщений поддержки активности, которые могут быть отправлены клиентом без получения клиентом каких-либо сообщений от сервера.Когда этот порог будет достигнут, клиент завершит сеанс.
ServerAliveInterval
Определяет интервал для отправки сообщений keepalive на сервер. Сообщения отправляются через зашифрованный канал и служат для обнаружения сбоя сервера или отказа сети.
SmartcardDevice
Указывает, какое устройство смарт-карты использовать.
StrictHostKeyChecking
Указывает, не следует ли ssh автоматически добавлять ключи хоста в ~ /.ssh / known_hosts и отказывается подключаться к хостам, чей ключ хоста изменился.
TCPKeepAlive
Указывает, следует ли отправлять пакеты проверки активности TCP на другую сторону. Они работают на уровне протокола TCP. Отправка сообщений keepalive помогает правильно закрыть сокет при выходе из строя сети или сервера. С другой стороны, без него соединение может оставаться активным и любые окна открываться, даже если сеть на некоторое время отключена.
Туннель
Если да , запросить пересылку устройства tun между клиентом и сервером.Это используется для реализации VPN через SSH.
TunnelDevice
Задает устройства tun для открытия на клиенте ( local_tun ) и сервере ( remote_tun ).
UsePrivilegedPort
Указывает, следует ли использовать привилегированный порт для исходящих подключений. Чтобы использовать привилегированный порт, клиент должен работать как root. Привилегированный порт необходим для аутентификации на основе хоста.
UserKnownHostsFile
Задает файл, который будет использоваться для базы данных известных ключей хоста для каждого пользователя вместо стандартного ~ /.SSH / известные_узлы .
VerifyHostKeyDNS
Указывает, нужно ли проверять удаленный ключ с помощью записей ресурсов DNS и SSHFP.
VisualHostKey
Указывает, печатается ли художественное представление отпечатка ключа удаленного хоста в формате ASCII в дополнение к шестнадцатеричной строке отпечатка пальца при входе в систему и для неизвестных ключей хоста.
Как установить и настроить сервер OpenSSH в Linux
Для того, чтобы быть сетевым администратором, необходимы глубокие знания протоколов удаленного входа в систему, таких как rlogin , telnet и ssh .В этой статье я расскажу о ssh , защищенном удаленном протоколе, который используется для удаленной работы на других машинах или передачи данных между компьютерами с помощью команды SCP (Secure Copy). Но что такое OpenSSH и как его установить в дистрибутив Linux ?
Установите OpenSSH в Linux
Что такое OpenSSH?
OpenSSH — это бесплатный набор компьютерных инструментов с открытым исходным кодом, используемых для обеспечения безопасной и зашифрованной связи по компьютерной сети с использованием протокола ssh .Многие люди, плохо знакомые с компьютерами и протоколами, создают неправильное представление о OpenSSH , они думают, что это протокол, но это не так, это набор компьютерных программ, которые используют протокол ssh .
OpenSSH разработан группой Open BSD и выпущен под лицензией Simplified BSD License . Основным фактором, благодаря которому OpenSSH стало широко использоваться системными администраторами, является его многоплатформенность и очень полезные приятные функции.Последняя версия — OpenSSH 6.4 , выпущенная 8 ноября 2013 г. .
Эта версия OpenSSH поставляется с множеством новых функций и исправлений, поэтому, если вы уже используете OpenSSH для администрирования своих машин, я предлагаю вам выполнить обновление.
Зачем использовать OpenSSH и через Telnet или FTP?
Самая важная причина, по которой следует использовать инструменты OpenSSH вместо ftp и telnet , заключается в том, что все коммуникации и учетные данные пользователей, использующие OpenSSH , зашифрованы, они также защищены от атак посредника.Если третье лицо пытается перехватить ваше соединение, OpenSSH обнаруживает его и сообщает вам об этом.
Каковы некоторые особенности OpenSSH?
- Безопасная связь
- Надежное шифрование ( 3DES , Blowfish , AES , Arcfour )
- X11 Пересылка (шифрование трафика оконной системы X )
- Перенаправление портов (зашифрованные каналы для устаревших протоколов)
- Строгая проверка подлинности ( Открытый ключ , одноразовый пароль и проверка подлинности Kerberos)
- Переадресация агентов (, единый вход, )
- Взаимодействие (соответствие SSH 1.3, 1.5 и 2.0 Стандарты протокола )
- Поддержка клиента и сервера SFTP в протоколах SSh2 и SSh3 .
- Kerberos и Прохождение билетов AFS
- Сжатие данных
Установка OpenSSH в Linux
Чтобы установить OpenSSH , откройте терминал и выполните следующие команды с разрешениями суперпользователя.
В Ubuntu / Debian / Linux Mint
$ sudo apt-get install openssh-server openssh-client
На RHEL / Centos / Fedora
Введите следующую команду yum , чтобы установить клиент и сервер openssh.
# yum -y установить openssh-server openssh-clients
Конфигурация OpenSSH
Пришло время настроить поведение OpenSSH с помощью файла ssh config , но перед редактированием файла / etc / ssh / sshd_config нам нужно сделать резервную копию его копии, поэтому на случай ошибки у нас есть оригинал.
Откройте терминал и выполните следующую команду, чтобы сделать копию исходного файла конфигурации sshd.
$ sudo cp / etc / ssh / sshd_config / etc / ssh / sshd_config.original_copy
Как видно из набранной мной команды, я добавил суффикс original_copy , поэтому каждый раз, когда я вижу этот файл, я знаю, что это исходная копия файла конфигурации sshd.
Как подключиться к OpenSSH
Прежде чем мы продолжим, нам нужно проверить, работает ли наш сервер openssh или нет. Как это сделать? Вы можете попытаться подключиться к серверу openssh со своего localhost через клиент openssh или выполнить сканирование портов с помощью nmap , но мне нравится использовать небольшой инструмент под названием netcat , также известный как TCP / IP Швейцарский армейский нож.Мне нравится работать с этим удивительным инструментом на моей машине, поэтому позвольте мне показать его вам.
# нк -v -z 127.0.0.1 22
Ссылаясь на результаты netcat , служба ssh работает на порту 22 на моем компьютере. Отлично! Что, если мы хотим использовать другой порт вместо 22 ? Мы можем сделать это, отредактировав файл конфигурации sshd.
Настройте свой OpenSSH на прослушивание порта TCP 13 вместо порта TCP по умолчанию 22 .Откройте файл sshd_config в своем любимом текстовом редакторе и измените директиву порта на 13 .
# Какие порты, IP и протоколы мы слушаем Порт 13
Перезапустите сервер OpenSSH , чтобы изменения в файле конфигурации могли произойти. Для этого введите следующую команду и запустите netcat , чтобы проверить, открыт ли порт, который вы установили для прослушивания.
$ sudo /etc/init.d/ssh перезапуск
Должны ли мы проверить, прослушивает ли наш openssh-сервер порт 13 или нет?Эта проверка необходима, поэтому я звоню своему прекрасному инструменту netcat , чтобы помочь мне выполнить эту работу.
# нк -v -z 127.0.0.1 13
Вы хотите, чтобы на вашем сервере openssh отображался красивый баннер для входа в систему? Вы можете сделать это, изменив содержимое файла /etc/issue.net и добавив следующую строку в файл конфигурации sshd.
Баннер /etc/issue.net
Заключение
Есть много вещей, которые вы можете сделать с помощью инструментов openssh , когда дело доходит до того, как вы настраиваете свой сервер openssh , я могу сказать, что ваше воображение — это предел !.
Читайте также: 5 рекомендаций по обеспечению безопасности и защиты сервера OpenSSH
Если вы цените то, что мы делаем здесь, на TecMint, вам следует принять во внимание:
TecMint — это самый быстрорастущий и пользующийся наибольшим доверием сайт сообщества, где можно найти любые статьи, руководства и книги по Linux в Интернете. Миллионы людей посещают TecMint! для поиска или просмотра тысяч опубликованных статей доступны БЕСПЛАТНО для всех.
Если вам нравится то, что вы читаете, пожалуйста, купите нам кофе (или 2) в знак признательности.
Мы благодарны вам за постоянную поддержку.
Защитите SSH-сервер в Ubuntu
Содержание
Введение
Secure Shell (SSH) — это протокол, используемый для обеспечения безопасной и зашифрованной связи по сети. Он наиболее широко используется системными администраторами Linux для удаленного управления сервером. Его также можно использовать для передачи файлов по сети. Поэтому безопасность SSH очень важна.
Требования
- Сервер под управлением Ubuntu v.14.04
- Настольный компьютер под управлением Linux (рекомендуется)
Установка SSH
Чтобы установить SSH-сервер на свой сервер, выполните следующую команду:
sudo apt-get install openssh-server
Чтобы установить клиент SSH на рабочий стол, выполните следующую команду:
sudo apt-get install openssh-client
Настроить SSH для входа с ключами SSH вместо пароля
Использование паролей для аутентификации SSH небезопасно.Если один из ваших пользователей установит слабый пароль, ваш сервер может быть скомпрометирован. Чтобы этого избежать, вы можете использовать ssh-ключ для аутентификации без пароля.
Сгенерировать ключи SSH
Чтобы сгенерировать ключи SSH на клиентском компьютере, выполните следующую команду:
кд ~ / .ssh
ssh-keygen -t rsa
Просто нажимайте клавишу ввода при каждом вопросе. Это создаст два файла: id_rsa.pub (открытый ключ) и id_rsa (закрытый ключ).
Будет выведено что-то вроде.
Создать папку SSH
На вашем сервере создайте папку для SSH с помощью команды:
mkdir -p ~ / .ssh /
Скопируйте файл открытого ключа на свой сервер
На рабочем столе скопируйте файл id_dsa.pub на свой сервер, используя следующую команду:
scp -P "ssh-port" ~ / .ssh / id_dsa.pub имя пользователя @ serverip-адрес: ~ / .ssh
Обновить файл открытого ключа
Измените имя файла и разрешения:
кот ~ /.ssh / id_rsa.pub >> ~ / .ssh / authorized_keys
chmod 700 .ssh
chmod 600 .ssh / authorized_keys
rm .ssh / id_rsa.pub
Теперь вы можете войти на свой SSH-сервер без пароля.
Выполните следующую команду со своего рабочего стола, чтобы проверить ее.
ssh -P "ssh-port" имя пользователя @ ip-адрес сервера
Защитите файл конфигурации SSH
Вы можете изменить параметры безопасности по умолчанию, отредактировав / etc / ssh / sshd_config .
Судо нано / и т. Д. / Ssh / sshd_config
Вот несколько предложений по настройкам по умолчанию, которые вы, возможно, захотите изменить.
После внесения изменений обязательно сохраните и выйдите из файла sshd_config и перезапустите сервер SSH с помощью:
sudo service ssh перезапуск
Изменить порт SSH по умолчанию
По умолчанию большинство серверов прослушивают SSH-соединения на порту 22 . Хакеры могут использовать сканер портов, чтобы определить, работает ли служба SSH или нет. Поэтому рекомендуется изменить порт по умолчанию.
Чтобы изменить порт по умолчанию с 22 на 8908 , измените следующую строку:
Порт 8908
Использовать СШ3
Протокол SSH 1 (SSh2) содержит множество уязвимостей.Вместо этого настоятельно рекомендуется использовать протокол 2 (SSh3).
По умолчанию должен быть установлен SSh3. Если нет, измените строку Protocol на использование SSh3.
Протокол 2
Используйте белый список и черный список для ограничения доступа пользователей
Использование белого списка для разрешения доступа по SSH определенным пользователям и черного списка для запрета другим пользователям повысит вашу безопасность SSH.
Чтобы разрешить validuser1 и validuser2 , добавьте следующую строку:
AllowUsers validuser1 validuser2
Чтобы запретить baduser1 и baduser2 , добавьте следующую строку:
DenyUser baduser1 baduser2
Отключить вход root
Обычная атака — попытка использовать root для входа на сервер с SSH.Поскольку это большой риск для безопасности, отключите вход в систему по SSH с правами root, изменив PermitRootLogin с без пароля на:
PermitRootLogin нет
Скрыть последний вход
Вы можете скрыть последнего авторизованного пользователя, отредактировав следующую строку.
PrintLastLog нет
Ограничить вход по SSH определенным IP-адресам
По умолчанию SSH принимает соединения с любого внешнего IP-адреса. Если вы хотите ограничить SSH, чтобы разрешить соединение только с определенного IP-адреса, вы можете добавить строку ListenAddress .
Например, если вы хотите принимать SSH-соединения только с IP-адреса 192.168.1.2, вы должны добавить строку:
ListenAddress 192.168.1.2 Отключить аутентификацию по паролю
Парольная аутентификация в SSH представляет собой большую угрозу безопасности, если ваш пользователь устанавливает слабый пароль. В этом разделе приведены инструкции по настройке аутентификации по ключу SSH
.
Чтобы отключить аутентификацию по паролю, измените строку PasswordAuthentication на:
Пароль Нет аутентификации
Отключить.Rhosts
По умолчанию SSH не разрешает роутов . Файлы .rhosts определяют, какие пользователи могут получить доступ к r-командам (например, rcp и rsh ) в локальной системе без пароля.
Для отключения ростов :
Игнорировать хосты да
RhostsAuthentication нет
RSAAuthentication да
Отключить аутентификацию на основе хоста
Аутентификация на основе хоста
SSH более безопасна, чем аутентификация rhosts .Однако доверенные хосты по-прежнему считаются угрозой безопасности.
По умолчанию опция HostbasedAuthentication отключена, в противном случае измените следующую строку:
Hostbased Аутентификация нет
Установить тайм-аут отсрочки входа
«LoginGraceTime» указывает, сколько времени после запроса на соединение сервер SSH будет ждать перед отключением. Рекомендуемое значение для тайм-аута отсрочки входа — 60 секунд.
Вы можете изменить это значение, отредактировав следующую строку:
LoginGraceTime 60
Установить максимальное количество подключений при запуске
Ограничение максимального количества одновременных подключений к демону SSH может помочь защитить ваш SSH-сервер от атаки методом грубой силы.
Вы можете установить это значение, отредактировав следующую строку, указав количество одновременных подключений, которые вы хотите разрешить. В этом примере мы выбрали 2:
MaxStartups 2
Отключить пересылку
Хакеры могут использовать технику переадресации портов для туннелирования сетевых подключений через сеанс SSH для входа в системы.
Чтобы отключить это изменение, следующие строки:
AllowTcpForwarding no
X11 Нет пересылки
Журнал дополнительной информации
По умолчанию SSH регистрирует все.Если вы хотите регистрировать дополнительную информацию, например, о неудачных попытках входа в систему. вы можете изменить значение с INFO на VERBOSE .
Для этого измените следующую строку:
LogLevel VERBOSE
Отключить пустые пароли
Вы захотите запретить вход пользователям с пустым (пустым) паролем.
По умолчанию эта опция отключена, в противном случае измените следующую строку:
PermitEmptyPasswords нет
Установить интервал ожидания простоя
SSH позволяет пользователям устанавливать интервал ожидания простоя.По истечении этого интервала бездействующий пользователь автоматически выходит из системы.
Вы можете установить количество секунд, добавив следующую строку:
ClientAliveInterval 300
ClientAliveCountMax 0
Перезапустите SSH, чтобы изменения вступили в силу
После того, как вы закончили редактировать файл / etc / ssh / sshd_config , сохраните и выйдите из огня, затем перезапустите сервер SSH:
sudo service ssh перезапуск
Безопасный SSH с использованием TCP-оболочек
Оболочка
TCP обеспечивает управление доступом к сетевым службам на основе хоста, которое используется для фильтрации сетевого доступа к Интернету.
Вы можете разрешить SSH только с IP-адресов 192.168.1.100 и 172.16.20.10, отредактировав файл /etc/hosts.allow .
судо нано /etc/hosts.allow
Добавьте следующую строку:
sshd: 192.168.1.100 172.16.20.10
Безопасный SSH с использованием iptables
Вы можете ограничить SSH-соединение, чтобы разрешить только авторизованные IP-адреса.
Чтобы разрешить SSH-соединения только с 192.168.1.200, выполните следующую команду:
sudo iptables -A INPUT -p tcp -m state --state NEW --source 192.168.1.200 --dport 8908 -j ПРИНЯТЬ
Чтобы отключить SSH-соединение со всех остальных хостов, выполните следующую команду:
sudo iptables -A INPUT -p tcp --dport 8908 -j DROP
Теперь сохраните ваши новые правила, используя следующую команду:
Судо iptables-save> /etc/iptables/rules.v4
.