Включение доступ root в ubuntu ssh. Что можно поменять в настройках SSH. Кроссплатформенный SSH-клиент с графическим интерфейсом PuTTY.

Эта статья помечена как незаконченная. См. заметку в конце статьи.

Данная статья посвящена клиенту и серверу защищенного терминала (secure shell) в Ubuntu, их настройке и использованию. SSH - это специальный сетевой протокол, позволяющий получать удаленный доступ к компьютеру с большой степенью безопасности соединения. Более подробно про протокол ssh можно прочитать .

Описание принципов работы и используемых приложений

В основном, SSH реализован в виде двух приложений - SSH -сервера и SSH -клиента В Ubuntu используется свободная реализация клиента и сервера SSH - OpenSSH . При подключении клиент проходит процедуру авторизации у сервера и между ними устанавливается зашифрованное соединение. OpenSSH сервер может работать как с протоколом ssh1, так и с протоколом ssh2. В настоящее время протокол ssh1 считается небезопасным, поэтому его использование крайне не рекомендуется. Я намеренно опускаю различные технические подробности работы протокола, т. к. основной целью данного руководства является описание его настройки и использования. Про сам протокол, принципы его работы, алгоритмы шифрования и т. д. существует множество статей в интернете, например подробно про это можно почитать .

Установка

Установить OpenSSH можно из терминала командой:

sudo apt-get install ssh

В метапакете ssh содержится как клиент, так и сервер, но при этом, скорее всего, будет установлен только сервер, т. к. клиент уже есть в Ubuntu по умолчанию.

Настройка сервера

При установке SSH -сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:

sudo service ssh stop| start| restart

Основной файл конфигурации SSH -сервера - файл /etc/ssh/sshd_config , доступный для чтения или редактирования только суперпользователю . После каждого изменения этого файла необходимо перезапустить ssh-сервер для применения таких изменений.

Пример конфигурации SSH -сервера в Ubuntu по умолчанию :

# Пример конфигурации open-ssh сервера с русскими # # комментариями..2010. # # # # # # Условные обозначения: # # Под "по умолчанию" - подразумевается поведение sshd при # # неуказанной явно директиве. Стоит заметить, что в Ubuntu # # файл sshd_config уже содержит ряд настроек, которые # # являются настройками по умолчанию для именно для Ubuntu. # # Такие настройки указаны в этом файле. # # # ############################################################ ################ Настройки адресов/портов и т.д. ########### ############################################################ # # ## Port #################################################### # # # Используемый порт. Можно указывать несколько, например: # # Port 22 # # Port 23 # # Port 24 # # Рекомендуется использовать нестандартный порт, т.к. # # стандартный часто сканируется ботами на предмет # # потенциальных "дырок". Может быть опущен, если задан # # через адрес. См. также параметр ListenAddress. # # # Port 22 # # ## ListenAddress ########################################### # # # Сетевой адрес, на котором "слушает" сервер. Адрес можно # # записывать так: # # ListenAddress host|IPv4_addr|IPv6_addr # # ListenAddress host|IPv4_addr:port # # ListenAddress :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 секунд. Эта директива работает только для # # протокола ssh2. # # # ## ClientAliveInterval ##################################### # # # Задает временной интервал в секундах. Если в течении # # этого интервала не было обмена данными с клиентом, sshd # # посылает сообщение по зашифрованному каналу, # # запрашивающее ответ от клиента. По умолчанию - 0, т.е. # # не посылать таких сообщений. Эта директива работает # # только для протокола ssh2. # # # ############################################################ ################ Общие опции аутентификации ################ ############################################################ # # ## 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’ - ssh1 и ssh2 # # соответственно. Возможна одновременная запись, при # # которой значения следует разделять запятыми. # # По умолчанию - “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 # # для протокола ssh1 и /etc/ssh/ssh_host_rsa_key и # # /etc/ssh/ssh_host_dsa_key для протокола ssh2. Стоит # # отметить, что sshd не станет пользоваться файлом, # # который доступен кому либо, кроме пользователя. Можно # # использовать несколько файлов с ключами, ключи “rsa1” - # # для протокола ssh1 и “dsa”/“rsa” для протокола ssh2. # # # HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # # ############################################################ ########## Опции протокола SSH версии 1 (ssh1) ############# ############################################################ # Настоятельно НЕ РЕКОМЕНДУЕТСЯ использовать протокол ssh1.# # Протокол ssh2 намного более безопасен, чем ssh1 # ############################################################ # # ## KeyRegenerationInterval ################################# # # # Для протокола ssh1 - раз в определенное время # # автоматически генерируется новый временный ключ сервера # # (если он был использован). Это сделано для # # предотвращения расшифровки перехваченных сеансов,с целью # # позже зайти с параметрами этих сеансов на машину и # # украсть ключи. Такой ключ нигде не хранится (хранится в # # оперативной памяти). Данная директива указывает период # # "жизни" ключа в секундах, после которого он будет # # сгенерирован заново. Если значение задать равным 0 - # # ключ не будет генерироваться заново. # # По умолчанию значение - 3600 (секунд). # # # KeyRegenerationInterval 3600 # # ## RhostsRSAAuthentication ################################# # # # Указывает, нужна ли аутентификация на основе файлов # # rhosts или /etc/hosts.equiv совместно с успешной # # аутентификацией хоста через RSA. # # Актуально только для протокола ssh1. # # По умолчанию - “no”. # # # RhostsRSAAuthentication no # # ## RSAAuthentication ####################################### # # # Указывает, разрешена ли "чистая" RSA-аутентификация. # # Актуально только для протокола ssh1. # # По умолчанию - “yes”. # # # RSAAuthentication yes # # ## ServerKeyBits ########################################### # # # Определяет число бит во временном ключе сервера для # # протокола ssh1. Минимальное значение 512. # # Значение по умолчанию - 1024. # ServerKeyBits 768 # # ############################################################ ########### Опции протокола SSH версии 2 (ssh2) ############ ############################################################ # # ## Ciphers ################################################# # # # Указывает алгоритмы шифрования, разрешенные для # # протокола ssh2. Несколько алгоритмов должны быть # # разделены запятыми. Поддерживаемые алгоритмы: # # “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 и # # подходит только для протокола ssh2. # # По умолчанию - "no". # # # HostbasedAuthentication no # # ## MACs #################################################### # # # Указывает допустимый алгоритм MAC (message # # authentication code). Алгоритм MAC используется # # протоколом ssh2 для защиты целостности данных. Несколько # # алгоритмов должны быть разделены запятыми. # # По умолчанию используются: # # hmac-md5,hmac-sha1,[email protected],hmac-ripemd160, # # hmac-sha1-96,hmac-md5-96 # # # ## PubkeyAuthentication #################################### # # # Указывает, разрешена ли аутентификация на основе # # публичного ключа. Актуально только для протокола ssh2. # # По умолчанию - “yes”. # # # PubkeyAuthentication yes ############################################################ #################### Опции GSSAPI ########################## ############################################################ # # ############ Применимо только для протокола ssh2 ########### # # ## 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 :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 в клиенте. # # Стоит заметить, что передача переменных возможна только # # для протокола ssh2. Переменные указываются по имени, # # можно использовать маски (‘*’ и ‘?’). Можно указывать # # несколько переменных через пробел, или разбить на # # несколько строк 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 ################################################## # # # Указывает какой файл содержит текстовый баннер, который # # будет показан пользователю ПЕРЕД процедурой # # аутентификации. Опция доступна только для протокола ssh2.# # По умолчанию - не показывает ничего. # # В 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 По умолчанию никаких подсистем # # не вызывается. Актуально только для протокола ssh2. # # # 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 есть много дополнительных полезных опций, которые желательно включить для повышения удобства работы и безопасности .

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-password . Но, при условии, что по умолчанию в Ubuntu пользователь, добавленный при установке системы имеет возможность решать все административные задачи через sudo, создавать возможность root доступа к системе через ssh - выглядит неразумно (даже при аутентификации по ключу). Рекомендуется совсем отключить. эту опцию, или применять ее только в режиме forced-commands-only . Отключить root-доступ можно так:

PermitRootLogin no

Парольная аутентификация

Разрешенная по умолчанию парольная аутентификация является практически самым примитивным способом авторизации в sshd. С одной стороны это упрощает конфигурацию и подключение новых пользователей (пользователю достаточно знать свой системный логин/пароль), с другой стороны пароль всегда можно подобрать, а пользователи часто пренебрегают созданием сложных и длинных паролей. Специальные боты постоянно сканируют доступные из интернета ssh сервера и пытаются авторизоваться на них путем перебора логинов/паролей из своей базы. Настоятельно не рекомендуется использовать парольную аутентификацию. Отключить ее можно так:

PasswordAuthentication no

Если по каким либо причинам вам все таки хочется использовать парольную аутентификацию - позаботьтесь о том, чтобы никто не мог авторизоваться с пустым паролем. Для этого задайте директиву PermitEmptyPasswords:

PermitEmptyPasswords no

Протоколы SSH1 и SSH2

Как уже было сказано, sshd может работать с протоколами SSH1 и SSH2. При этом использование небезопасного SSH1 крайне не рекомендуется. Заставить sshd работать только с протоколом SSH2 можно так:

Аутентификация на основе SSH2 RSA-ключей

Наиболее предпочтительным способом авторизации является аутентификация на основе SSH2 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]

Можно указать как один общий файл с ключами, так и по файлу на каждого пользователя. Последний способ является более удобным и безопасным, т. к. можно во-первых указывать разные комбинации ключей для каждого пользователя , а во-вторых ограничить доступ к публичному ключу пользователя. Задать файл с ключами можно при помощи директивы AuthorizedKeysFile:

AuthorizedKeysFile %h/.ssh/my_keys На клиенте в файле /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 -протокол для передачи файлов. Он предназначен для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения. Как правило, в качестве базового протокола, обеспечивающего соединение, и используется протокол SSH2. Для того чтобы включить поддержку SFTP добавьте в sshd_config строку

Subsystem sftp /usr/lib/openssh/sftp-server

По умолчанию поддержка SFTP включена.

Использование критериев. Директива Match

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 .

Т. е. user1 может быть прописан как у себя - в файле /home/user1/.ssh/keys) так и у другого пользователя, что позволит ему выполнять со своего компьютера вход как «под собой», так и под «другим»

SSH – один из важнейших инструментов системного администрирования.

SSH, или Secure Shell (безопасная оболочка) – это протокол, который используется для безопасного подключения к удаленным системам. Это самый распространенный способ подключения к удаленным Linux- и Unix-подобным серверам (например, к VPS).

В данном руководстве речь пойдет об использовании SSH для подключения к удаленной системе.

Базовый синтаксис

Для подключения к удаленной системе с помощью SSH в Linux существует одноименный инструмент – ssh.

Базовый вид команды:

ssh удаленный_хост

В данном примере фраза «удаленный_хост» заменяет IP-адрес или доменное имя хоста, к которому нужно подключиться.

Эта команда предполагает, что имя пользователя на удаленной и локальной системах совпадают.

Если же на удаленной системе установлено другое имя пользователя, его нужно указать с помощью следующего синтаксиса:

ssh имя_пользователя@удаленный_хост

После подключения к серверу необходимо указать пароль, чтобы пройти авторизацию.

Процедура создания ключей, которые можно использовать вместо пароля, будет описана позже.

Чтобы вернуться в локальную сессию, просто наберите:

Как работает SSH?

SSH работает путем подключения клиентской программы к серверу ssh.

В приведенных выше командах ssh является клиентской программой. Сервер ssh уже запущен на указанном удаленном хосте.

Если сервер ssh еще не запущен на VPS, нажмите кнопку «Console Access», которая находится на странице сервера. Это выведет экран авторизации. Для входа используйте свои учетные данные.

В целом, процесс запуска сервера ssh зависит от используемого дистрибутива Linux.

В Ubuntu для запуска сервера ssh на VPS нужно ввести:

Sudo service sshd start

Настройка SSH

При изменении настроек SSH изменяются и настройки ssh-сервера.

В Ubuntu главный конфигурационный файл SSH находится в /etc/ssh/sshd_config.

Создайте резервную копию текущей версии этого файла перед его редактированием:

Sudo cp /etc/ssh/sshd_config{,.bak}

Откройте его с помощью текстового редактора:

Sudo nano /etc/ssh/sshd_config

Некоторые настройки требуют особенного внимания, например:

Данная строка определяет, какой порт ssh-сервер будет прослушивать для соединений. По умолчанию это порт 22.

Желательно использовать нестандартный порт, чтобы защитить сервер от случайных сканирований портов. Позже будет показано, как подключиться к новому порту.

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

Строки HostKey указывают, где находятся ключи хоста (подробнее о ключах хоста позже).

SyslogFacility
LogLevel INFO

Данные строки содержат настройки журналирования и определяют уровень журнала.

При возникновении каких-либо проблем с SSH рекомендуется повысить уровень журнала (что увеличивает количество записываемых данных).

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

Данные параметры содержат некоторую регистрационную информацию.

LoginGraceTime указывает количество секунд, на протяжении которых необходимо поддерживать соединение без авторизации.

Примечание : в данной строке установите немного больше времени, чем обычно необходимо для регистрации.

PermitRootLogin определяет возможность входа в систему как пользователь root.

В большинстве случаев после создания пользователя, имеющего повышенные привилегии (su или sudo) и возможность подключаться через ssh, в данной строке рекомендуется установить «no»

strictModes – это защитное устройство, которое откажет во входе, если файлы аутентификации доступны для чтения всем.

Это предотвращает попытки входа, если файлы конфигурации не защищены.

X11Forwarding yes
X11DisplayOffset 10

Данные параметры настраивают функцию под названием X11 Forwarding, что позволяет просматривать графический пользовательский интерфейс (GUI) удаленной системы на локальной системе.

Этот параметр должен быть активирован и на локальной, и на удаленной машине; для использования функции необходимо передать клиента и опцию –X.

Отредактировав данный файл, не забудьте перезапустить ssh-сервер, чтобы активировать внесенные изменения:

sudo service sshd restart

Кроме того, внесенные изменения необходимо тщательно протестировать, чтобы убедиться, что все работает должным образом.

Столкнувшись с проблемами, помните, что войти можно также с помощью кнопки «Console Access».

Вход с помощью ключей SSH

Зачастую аутентификация на основе ключей намного надежнее, чем вход в удаленную систему при помощи пароля.

Как работает аутентификация на основе ключей?

Аутентификация на основе ключей подразумевает создание пары ключей – закрытого и открытого.

Закрытый ключ находится на клиентской машине, должен быть защищен и храниться в секрете.

Открытый ключ можно давать кому угодно и разместить на любом сервере, к которому нужно получить доступ.

При попытке подключиться с помощью пары ключей сервер использует открытый ключ, чтобы создать сообщение для клиентского компьютера, которое можно прочитать только с помощью закрытого ключа.

Затем клиентский компьютер посылает серверу соответствующий ответ, благодаря чему сервер понимает, что клиент является законным.

После настройки ключей весь этот процесс осуществляется автоматически в фоновом режиме.

Создание SSH-ключей

SSH-ключи нужно создать на компьютере, с которого нужно установить подключение (как правило, это локальный компьютер).

В командной строке наберите:

ssh-keygen -t rsa

Чтобы принять настройки по умолчанию, нажмите Enter. Ключи будут созданы в ~/.ssh/id_rsa.pub и ~/.ssh/id_rsa.

Перейдите в каталог.ssh, набрав:

Обратите внимание на права на файлы:

ls -l
-rw-r--r-- 1 demo demo 807 Sep 9 22:15 authorized_keys
-rw------- 1 demo demo 1679 Sep 9 23:13 id_rsa
-rw-r--r-- 1 demo demo 396 Sep 9 23:13 id_rsa.pub

Как можно видеть, права на чтение и изменение файла id_rsa есть только у владельца. Такие привилегии необходимы, чтобы сохранить ключ в секрете.

В то же время, файл id_rsa.pub можно использовать совместно, потому он имеет соответствующие привилегии.

Передача открытого ключа на сервер

Следующая команда скопирует открытый ключ на удаленный сервер:

ssh-copy-id удаленный_хост

Это откроет сессию SSH, для входа в которую нужно ввести пароль.

После введения пароля открытый ключ будет скопирован на сервер, что позволит в следующий раз войти в систему без пароля.

Клиентские настройки SSH

При подключении по SSH можно использовать ряд флагов.

Некоторые из них нужны для установки соответствующих параметров вфайле ssh удаленного хоста.

Например, если номер порта в конфигурациях ssh на локальном хосте был изменен, нужно установить соответствующий порт на стороне клиента, набрав:

ssh -p номер_порта удаленный_хост

Если на удаленной системе нужно выполнить какую-либо команду, ее можно указать следующим образом:

ssh удаленный_хост нужная_команда

Эта строка установит соединение с удаленной машиной и выполнит указанную команду.

Как уже было сказано, если функция X11 forwarding активирована на обоих компьютерах, ее можно использовать, набрав:

ssh -X удаленный_хост

При наличии на локальной системе всех соответствующих инструментов программы с графическим интерфейсом, используемые на удаленной системе, откроются на локальном компьютере.

Итоги

Научиться работать с SSH очень важно хотя бы потому, что это необходимо для выполнения самых базовых задач.

Постоянно используя SSH, можно не только защитить сервер, но и стать продвинутым пользователем, что значительно упростит жизнь. Протокол SSH остается популярным, потому что он безопасен, надежен и полезен в различных ситуациях.

Tags: ,

Yossi

прошу прощения, проблема решина

Мы разобрались, что такое SSH и в чем ее преимущества, также мы реализовали самый простой пример SSH- сервера и клиента.

Сегодня я расскажу про более детальную настройку SSH- сервера.

Как гласит известная фраза, «в Linux все есть файл», поэтому для настройки SSH- сервера необходимо и достаточно отредактировать один конфигурационный файл. Его полный путь — /etc/ssh/sshd_config . Для редактирования откроем этот файл с правами суперпользователя любым текстовым редактором.

Перед редактированием сделаем на всякий случай backup файла:

Sudo cp /etc/ssh/sshd_config{,.bak}

Теперь посмотрим его содержимое:

Sudo nano /etc/ssh/sshd_config

После каждого изменения этого файла необходимо перезапустить ssh- сервер для применения наших изменений.

Как мы видим, здесь довольно много параметров, будем разбираться постепенно с каждым из них.

Port

Здесь прописывается, какой порт будет слушать наш сервер. По умолчанию он слушает 22 порт TCP/IP . Интересный факт, что можно указать несколько портов. Например:

ListenAddress

Ограничение авторизации по интерфейсу (ListenAddress)

Общий вид настройки можно записать так:

ListenAddress host | IPv4_addr | IPv6_addr ListenAddress :port

Указывает сетевой адрес, на котором будет «слушать» сервер.
Если на сервере есть несколько сетевых интерфейсов, которые настроены на использования разных IP- адресов, то вы можете ограничить доступ по этому параметру.
К примеру, на сервере следующие 4 сетевых интерфейса:

Eth0 – 192.168.0.1 eth1 – 192.168.0.2 eth2 – 192.168.0.3 eth3 – 192.168.0.4

По умолчанию ssh- сервер находится в состоянии ожидания подключения на всех IP- адресах. Если хотите, чтобы пользователи могли авторизовываться только на интерфейсах 2 и 3 , то следует сделать так:

ListenAddress 192.168.0.2 ListenAddress 192.168.0.3

Здесь можно также указать порт. Например:

ListenAddress 192.168.0.2:222

Если порт не задан, ssh будет слушать на этом адресе и
на порту, указанному в опции Port. Если вы будете использовать ListenAddress не указывая порт, то опция Port должна предшествовать опции ListenAddress. Если вообще не указывать ListenAddress, то по умолчанию сервер слушает на всех локальных адресах.

Address Family

Указывает, какое семейство IP адресов должно быть использовано сервисом ssh . Возможные варианты:
“any” — любые
“inet” (только IPv4 )
“inet6” (только IPv6 )
По умолчанию — “any”.

Имеет смысл по возможности ограничить семейство обрабатываемых адресов реально используемыми, т. е. если вы используете только IPv4 - отключите IРv6 , и наоборот.

Например, для разрешения IPv4 и запрета IPv6:

AddressFamily inet

Protocol

ssh может работать с протоколами SSH1 и SSH2. При этом использование небезопасного SSH1 крайне не рекомендуется. Заставить ssh работать только с протоколом SSH2 можно так:

Protocol 2

PermitRootLogin

Возможность авторизации под суперпользователем

По умолчанию зайти на удаленный сервер под пользователем root никто не запрещает. Но это не совсем безопасно. В место этого более правильно будет авторизовываться под пользовательской учетной записью и повышать свои привилегии с помощью команды ‘su -‘, либо использовать ‘sudo’.

Если в вашей организации несколько системных администраторов и все они подключаются к серверу под суперпользователем, то не всегда можно узнать кто из администраторов находится на сервере. Поэтому после отключения возможности авторизации напрямую под пользователем root, системные администраторы сначала будут заходить под своей учетной записью и только после этого получать привилегии суперпользователя; это облегчить аудит сервера и действий, которые производят сисадмины.
Для отключения вышеописанной функции следует отключить параметр PermitRootLogin , установив значение “no”.

PermitRootLogin no

PermitEmptyPasswords

Блокируем пустые пароли

PermitEmptyPasswords no

AllowUsers, AllowGroups

По умолчанию авторизоваться может любой пользователь сервера. Лучше ограничить круг пользователей, которым разрешен доступ к ssh.
Это может быть полезно, когда вы создаете некоторое количество пользователей системе, но разрешить доступ по ssh хотите только некоторым.

Для этого в конфигурационный файл sshd_config следует добавить определенных пользователей, существующих на сервере. В примере ниже это пользователи john, peter и michael, которым разрешен вход на сервер. Имя пользователей разделены пробелами.

AllowUsers john peter michael

При добавлении всех пользователей, которые присутствуют в какой-либо опроеделенной групппе следует указать так, как это представлено на примере ниже. Группы пользователей, которым разрешен вход на сервер разделены также пробелом.

AllowGroups developers administrators

DenyUsers, DenyGroups

В противовес параметра, разрешающего доступ определенным пользователям или группам, вы также можете указать пользователей или группы, которым запрещен вход на сервер.
Для этого следует добавить в конфигурационный файл sshd_config параметр DenyUsers , в котором через пробел указать тех пользователей, которым запрещен доступ на сервер. На примере ниже это системный apache, а так же вполне реальный boris.

DenyUsers apache boris

Существует также параметр, с помощью которого можно запретить доступ не отдельным пользователям, а целым группам, в которые входят пользователи. Это параметр DenyGroups и группы указываются тоже через пробел.

DenyGroups marketing hackers

Обратите внимание на то, что можно использовать комбинации запрещающих и разрешающих параметров: DenyUsers , AllowUsers , DenyGroups , и AllowGroups .

LoginGraceTime

При попытке авторизоваться по ssh на сервер у вас есть 2 минуты, чтобы ввести логин и пароль. Если вы этого не сделаете, то соединение с сервером будет разорвано. 2 минуты ожидания авторизационных данных это довольно много. Следует ограничить до 1 минуты или даже до 30 секунд.

Для этого следует изменить параметр LoginGraceTime путем редактирования файла sshd_config, и указать там требуемое время. В примере ниже это 1 минута.

LoginGraceTime 1m

ClientAliveInterval

Рассоединение при отсутствии активности в шелле

После того, как вы успешно авторизовались на сервер, вы можете захотеть сделать так, чтобы можно было разрывать соединение автоматически после того, как прошло некоторое время, в течение которого вы не производили никаких действий в консоли. Это обычно называется временем бездействия.

Используя Bash, вы можете достичь этого, изменив переменную окружения TMOUT .

В OpenSSH же это достигается путем комбинации параметров ClientAliveCountMax и ClientAliveInterval в конфигурационном файле sshd_config.

ClientAliveCountMax — указывает максимальное количество checkalive сообщений, отсылаемых ssh- сервером, при которых он не получает какой-либо ответ от ssh- клиента. По умолчанию это 3.
ClientAliveInterval — указывает время ожидания (таймаут) в секундах. После указанного времени ssh- сервер отошлет checkalive сообщение клиенту, ожидая от него ответ (response) . По умолчанию — это 0, то есть сервер не будет отсылать сообщения для проверки.

Для того, чтобы ваш ssh- клиент автоматически отключался после 10 минут (600 секунд), следует внести изменения в конфигурационный файл sshd_config следующим образом:

ClientAliveInterval 600 ClientAliveCountMax 0

На этом пока все. В принципе, я думаю, этого уже достаточно для хорошей настройки и улучшения безопасности ssh. В следующей части мы разберем еще некоторые параметры ssh- сервера и, может, успеем обсудить аутентификацию на основе ключей.

Всем удачи и до скорых встреч на нашем блоге!

Для работы ssh-сервера, а также ssh-клиента будем использовать всем известный пакет OpenSSH

Установка

Установим OpenSSH командой:

sudo apt install ssh

Настройка сервера

При установке SSH-сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:

sudo service ssh stop|start|restart

Основной файл конфигурации SSH-сервера - файл /etc/ssh/sshd_config, доступный для чтения или редактирования только суперпользователю. После каждого изменения этого файла необходимо перезапустить ssh-сервер для применения таких изменений.

Пример конфигурации SSH-сервера в Ubuntu 16.04:

# Какие порты, IP-адреса и протоколы мы слушаем Port 22 # “any” - любые # # “inet” (только IPv4) # # “inet6” (только IPv6) # AddressFamily inet # По каким интерфейсам/сетям разрешен доступ, если # не указывать, то слушает по всем адресам. #ListenAddress:: #ListenAddress 0.0.0.0 # Протокол на котором будет работать SSH (рекомендуестя второй) Protocol 2 # Указывает файл, содержащий закрытый хост-ключ для протокола версии 2 HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key #Разделение привилегий включена для безопасности UsePrivilegeSeparation yes # Продолжительность жизни и размер бит ключа для протокола версии 1 #KeyRegenerationInterval 3600 #ServerKeyBits 1024 # Логирование # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # SyslogFacility AUTH # SILENT # # QUIET # # FATAL # # ERROR # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # LogLevel INFO # Аутентификация: LoginGraceTime 45 # Разрешить или нет доступ root пользователю. # “yes” - суперпользователь может зайти. # Применяется текущая глобальная схема аутентификации. # “without-password” - суперпользователь может зайти. # Парольная аутентификация для него будет отключена. # “forced-commands-only” - суперпользователь сможет зайти, # пользуясь аутентификацией на основе публичного ключа и # только если передаст необходимую к исполнению комнаду. # Все остальные методы аутентификации для суперпользователя будут заблокированы. # “no” - суперпользователь не может использовать ssh для входа в систему. PermitRootLogin no StrictModes yes # Указывает, разрешена ли "чистая" RSA-аутентификация. # Актуально только для протокола версии 1. RSAAuthentication yes # Использовать аутентификацию по публичному ключу PubkeyAuthentication yes # Указывает файл, в котором содержатся публичные ключи, используемые # для аутентификации пользователей. #AuthorizedKeysFile %h/.ssh/authorized_keys # Запрещает использование файлов.rhosts и.shosts # # в процессе аутентификации, основанной на проверке хоста. IgnoreRhosts yes # Для этой работы вам также потребуется ключи хоста в /etc/ssh_known_hosts RhostsRSAAuthentication no # аналогично для версии протокола 2 HostbasedAuthentication no # Указывает должен ли sshd игнорировать пользовательские # "известные хосты" ~/.ssh/known_hosts для RhostsRSAAuthentication #IgnoreUserKnownHosts yes # Включает аутентификацию по пустому паролю (НЕ РЕКОМЕНДУЕТСЯ) PermitEmptyPasswords no # Указывает, разрешить ли аутентификацию вида вопрос-ответ ChallengeResponseAuthentication no # Указывает, разрешина ли аутентификация по паролю PasswordAuthentication no # Kerberos опции # Указывает, требует ли пароль, предоставленный # # пользователем для аутентификации #KerberosAuthentication no # Если активен AFS и пользователь получил Kerberos 5 TGT, # пытаться ли получить AFS токен до того, как пользователь # получит доступ к своей домашней папке. # По умолчанию - “no”. #KerberosGetAFSToken no # Указывает, как поступать в случае, если аутентификация # через Kerberos завершилась неудачей. Если # значение = "yes" - пароль будет проверен при помощи # любого дополнительного локального механизма авторизации, # например - /etc/passwd. # По умолчанию - “yes”. #KerberosOrLocalPasswd yes # Указывает, нужно ли автоматически уничтожать файл с # кешем тикета пользователя по завершению сеанса. # По умолчанию - “yes”. #KerberosTicketCleanup yes # GSSAPI опции # Указывает, разрешена ли аутентификация пользователя на # основе GSSAPI. По умолчанию - "no" #GSSAPIAuthentication no # Указывает, нужно ли автоматически уничтожать # пользовательский кеш аутентификационных полномочий при # завершении сеанса. # По умолчанию - "yes" #GSSAPICleanupCredentials yes # Указывает, разрешено ли перенаправление графической # подсистемы X11. #X11Forwarding yes # Указывает номер первого дисплея, доступного sshd в # качестве перенаправления X11. #X11DisplayOffset 10 # Указывает, должен ли sshd выводить на экран информацию /etc/motd # при интерактивном входе пользователя. PrintMotd no # Указывает, должен ли sshd выводить на экран дату и время # последнего сеанса при интерактивном входе пользователя. # По умолчанию - “yes”. PrintLastLog yes # Указывает, нужно системе посылать TCP сообщения клиенту с целью # поддержания соединения. TCPKeepAlive yes # Задает количество сообщений к клиентам, которые sshd # посылает подряд, не получая какого либо ответа от # клиента. Если пороговое значение будет достигнуто, а # клиент так и не ответил - sshd отключит клиента, прервав # ssh сессию. #ClientAliveCountMax # Задает временной интервал в секундах. Если в течении # этого интервала не было обмена данными с клиентом, sshd # посылает сообщение по зашифрованному каналу, # запрашивающее ответ от клиента. По умолчанию - 0, т.е. # не посылать таких сообщений. Эта директива работает # только для протокола ssh2. #ClientAliveInterval # Указывает, должен ли использоваться login для # интерактивного сеанса. Значение по умолчанию - “no”. #UseLogin no # Указывает максимальное число одновременных # неавторизованных подключений к sshd. # Дополнительно, можно задать ранний сброс соединений, # указав в качестве параметра три значения, разделенные # двоеточием “start:rate:full” (например: "3:30:30"). # sshd отклонит попытку соединения с вероятностью равной # “rate/100” (т.е. в нашем примере - 30%), если уже # имеется “start” (3) неавторизованных соединений. # Вероятность увеличивается линейно и любые попытки # соединения будут отклонены, если число неавторизованных # соединений достигнет значения “full” (30). # MaxStartups 3:30:30 # Указывает какой файл содержит текстовый баннер, который # будет показан пользователю ПЕРЕД процедурой # аутентификации. Опция доступна только для протокола ssh2. Banner /etc/issue.net # Разрешить клиенту передавать региональные переменные окружения AcceptEnv LANG LC_* # Определяет и настраивает внешнюю подсистему (например # демона передачи файлов - file transfer daemon). Subsystem sftp /usr/lib/openssh/sftp-server # Включает интерфейс PAM (Pluggable Authentication Module # interface).Если задано значение "yes" - для всех типов # аутентификации помимо обработки модуля сессии и аккаунта # PAM будет использоваться аутентификация на основе # запроса-ответа (ChallengeResponseAuthentication и # PasswordAuthentication) Т.к. аутентификация # запросов-ответов в PAM обычно выполняет ту же роль, # что и парольная аутентификация, вам следует отключить # либо PasswordAuthentication, либо # ChallengeResponseAuthentication. Стоит отметить, что # если директива UsePAM включена - вы не сможете запустить # sshd от имени пользователя, отличного от root. # Значение по умолчанию - “no”. UsePAM yes

Можно скопировать приведенный выше текст в ваш собственный sshd_config и использовать в дальнейшем.

Сам по себе, неправильно настроенный SSH-сервер - огромная уязвимость в безопасности системы, т. к. у возможного злоумышленника есть возможность получить практически неограниченный доступ к системе. Помимо этого, у sshd есть много дополнительных полезных опций, которые желательно включить для повышения удобства работы и безопасности).

Port, ListenAddress и AddressFamily

Во-вторых, желательно сменить стандартный порт (22) на котором слушает sshd. Это связано с тем, что многочисленные сетевые сканеры постоянно пытаются соединиться с 22-м портом и как минимум получить доступ путем перебора логинов/паролей из своей базы. Даже если у вас и отключена парольная аутентификация - эти попытки сильно засоряют журналы и (в большом количестве) могут негативно повлиять на скорость работы ssh сервера. Если же вы по какой либо причине не желаете изменить стандартный порт вы можете использовать как различные внешние утилиты для борьбы брутфорсерами, например fail2ban, так и встроенные, такие как MaxStartups.
Задать порт можно как абсолютным значением для всех интерфейсов при помощи директивы Port, так и конкретным значением для каждого интерфейса, при помощи директивы ListenAddress.

Запрещение удаленного доступа для суперпользователя

По умолчанию root-доступ запрещен по паролю (по ключу — можно) — опция PermitRootLogin установлена в without-password4). Но, при условии, что по умолчанию в Ubuntu пользователь, добавленный при установке системы имеет возможность решать все административные задачи через sudo, создавать возможность root доступа к системе через ssh — выглядит неразумно (даже при аутентификации по ключу). Рекомендуется совсем отключить. эту опцию, или применять ее только в режиме forced-commands-only.

Парольная аутентификация

Протоколы SSH1 и SSH2

Аутентификация на основе SSH2 RSA-ключей

Настройка SSH-клиента

Наиболее безопасным считается вход по ключу, и в большинстве случаев на стороне сервера такая возможность включена, так что для её использования никаких прав суперпользователя не требуется. На клиентской машине генерируем ключ:

Ssh-keygen

Получаем предложение ввести пароль для защиты файла ключа (оказывается полезным при попадании файла в чужие руки). Передаём публичный ключ на сервер командой

Ssh-copy-id -i ~/.ssh/id_rsa.pub пользователь_на_сервере@адрес_сервера

Всё, можно заходить.

Когда ssh работает на нестандартном порту:

Ssh-copy-id -i ~/.ssh/id_rsa.pub -p ваш_порт пользователь_на_сервере@адрес_сервера

Порой появляется потребность зайти с одного ПК на другой, при этом чтобы можно было не только просматривать данные, но и совершать какие-то действия. Для таких задач идеально подходит протокол SSH, особенно в Ubuntu. Он позволяет безопасно объединить сервер и клиент и при этом установка и настройка не займет у вас много времени, если действовать по инструкции.

Как установить server в Ubuntu

Дело в том, что по умолчанию в операционной системе Ubuntu клиент уже установлен. Потому главное — это установка программы server OpenSSH на компьютере и ее последующая настройка. Для того, чтобы установить сервер, откройте терминал и введите строку: sudo apt-get install openssh-server. После этого Ubuntu запросит у вас пароль — подтвердите его. Когда установка будет завершена, вылетит сообщение с отчетом об успешной инсталляции. В итоге будет установлен server OpenSSH. Эта программа находится в дистрибутивах Ubuntu по умолчанию, потому server OpenSSH пользуется большой популярностью среди юзеров данной ОС.

Настройка server SSH в Ubuntu

Теперь самое главное — вам нужно правильно настроить server OpenSSH перед тем, как включить его и пускать клиент по защищенному протоколу на хост. Неправильная настройка может привести к понижению уровня безопасности и ваш сервер могут взломать.

А SSH протокол для того и нужен, чтобы подключение и передача данных проходили по надежным, шифрованным каналам, так что лучше потратьте немного времени и разберитесь в настройках.

То, как будет работать сервер, прописано в файле конфигураций config. В частности, в нем прописаны требования, каким должен соответствовать клиент для прохода через защиту SSH. Для начала стоит определиться с пользователем, через которого вы будете управлять системой. По умолчанию установлен пользователь root. Но оставлять эту настройку таковой небезопасно — у root пользователя слишком много прав и вы случайно можете навредить системе, потому лучше запретить его подключение к серверу.

Вам нужно переустановить на сервер другой аккаунт пользователя, чтобы вы могли безопасно пользоваться другим компьютером через SSH. Для этого вам нужно будет вместо root добавить другого юзера при помощи командной строки: adduser имя_пользователя. Но и этого недостаточно — все-таки иногда вам нужен будет пользователь root. Тогда сделайте добавленного юзера наполовину суперадминистратором, чтобы он мог временно получать root права. Для этого зайдите в root и пропишите следующую строку: gpasswd -a имя_пользователя sudo. Таким образом вы добавите нового юзера в группу пользователей sudo, у которых наибольший уровень доступа.

Если вы планируете при помощи SSH создать публичный сервер и на компьютер будет заходить ни один клиент, тогда лучше вообще убрать root пользователя. Если же вы уверены в своих способностях и не планируете публиковать хост, тогда можете сделать клиент суперадминистратором и защитить его паролем. Но иногда после этого появляется сообщение об ошибке: access denied. Надпись access denied после попытки зайти в аккаунт суперпользователя при помощи ввода пароля может означать какое-то противоречие в файле конфигураций config.

Чтобы устранить access denied, вам стоит хорошенько просмотреть все ли в порядке в настройках. Самая частая причина, почему появляется access denied — это активация опции авторизации по паролю и для обычных пользователей, и для root. Чтобы убрать access denied, поменяйте PermitRootLogin вместо yes на without-password. А затем пропишите PermitRootLogin yes. Далее перезапустите сервер (service ssh restart) и сообщение access denied окончательно пропадет.

Следующий важный шаг — это активация усиленной аутентификации пользователей. Авторизация путем ввода пароля — это уже устарелый и неэффективный способ защиты аккаунтов. Сейчас есть множество программ, при помощи которых можно путем подбора взломать пароли. Потому вам лучше использовать аутентификацию при помощи публичного ключа. То есть вам лучше использовать Public Key Authentication и поставить yes возле этого пункта в файле config.

Чтобы войти на сервер путем подтверждения публичного ключа, вам нужно его сначала сгенерировать. В Ubuntu очень удобно генерировать ключи, так как для этого не нужно скачивать какие-то дополнительные программы — достаточно забить в терминале ssh-keygen. После этого появится сообщение с информацией о расположении созданного ключа. Он будет находится в папке.ssh. После этого система запросит у вас пароль, но настоятельно рекомендуется оставить его пустым — иначе потом будете вводить его каждый раз при осуществлении какой-либо операции.

Следующим шагом вам нужно добавить сгенерированный публичный ключ в список доверенных на сервере. Для начала вам нужно будет скопировать публичный ключ. Он находится в файле формата.pub в папке.ssh. Скопируйте его и зайдите на сервер. На сервере так же должна быть папка.ssh. Если ее нет, то придется создать самостоятельно. А после этого, используя стандартный текстовый редактор, создайте файл authorized_keys. Именно в него вам нужно будет поместить публичный ключ. После этого вы сможете заходить на сервер без какого-либо подтверждения. Аутентификация будет проходить в автоматическом, фоновом режиме, что весьма удобно и при этом безопасно.

В целом, на этом настройка протокола SSH заканчивается! Разве что еще можете изменить порт 22 на другой.

Описание принципов работы и используемых приложений

Установка

Настройка сервера

Port, ListenAddress и AddressFamily

Запрещение удаленного доступа для суперпользователя

Парольная аутентификация

Протоколы SSH1 и SSH2

Аутентификация на основе SSH2 RSA-ключей

SFTP

Использование критериев. Директива Match

Базовый синтаксис

Как работает SSH?

Настройка SSH

Вход с помощью ключей SSH

Как работает аутентификация на основе ключей?

Создание SSH-ключей

Передача открытого ключа на сервер

Клиентские настройки SSH

Итоги

Port

ListenAddress

Address Family

Protocol

PermitRootLogin

PermitEmptyPasswords

AllowUsers, AllowGroups

DenyUsers, DenyGroups

LoginGraceTime

ClientAliveInterval

Установка

Настройка сервера

Настройка SSH-клиента

Как установить server в Ubuntu

Настройка server SSH в Ubuntu

Похожие материалы: