SSH сервер на Debian
Приветствую, пользователи и администраторы Debian и Ubuntu. Сегодня хочу затронуть такую, казалось бы, очевидную тему – установка и настройка ssh сервера на Debian. Ранее никак не доходили руки.
Введение в SSH
Как становится понятно из названия, SSH сервер основан на работе протокола SSH. Существуют несколько реализация данного сервера (dropbear, lsh-server, openssh-server, ssh и др.), в данной статье я буду рассматривать реализацию сервера OpenSSH на Debian Squeeze. Протокол SSH изначально являлся проприетарным коммерческим и пережил 2 реализации. В 1995 г. была разработана версия протокола SSH-1, в 1996 г. разработали версию SSH-2 (используется по настоящее время), не совместимую с SSH-1.
Техническая информация о протоколе SSH
SSH — это протокол сеансового (транспортного) уровня, использует для работы 22/tcp порт. OpenSSH предлагает два уровня идентификации: идентификация сервера и идентификацию клиента (пользователя). В-первых, клиент проверяет, что подсоединен к требуемому серверу. Затем OpenSSH шифрует все данные, передаваемые между системами. Во-вторых, как только защищенная шифрованная связь установлена, SSH убеждается в авторизации пользователя для входа в систему (или для копирования файлов с системы и на нее). Как только система сервер и пользователь проверены, SSH разрешает службам пользоваться созданным соединением. Установленное соединение может использоваться для интерактивной работы в bash (утилита ssh), удаленного выполнение каких-либо команд (опять же утилита ssh и scp), а так же туннелирование портов TCP/IP.
В своей работе SSH задействует следующие типы шифрования: аутентификация производится с использованием асимметричного шифрования с открытым ключом (версия SSH1 – RSA, SSH2 – RSA/DSA). Обмен данными во время установленного соединения – симметричное шифрование (IDEA – патентованный, DES, triple DES (3DES), ARCFOUR, BLOWFISH, CAST128, AES/Rijndael). Целостность переданных данных проверяется с помощью CRC32 в версии SSH1 и HMAC-SHA1/HMAC-MD5 – в SSH2. Для сжатия шифруемых данных может использоваться алгоритм LempelZiv (LZ77), который обеспечивает такой же уровень сжатия, что и архиватор ZIP. Спецификация протокола SSH-2 описана в RFC 4251.
Ранее (в SSH1) установка соединения происходила так: при первом подключении клиента к серверу (сервер в данном примере имеется ввиду – компьютер, на котором работает демон sshd), клиент получал от сервера публичный ключ и сохранял его в собственной базе. При следующих соединениях клиент проверял не изменился ли данный ключ. Делее, клиент генерировал произвольный 256-битный набор символов и зашифровывал этот набор публичным ключом. Сервер расшифровывал данную фразу и отправлял клиенту. Клиент, убедившись, что расшифрованная фраза валидна – устанавливал соединение и данная фраза использовалась далее клиентом и сервером как сессионный ключ для шифрования передаваемых данных.
В современной реализации (SSH2) используется гораздо более сложный алгоритм (алгоритм Diffie-Hellman’а, описанный в rfc4419).
Архитектуру протокола SSH можно разделить на несколько уровней:
Транспортный уровень RFC 4253 – работает поверх протокола TCP, обеспечивает начальный обмен ключами, устанавливает шифрование, сжатие и проверку целостности. Уровень аутентификации RFC 4252 – работает поверх транспортного уровня, обеспечивает аутентификацию клиента и сервера. Наиболее популярные методы аутентификации ssh:
- Парольная – метод на основе простого ввода пароля.
- Публичный ключ – метод на основе публичного RSA/DSA ключа
- Интерактивный – метод, когда сервер посылает один или несколько запросов ввода информации клиенту, а клиент отображает их и отправляет обратно серверу ответы введенные пользователем. Используется при одноразовых паролях аутентификации.
- GSSAPI – методы аутентификации, которые обеспечивают аутентификацию с использованием внешних механизмов, таких как Kerberos 5 или NTLM.
Протокол соединения RFC 4254 – работает поверх протокола аутентификации, позволяет использовать установленный безопасный канал для передачи нескольких потоков информации в обоих направлениях. Используется для работы в шелле, туннелирования трафика или копирования файлов.
Установка OpenSSH в Debian
В Debian OpenSSH представлен несколькими пакетами:
gw ~ # aptitude search openssh ... i openssh-client - клиент протокола SSH, для защищённого удалённого доступа i openssh-server - серверная часть протокола SSH, для защищённого удалённого доступа
основные – это openssh-server и openssh-client. При этом, последний чаще всего устанавливается вместе с системой. Итак, чтобы установить ssh сервер в Debian Squeeze, достаточно выполнить команду:
Во время выполнения установки будут автоматически сгенерированы необходимые ключи шифрования (RSA и DSA), демон sshd будет добавлен в автозагрузку и запущен. На этом по большому счету, можно считать сервер SSH вполне работоспособным. Но настройки по умолчанию, не совсем корректны и безопасны.
OpenSSH в реализации Debian содержит следующие компоненты/команды:
ssh (/usr/bin/ssh)
Собственно, клиент ssh.
scp (/usr/bin/scp)
Клиент для удаленного копирования файлов по протоколу SSH.
sftp (/usr/bin/sftp)
FTP-подобный SSH клиент.
sshd (/usr/sbin/sshd)
Демон, собственно предоставляющий защищённый доступ к ресурсам.
sftp-server ( /usr/lib/openssh/sftp-server)
Отдельная реализация подсистемы SFTP (серверная часть). Обладает бОльшими возможностями, чем встроенная в sshd.
ssh-keygen (/usr/bin/ssh-keygen)
Генератор пар ключей.
ssh-keysign (/usr/lib/openssh/ssh-keysign)
Утилита для проверки ключей хостов. Задействуется при использовании аутентификации по хостам (аналогично rsh) вместо проводимой по умолчанию аутентификации по пользователям/паролям.
ssh-keyscan (/usr/bin/ssh-keyscan)
Вспомогательная утилита. Позволяет за считанные секунды собрать публичные ключи с других хостов.
ssh-agent (/usr/bin/ssh-agent)
Вспомогательная утилита. Поддерживает кэш закрытых ключей. Кэширование позволяет избегать частого ввода пароля для расшифровки ключей перед их использованием.
ssh-add (/usr/bin/ssh-add)
Вспомогательная утилита. Добавляет ключи в кэш ssh-agent.
Клиенты SSH
Показать ssh_config на русском »
# Это системный конфигурационный файл клиента ssh. # Смотрите ssh_config(5) для более подробной документации. # Этот файл обеспечивает умолчания для пользователей, # значения могут быть изменены в пользовательском # файле конфигурации или в коммандной строке. # Данные конфигурации анализируется в следующем порядке: # 1. параметры командной строки # 2. пользовательские конфигурационные файлы (~/.ssh/config ) # 3. системный конфигурационный файл(/etc/ssh/ssh_config) # Любое первое встретившееся измененное конфигурационное значение является установленным. # Задание специфичных настроек для какого-либо хоста должно быть расположено # в начале файла конфигурации, а значения по-умолчанию в конце. # Ниже приведены некоторые общесистемные часто используемые опции. # Для получения полного списка опций и установленных значений # по умолчанию смотрите ssh_config(5) в ман старницах. # Определение настроек хоста (в данном случае включает все возможные # хосты - значение *), к которому применяются ниже заданные параметры и значения Host * # Перенаправлять (туннелировать) ли запросы к # программе управляющей ключами на удалённую систему # (используется для аутентификации через сервер-посредник). # Допустимые значения - yes и no. Значение по умолчанию - no. # ForwardAgent no # Включить автоматическое туннелирование соединений X11 # через защищённый канал. При этом переменная DISPLAY устанавливается # в соответствующее значение. Допустимые значения - yes и no # Значение по умолчанию - no # ForwardX11 no # При значении yes удалённые клиенты X11 будут получать # полный доступ к исходному дисплею X11. При значении # no удалённые клиенты X11 будут считаться ненадёжными # и будут приниматься меры для предотвращения получения # или подмены данных принадлежащих надёжным клиентам X11. Более того, # для маркера xauth(1) используемого для сеанса будет # устанавливаться срок действия 20 минут. По прошествии этого # времени удалённым клиентам будет отказываться в доступе. # Значение по умолчанию - no # ForwardX11Trusted yes # Пытаться ли выполнять аутентификацию по rhosts. # Допустимые значения - yes и no. Значение по умолчанию - no. # Данный параметр относится только к протоколу # версии 1 и требует setuid root для ssh # RhostsRSAAuthentication no # Пытаться ли выполнять аутентификацию только по ключу RSA. # Допустимые значения - yes и no. RSA будет выполняться # только если будет найден файл с идентификационными данными # или при работающем менеджере ключей. Значение по # умолчанию - yes. Данный параметр относится только к протоколу версии 1. # RSAAuthentication yes # Использовать ли аутентификацию по паролю. Значение по умолчанию - yes # PasswordAuthentication yes # Пытаться ли выполнять Hostbased аутентификацию, т.е. # аутентификацию по rhosts или /etc/hosts.equiv в сочетании # с открытым ключом. Допустимые значения - yes и no. Значение # по умолчанию - no. Этот параметр схож с RhostsRSAAuthentication # и применим только к протоколу версии 2. # HostbasedAuthentication no # Допускать аутентификацию по GSSAPI. Значение по умолчанию - no. # Данный параметр относится только к протоколу версии 2. # GSSAPIAuthentication no # Перенаправлять (делегировать) идентификационные данные серверу. # Значение по умолчанию - no. Данный параметр относится только к протоколу версии 2. # GSSAPIDelegateCredentials no # Что-то связанное с Kerberos keytab ключами. # Относится только к протоколу версии 2. # GSSAPIKeyExchange no # Тоже Kerberos настройка # GSSAPITrustDNS no # При значении yes запрос паролей отключается. # Полезно при использовании программы их сценариев, # выполняемых без вмешательства человека. Значение по умолчанию: no. # BatchMode no # При значении yes ssh будет выполнять проверку наличия IP-адресов # в файле known_hosts. Это позволяет обнаруживать подмену # ключа хоста посредством вмешательства в работу с DNS. # При значении no проверка не выполняется. Значение по умолчанию: yes. # CheckHostIP yes # Семейство адресов которое должен использовать клиент. # Допустимые значения: any, inet (только IPv4) и inet6 (только IPv6). # AddressFamily any # Время ожидания (в секундах) подключения к серверу SSH # (имеет больший приоритет чем системное значение времени ожидания # протокола TCP). Это значение игнорируется если с сервером # не удаётся соединиться потому что он отклоняет запросы на подключение. # ConnectTimeout 0 # При значении yes ключи хоста не будут автоматически # добавляться в ~/.ssh/known_hosts и программа не будет # соединяться с хостами ключи которых изменились.Это # позволяет лучше защититься от "троянских коней", # некоторые люди сочтут это раздражающим, особенно если # им приходится часто подключаться к новым серверам. # При значении no новые ключи хостов будут автоматически # добавляться в соответствующий файл. При значении ask новые # ключи хостов будут добавляться после подтверждения # пользователем, к хостам, ключи которых изменились, # по-прежнему подключиться будет невозможно. # Ключи имеющиеся в файле известных хостов проверяются # автоматически в любом случае. Допустимые значения - yes, no и ask. # Значение по умолчанию - ask. # StrictHostKeyChecking ask # Файлы с идентификационными данными (субъектом) RSA или DSA. # Значение по умолчанию - ~/.ssh/identity для протокола версии 1, # ~/.ssh/id_rsa и ~/.ssh/id_dsa для протокола версии 2. # Кроме того для аутентификации будут использоваться данные # предоставляемые менеджером ключей. В имени файла может присутствовать # тильда для указания каталога пользователя, а также следующие # последовательности: %d (домашний каталог локального пользователя). # %u (имя локального пользователя), %l (имя локального хоста), # %h (имя удалённого хоста), %r (имя удалённого # пользователя). Допустимо указание нескольких файлов с идентификационными # данными в файлах конфигурации; все они будут пробоваться по очереди. # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # Порт на удалённой машине к которому следует подключаться. # Значение по умолчанию - 22. # Port 22 # Версии протокола которые следует пытаться использовать, # в порядке предпочтения. Допустимые значения - 1 и 2 # Значение по умолчанию - 2,1. Это означает, что ssh сначала # пытается подключиться по протоколу 2 и, если он не поддерживается, пробует протокол 1. # Protocol 2,1 # Тип шифрования для защиты сеансов по протоколу версии 1. # Поддерживаются blowfish, 3des и des. Алгоритм des поддерживается # в клиенте ssh(1) только для совместимости со старыми серверами # не поддерживающими 3des. Рекомендуется воздержаться от # использования первого из-за его слабой стойкости. Значение # по умолчанию: 3des. # Cipher 3des # Допустимые для протокола версии 2 шифры. Несколько шифров # указываются через запятую. Поддерживаются следующие шифры: # 3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc, aes128-ctr, # aes192-ctr, aes256-ctr, arcfour128, arcfour256, arcfour, blowfish-cbc и cast128-cbc. # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc # Порядок предпочтения алгоритмов MAC (Message Authentication # Code - код установления подлинности сообщения). # Они используются в протоколе версии 2 для гарантирования # целостности данных. Несколько алгоритмов следует указывать через запятую. # Значение по умолчанию: hmac-md5, hmac-sha1, hmac-ripemd160, hmac-sha1-96, hmac-md5-96. # MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160 # Символ отменяющий интерпретирование следующего за ним символа # (по умолчанию - ~ ) . Символ можно также задавать через командную строку. В качестве # аргумента следует указывать последовательность из ^ и символа, # либо none для отключения данного механизма (что позволит использовать соединение для # передачи двоичных данных без искажений). # EscapeChar ~ # Запрашивать туннелирование (между клиентом и сервером) для устройств # tun(4) Допустимые значения - yes, point-to-point (layer 3), ethernet (layer 2), # и no. При указании yes программа будет запрашивать режим # туннелирования по умолчанию, point-to-point. Значение по умолчанию - no. # Tunnel no # Устройства tun(4) которые должны открываться на стороне клиента # (local_tun) и сервера (remote_tun). Формат аргумента: local_tun # [: remote_tun ]. Устройства можно указывать по числовому # идентификатору. Значение any отвечает ближайшему доступному # устройству tunnel. Если часть remote_tun не указана, она считается равной any. # Значение по умолчанию - any:any # TunnelDevice any:any # Разрешить выполнение локальной команды указанной в LocalCommand # или через управляющую последовательность ! command в ssh(1). # Допустимые значения - yes и no. Значение по умолчанию - no. # PermitLocalCommand no # Переменные локальной среды environ(7) которые следует посылать # серверу для копирования. Эта функция доступна только для протокола 2. Сервер также # должен поддерживать передачу переменных, кроме того, таковая # должна быть разрешена. За это отвечает параметр AcceptEnv файла конфигурации сервера # sshd_config. Переменные задаются по шаблону имён. Несколько шаблонов # разделяются пробелами, либо указываются в нескольких директивах SendEnv По # умолчанию не передаются никакие переменные. SendEnv LANG LC_* # Создавать хэши имён хостов при добавлении их в ~/.ssh/known_hosts # Использование хэшей имён хостов вместо самих имён хостов поддерживается и ssh(1) # и sshd(8), и позволяет предотвратить утечку информации в случае # разглашения содержимого файла. Значение по умолчанию - no. Уже имеющиеся в файле # имена хостов не будут преобразованы автоматически, это можно # сделать вручную с помощью утилиты ssh-keygen. HashKnownHosts yes # Эти два парметра уже рассматривались, здесь идет их переназначение. GSSAPIAuthentication yes GSSAPIDelegateCredentials no
Для того, чтобы удачно воспользоваться SSH клиентом по назначению, необходимо: иметь сервер с выполняющимся демоном sshd, иметь учетную запись на удаленной системе. В Debian наиболее часто используемый клиент, это утилита ssh (пакет openssh-client). Формат использования команды приведен в man ssh. Кратко, формат команды ssh имеет вид:
$ ssh [options] [user@]host [command]
Первая часть – это собственно команда ssh, далее возможны опции (например -p port задаст нестандартный порт), далее возможно указание имени пользователя от имени которого необходимо залогинется на удаленную систему. Если имя пользователя не указано, то соединение будет установлено от имени текущего пользователя. Далее идет обязательный параметр – DNS имя или IP удаленного хоста. Если осле имени хоста заданна какая-то команда, то эта команда будет выполнена и соединение будет разорвано, если команда не задана, то будет запущен интерпретатор.
При первоначальном подключении к серверу, ssh клиент выдает примерно следующее сообщение:
[root@proxy ~]# ssh 10.0.0.10 The authenticity of host '10.0.0.10 (10.0.0.10)' can't be established. RSA key fingerprint is 30:77:af:cb:e9:1a:20:f4:58:0d:d7:7e:a0:07:89:53. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.0.10' (RSA) to the list of known hosts. [email protected]'s password:
Данное сообщение говорит нам, что мы подключаемся к неизвестному ранее хосту с RSA ключем, имеющим такой-то отпечаток и требуется подтверждение нашего подключения. При положительном ответе (yes), клиент добавляет публичный ключ сервера sshd (/etc/ssh/ssh_host_rsa_key.pub) в пользовательский файл ~/.ssh/known_hosts на локальном компьютере. Когда клиент соединяется с несколькими серверами в указанном файле может скопиться большое количество таких ключей. Для отслеживания принадлежности каждого ключа к каждому серверу, клиент добавляет к строке ключа IP сервера и тип шифрования.
Кроме указанного пользовательского файла для “известных хостов серверов” существует так же глобальный файл /etc/ssh/ssh_known_hosts. К глобальному файлу должны иметь доступ на чтение все пользователи и использовать информацию при подключении к какому-либо серверу, но на запись должен иметь право только пользователь root. Как разграничить права доступа к файлам. Давайте рассмотрим содержимое файла known_hosts на примере:
[root@proxy ~]# grep .10 .ssh/known_hosts 10.0.0.10 ssh-rsa AAAAB3NzkejbdPP1p3KEzrONUppLn4ICCyMAQDiK5coYST2/BH/\ +vBBXhlj1LZkZFFtdkxVvRBxPhm7pbqRAxij9u/vfEe62yaLncb567sZOm1YG/\ y4aYGB8IdjUkejbdPP1p3KEzrONUppLn4ICCyM54QUjLQ3V7l+PDK500tM4OpPg/\ qLaaAQfMkejbdPP1p3KEzrONUppLn4ICCyMGqU+5E0+aOKHg7rXC1lW7LXdI4kq\ JHgydysgaiD78cGR2KaurQr3Zz02me4CtS9uuLoBkv5b9LCbQdX6OWyGgwbyp14x\ Y9tWFny4E3VDSctaaO5ie6pUBzs3ica0wxErFc/+cyjvpXTxLU7nkNqdaWBjMkfCggz8tVJt
В примере строка намеренно разбита на несколько, но реально это одна строка. Кроме команды ssh в OpenSSH существует команда scp, которая по синтаксису очень похожа на cp, за тем исключением, что к пути копируемого объекта добавляются некоторые параметры:
$ scp [[user@]src_host:]/path/src/file [[user@]dst_host:]/path/dst/file
, где src_host – хост источник, /path/src/file – исходный копируемый объект, dst_host – хост назначения, /path/dst/file – файл назначения.
Алиасы для ssh клиента (~/.ssh/config)
С помощью конфигурационного файла пользователя можно сделать использование ssh клиента более удобным. Допустим, имеем мы некоторый глобальный файл /etc/ssh/ssh_config, задающий настройки для всех хостов (host *). При этом, имеем некоторый удаленный ssh сервер, у которого длинное имя (например 678-ssh-server.superdomen.com.ua) и нестандартный порт (например 65387), при этом, имя пользователя тоже довольно длинное (например, vasilii-ptrov). Вводить каждый раз команду подключения к серверу:
$ ssh -p 65387 [email protected]
жутко неудобно и долго. Давайте упростим себе жизнь. В файл ~/.ssh/config добавим следующую информацию:
Host server User vasilii-ptrov Port 65387 HostName 678-ssh-server.superdomen.com.ua
Все! теперь введя в консоли ssh server мы попадаем на нужный сервер, нужны порт под нужным пользователем. Или даже так ssh se<Tab>. Строка автоматически развернется в ssh server!
Другие клиенты SSH
Кроме стандартного linux-ssh-клиента существует и множество других, например для Windows есть отличная софтина PuTTy.
Сервер OpenSSH (sshd)
Настройка sshd заключается в правке файла (например с помощью редактора vim) /etc/ssh/sshd_config. Описание файла приведено в man (5) sshd_config. Далее приведены описание наиболее часто используемых опций:
Показать sshd_config на русском »
# Конфигурационный файл сгенерирован пакетным менеджером # для более подробной информации смотрите man sshd_config(8) # Какие порты, адреса и протоколы, будет слушать демон Port 22 # Используйте эти опции для ограничения # интерфейсов/протоколов с которыми будет работать sshd #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # Приват ключи для протокола версии 2 (где будут сгенерированны и лежать) HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Разделение полномочий пользователей включается для обеспечения безопасности # Разделение полномочий пользователей работает следующим образом: # для каждого соединения создается отдельный серверный процесс, и когда приходит # запрос от клиента, отслеживающий ssh-монитор процесс запускает # непривилегированный дочерний процесс, который и будет обрабатывать все запросы от # клиента. Если для обработки запроса клиента требуются # привилегии суперпользователя, то этот запрос посылается привилегированному # процессу ssh-монитор. При просмотре запущенных процессов SSH можно # также увидеть демона sshd процесса, предназначенного для наблюдения, # и непривилегированный процесс, принадлежащий клиенту. UsePrivilegeSeparation yes # Данные значения определяют длину ключа сервера и его время жизни для # использования ssh версии 1 (данный ключ будет заново генерироваться через # заданное время) KeyRegenerationInterval 3600 ServerKeyBits 768 # Журналирование # Опция SyslogFacility определяет, список каких событий администратор # хочет видеть в лог-файле сервера. Доступны: # DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. # Опция LogLevel определяет уровень детализации сообщений. # Возможные значения: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG SyslogFacility AUTH LogLevel INFO # Аутентификация: # LoginGraceTime указывает количество секунд через которое # разорвется соединение если пользователь незалогинется. # PermitRootLogin разрешает или запрещает пользователю root # получать удаленный доступ по SSH. # StrictModes указывает sshd проверять ли права и владельца # домашнего каталога пользователя, который пытается получить удаленный доступ к системе, # перед тем как вызвать login, для использования # беспарольной аутентификации надо установить no. # RSAAuthentication указывает аутентификация через RSA (для версии 1). # PubkeyAuthentication указывает аутентификацию пользователя по ключу (для версии 2). # AuthorizedKeysFile определяет публичный ключ пользователя # для аутентификации по ключу. Можно применять шаблоны: # %u - имя пользователя, %h - домашний # каталог пользователя. LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Игнорируем пользовательские ~/.rhosts и ~/.shosts файлы. # Используется при hostbased аутентификации, # используя только known_hosts файл. IgnoreRhosts yes # Для этого режима вам также потребуется приватные ключи в /etc/ssh_known_hosts. # Используем ли аутентификацию через known_hosts совместно с .rhosts или # .shosts. Опция действительна только для протокола версии 1. RhostsRSAAuthentication no # Аналогично для протокола версии 2. # Включает hostbased аутентификацию. HostbasedAuthentication no # Раскомментируйте, если вы не доверяете ~/.ssh/known_hosts # при RhostsRSAAuthentication. # Не использовать known_hosts при hostbased аутентификации. # IgnoreUserKnownHosts yes # Для включения пустых паролей, установите yes (НЕ РЕКОМЕНДУЕТСЯ) PermitEmptyPasswords no # Определяет, разрешается ли безпарольная аутентификация # "вызов-ответ". (могут быть проблемы с PAM) ChallengeResponseAuthentication no # Выберите no чтобы запретить парольную аутентификацию. #PasswordAuthentication yes # Kerberos опции # Данные опции могут понадобиться, если для аутентификации # пользователя будет через Kerberos. # KerberosAuthentication no # KerberosGetAFSToken no # KerberosOrLocalPasswd yes # KerberosTicketCleanup yes # GSSAPI опции # Данные опции могут понадобиться, если для аутентификации # пользователя будет через GSSAPI. # GSSAPIAuthentication no # GSSAPICleanupCredentials yes # Передача протокола X через туннель ssh. X11Forwarding yes # Номер первого дисплея доступного для туннелирования трафика X11 X11DisplayOffset 10 # При логине пользователя выводим /etc/motd: рекомендуется отменить в # целях безопасности. PrintMotd no # Сообщаем пользователю время и место последнего логина. PrintLastLog yes # Поддержание связи с клиентом. Периодически посылать # клиенту контрольные сообщения для проверки активности соединения. # Если сообщения не будут отправляться, то после # отключения пользователя сеанс зависнет. TCPKeepAlive yes # Использовать login для интерактивных сеансов регистрации # в системе. Имейте ввиду, что login никогда # не используется для удалённого выполнения команд. # Если этот параметр включен, функция X11Forwarding будет # отключена потому что login не может обрабатывать cookie xauth. # В случае использования разделения полномочий (UsePrivilegeSeparation) # данный параметр будет отключен после прохождения аутентификации. #UseLogin no # MaxStartups контролирует количество параллельных неаутентифицированных # подключений к серверу. Запись параметра имеет форму "start:rate:full". В нашем # случае она означает отключение с вероятностью 30% при наличии # 10 неаутентифицированных связей, с линейным ростом вероятности до 100% при достижении # 60. #MaxStartups 10:30:60 # Опция Banner определяет место положения файла-баннера, который # будет выведен на экран, при попытке подключиться к серверу sshd. Обязательно убедитесь # в существовании файла, указанного в качестве параметра опции Banner. #Banner /etc/issue.net # Разрешить серверу принимать клиентские переменные окружения. AcceptEnv LANG LC_* # Новые системы, работающие через ssh. В данном примере определяется # "безопасный" ftp сервер - sftp, аналогичный доступ пользователя, но с # возможностью передачи файлов(т.е. пользователь получает доступ ко всем своим # файлам и нет возможности настройки разрешений и виртуальных пользователей, # как, например в proftpd). По сути дела подсистемы ssh могут обеспечивать # прохождение других протоколов по сети, но под "крылышком" ssh. Например, для # sftp сервера есть одноименный sftp клиент. Его интерфейс полностью идентичен # оригинальному ftp, но с одним отличием: происходит та же самая аутентификация # пользователя на удаленном сервере(методами ssh), но вместо оболочки с # пользователем взаимодействует подсистема, в данном случае sftp. Subsystem sftp /usr/lib/openssh/sftp-server # Использовать ли для аутентификации пользователя pam-модули. UsePAM yes
Ознакомившись с конфигом мы можем смело настроить сервер под свои нужны. Некоторые рекомендации и примеры приведены ниже. После правки sshd_config необходимо перезапустить сервер sshd:
root@debian:~# /etc/init.d/ssh restart Restarting OpenBSD Secure Shell server: sshd.
В OpenSSH временно можно запретить любые подключения к серверу, кроме пользователя root. Для этого, необходимо создать файл /etc/nologin. при существовании данного файла, сервер sshd выводит его ~/.ssh/содержимое и не позволяе/strong/strongт произвести вход для любого пользователя кроме пользователя root.
Типы аутентификации OpenSSH
Аутентификация пользователя по паролю.
При данном типе аутентификации, настроек сервера sshd и клиента ssh по-умолчанию вполне достаточно. При аутентификации сначала производится обмен ключами между сервером и клиентом и хэш пароля передается серверу в зашифрованном виде. Далее производится обмен данными.
Аутентификация пользователя по его публичному ключу.
Данный тип аутентификации может избавить от ввода пароля при подключении к серверу. Аутентификация по публичному ключу основана на проверке соответствия публичного ключа клиента, который размещается на сервере и секретного ключа клиента (пользователя), который расположен у клиента (у пользователя в домашнем каталоге ~/.ssh/id_rsa ). Примерно так же, как клиент проверяет валидность сервера по публичному ключу сервера. Генерация пары ключей осуществляется утилитой ssh-keygen, после чего в каталоге пользователя образуется 2 ключа ~/.ssh/id_rsa – секретный и ~/.ssh/id_rsa.pub – публичный. Публичный ключ помещается на сервер под именем ~/.ssh/authorized_keys. После этого при подключении к серверу под пользователем, в каталогах которого лежат соответствующие ключи (на клиенте – ~/.ssh/id_rsa, на сервере – ~/.ssh/authorized_keys) – нет необходимости вводить пароль. В файле ~/.ssh/authorized_keys может последовательно содержаться несколько ключей для доступа к данному серверу под данным пользователем с нескольких серверов. Давайте рассмотрим практический пример настройки аутентификации по публичному ключу:
mc-sim@FILES:~$ ssh-keygen -t rsa -b 2048 Generating public/private rsa key pair. (Генерация пары открытый/секретный rsa-ключей.) Enter file in which to save the key (/home/mc-sim/.ssh/id_rsa):<Enter> (Введите имя файла, в который будет сохранен ключ (путь по умолчанию)) Enter passphrase (empty for no passphrase):<Enter> (Введите кодовую фразу (пусто, если фраза не используется):) Enter same passphrase again: (Повторите ввод фразы:) Your identification has been saved in /home/mc-sim/.ssh/id_rsa. (Ваша идентификационная информация сохранена в /home/mc-sim/.ssh/id_rsa.) Your public key has been saved in /home/mc-sim/.ssh/id_rsa.pub. (Ваш публичный ключ сохранен в файле /home/mc-sim/.ssh/id_rsa.pub.) The key fingerprint is: (Контрольная сумма ключа:) fc:dd:1a:8d:2e:19:b2:36:63:fe:0a:e7:3c:85:a7:e8 mc-sim@FILES The key's randomart image is: (Случайное изображение ключа:) +--[ RSA 2048]----+ | | | | | | | . | | S. | | o.+. + | | ...*.o+ o | | .=O o. o | | .E+=*..o | +-----------------+ mc-sim@FILES:~$ # проверим созданные ключи mc-sim@FILES:~$ ls -la .ssh/ итого 16 drwx------ 2 mc-sim mc-sim 4096 Фев 11 02:42 . drwxr-xr-x 4 mc-sim mc-sim 4096 Фев 11 02:41 .. -rw------- 1 mc-sim mc-sim 1675 Фев 11 02:42 id_rsa -rw-r--r-- 1 mc-sim mc-sim 394 Фев 11 02:42 id_rsa.pub mc-sim@FILES:~$ # скопируем наш публичный ключ на удаленный сервер mc-sim@FILES:~$ scp .ssh/id_rsa.pub 10.0.0.6:/home/mc-sim/.ssh/authorized_keys The authenticity of host '10.0.0.6 (10.0.0.6)' can't be established. RSA key fingerprint is 8c:7b:98:51:2e:57:c9:53:54:aa:7d:bb:a6:92:c9:94. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.0.6' (RSA) to the list of known hosts. [email protected]'s password: scp: /home/mc-sim/.ssh/authorized_keys: No such file or directory (scp: /home/mc-sim/.ssh/authorized_keys: Нет такого файла или каталога) mc-sim@FILES:~$ # создадим отсутствующий каталог mc-sim@FILES:~$ ssh 10.0.0.6 mkdir /home/mc-sim/.ssh [email protected]'s password: mc-sim@FILES:~$ # еще раз попробуем скопировать публичный ключ mc-sim@FILES:~$ scp .ssh/id_rsa.pub 10.0.0.6:/home/mc-sim/.ssh/authorized_keys [email protected]'s password: id_rsa.pub 100% 394 0.4KB/s 00:00 mc-sim@FILES:~$ # попробуем подключиться к удаленной системе (пароль запрошен не будет) mc-sim@FIpLES:~$ ssh 10.0.0.6 Linux ARCHIV 3.0.0-1-486 #1 Sat Aug 27 15:56:48 UTC 2011 i686 The programs included with the Debian GNU/Linux sysptem are free software; the exact distribution tessh-keysign (/usr/lib/openssh/ssh-keysign)rms for each program are described in theppp individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have new mail. Last login: Fpri Nov 25 13:17:58 2011 mc-sim@ARCHIV:~$ logout Connection to 10.0.0.6 closed.
Для указания типа шифрования ключа задан параметр -t, а так же параметр -b, задающий размер ключа в байтах. Эти опции использовать рекомендуется. Кроме того, при создании ключа запрашивается некая passphrase. Это пароль расшифровки секретного ключа, который (если его задать) будет запрошен при попытке подключения. Данная опция позволяет зашифровать секретный ключ на случай компроментации, что повышает безопасность, но сводит на нет все удобство входа без ввода пароля.
Так же, обязательно стоит отметить такой момент безопасности. В случае, если поломают вашу учетку (у которой имеется секретный ключ в домашнем каталоге) на текущем сервере, то злоумышленник автоматически получает доступ и к серверу, на котором лежит соответствующий публичный ключ. Так что будьте крайне бдительны!
В данном разделе используется метод шифрования RSA, но если во всех командах заменить RSA на DSA, то соответственно будет использован тип шифрования DSA.
Другие типы аутентификации (hostbsed, GSSAPI…)
Некоторые другие типы аутентификации, возможно, в скором времени будут дополнены. Но некоторые гарантированно не будут рассмотрены, т.к. – устаревшие. Например не будет рассмотрена hostbased-аутентификация, которая работает только с протоколом SSH1.
Безопасность SSH сервера
Ниже приведены некоторые советы, позволяющие по максимуму снизить возможность взлома Вашего сервера:
- Необходимо запретить логин под пользователем root (параметр PermitRootLogin no в sshd_config ).
- Запрещение подключения с пустым паролем (параметр PermitEmptyPasswords no в sshd_config).
- Ограничить список пользователей, которым будет доступно подключение через ssh (параметр AllowUsers ssh_user1 ssh_user2 в sshd_config).
- По возможности использовать аутентификацию на основе открытого ключа и не использовать вход по паролю, особенно с недоверенных машин (параметр PubkeyAuthentication yes в sshd_config) .
- Запуск sshd на нестандартном порту, желательно из эфемерного диапазона – для Linux 32768 — 61000 (параметр Port 35571 в sshd_config)
- Желательно отключить использование протокола SSH1 (параметр Protocol 2 в sshd_config ).
- Время неактивности при установленном соединении желательно уменьшить о минимума. 60 секунд на ввод пароля, думаю, вполне достаточно (параметр LoginGraceTime 60 в sshd_config).
- Использование длинных SSH2 RSA-ключей (2048 бит и более). Системы шифрования на основе RSA считаются надёжными, если длина ключа не менее 1024 бит.
- Для доступа по ssh не использовать широко распространенные имена пользователей (например user, admin).
- Запуск sshd рекомендуется производить с параметрами: -u0 -4. Эти параметры запретят запись в лог DNS-имен клиентов (-u0), то есть будут записываться IP адреса. А так же параметр -4 заставит демон обрабатывать только IPv4 запросы. Для задания параметров запуска sshd используется файл /etc/default/ssh.
- Как вариант, можно отображать баннер всем, кто пытается подключиться. В некоторых случаях это заставит задуматься злоумышленника. Например следующего содержания (параметр Banner /etc/motd.ssh в sshd_config ):
# cat /etc/motd.ssh ************************************************************ This is a private server!!! All ssh login attempts are logged and monitored by our staff. All unauthorized login attempts will be investigated and repoeted to local authorities. If you have any login problem please contact helpdesk us at Phone: 888-555-777 or email us Email: [email protected] *************************************************************
- Защита сервера с помощью netfilter/iptables. Пример ниже.
Пример настройки iptables для защиты ssh от перебора паролей ( bruteforce-атак):
# Создаем цепочку для проверки попыток соединений на защищаемый порт iptables -N ssh_brute_check # Если за последние 10 минут (600 секунд) с одного адреса было 4 или более новых соединений — блокируем этот адрес iptables -A ssh_brute_check -m conntrack --ctstate NEW -m recent --update --seconds 600 --hitcount 4 -j DROP # В противном случае — разрешаем, и при этом заносим в список iptables -A ssh_brute_check -m recent --set -j ACCEPT # Очищаем цепочку INPUT (если необходимо) iptables -F INPUT # Разрешаем входящие пакеты по установленным соединениям iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Все попытки открыть новое соединение по порту 22 (ssh) направляем на проверку в созданную цепочку iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 22 -j ssh_brute_check # устанавливаем по-умолчанию запрещающую политику iptables -P INPUT DROP
Согласно данных правил, все попытки открыть новое SSH-соединение проверяются, и с одного IP-адреса можно открывать не более 3 соединений за 10 минут. Обратите внимание, что за одно соединение злоумышленник может проверить несколько паролей — число попыток аутентификации до обрыва соединения задает параметр MaxAuthTries в файле /etc/ssh/sshd_config. По умолчанию это число равно 6, так что в нашем примере злоумышленник сможет проверять не более 12 паролей за 10 минут. (c) http://ru.wikibooks.org/wiki/Iptables
Траблешуттинг
Системные журналы
Существует несколько мест, куда можно обратиться за разрешением проблем с ssh. Для начала, можно посмотреть записи, относящиеся к ssh в журналах /var/log/autch.log и /var/log/syslog. Вот небольшой пример, когда сервер работал на стандартном порту, каждую минуту из интернета были попытки подобрать пароль:
gw ~ # grep -i ssh /var/log/auth.log Feb 6 16:22:58 gw sshd[1039]: Received signal 15; terminating. Feb 6 16:22:58 gw sshd[11163]: Server listening on 0.0.0.0 port 22. Feb 6 20:14:18 gw sshd[12573]: Accepted password for root from 10.0.0.20 port 55050 ssh2 Feb 6 20:14:18 gw sshd[12573]: pam_unix(sshd:session): session opened for user root by (uid=0) Feb 7 00:03:59 gw sshd[12550]: pam_unix(sshd:session): session closed for user root Feb 7 05:58:44 gw sshd[13738]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mailer.arttour.ru user=root Feb 7 05:58:45 gw sshd[13738]: Failed password for root from 91.205.189.27 port 37561 ssh2 Feb 7 05:58:46 gw sshd[13743]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mailer.arttour.ru user=root Feb 7 05:58:48 gw sshd[13743]: Failed password for root from 91.205.189.27 port 38075 ssh2 ........ # далее сервер был запущен с ключом -n0 ........ Feb 7 11:31:15 gw sshd[14533]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.253.249.157 user=root Feb 7 11:31:16 gw sshd[14533]: Failed password for root from 61.253.249.157 port 54815 ssh2 Feb 8 00:22:42 gw sshd[15794]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=220.194.53.114 user=bin Feb 8 00:22:44 gw sshd[15794]: Failed password for bin from 220.194.53.114 port 42724 ssh2 Feb 8 13:35:06 gw sshd[17122]: Did not receive identification string from 95.132.37.105 Feb 8 13:35:07 gw sshd[17126]: Invalid user admin from 95.132.37.105 Feb 8 13:35:07 gw sshd[17126]: Failed none for invalid user admin from 95.132.37.105 port 3033 ssh2 Feb 8 13:35:07 gw sshd[17126]: pam_unix(sshd:auth): check pass; user unknown Feb 8 13:35:07 gw sshd[17126]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=105-37-132-95.pool.ukrtel.net Feb 8 13:35:09 gw sshd[17126]: Failed password for invalid user admin from 95.132.37.105 port 3033 ssh2 Feb 8 23:10:47 gw sshd[17896]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=189.206.39.51 Feb 8 23:10:49 gw sshd[17896]: Failed password for invalid user tribunal from 189.206.39.51 port 51725 ssh2 Feb 9 02:43:27 gw sshd[17991]: Did not receive identification string from 201.69.44.27 Feb 9 22:51:26 gw sshd[18532]: Address 91.205.189.27 maps to mailer.arttour.ru, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! Feb 9 22:51:26 gw sshd[18532]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=91.205.189.27 user=nobody Feb 9 22:51:29 gw sshd[18532]: Failed password for nobody from 91.205.189.27 port 51484 ssh2 ......... gw ~ #
Как видно, почти каждую секунду сервер пытаются взломать с “популярными” именами пользователей (root, nobody и др.)
Работа OpenSSH в режиме отладки
Если информации из системных журналов недостаточно, то можно запустить sshd в debug-режиме, указав в параметрах запуска демона (/etc/defauts/ssh) ключ -d. Так же, для диагностики отлично подойдет запуск клиента ssh с ключом -v (для бОльшей подробности можно задать -vv).
Проверка работы sshd (запущен ли процесс, слушает ли порт):
Проверить запущен ли sshd можно командой:
gw ~ # ps aux | grep ssh root 14371 0.0 0.0 8396 2944 ? Ss Feb07 0:09 sshd: root@pts/0 root 17514 0.0 0.0 5500 976 ? Ss Feb08 0:00 /usr/sbin/sshd -u0 -4 root 19844 0.0 0.0 3328 788 pts/0 S+ 17:40 0:00 grep --colour=auto ssh
Проверить, слушается ли необходимый порт можно командой:
gw ~ # ss -nal State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:22 *:*
Выводы
В данной статье я постарался изложить основные принципы работы OpenSSH сервера в Debian, рассказал, как установить сервер и как настроить. Описал основные методы аутентификации и основные схемы использования клиента SSH. Я планировал описать в статье о туннелировании трафика, но статья уже переросла все возможные размеры и тему туннелирования портов я пишу в следующей статье. Надеюсь, что материал был Вам полезен. До новых встреч!
Основной источник документации об OpenSSH: http://www.openssh.org/manual.html
Типы шифрования: http://www.bog.pp.ru/work/security.html
man ssh: http://www.opennet.ru/man.shtml?topic=ssh&category=1&russian=0
man sshd: http://www.opennet.ru/man.shtml?topic=sshd&category=8&russian=0
man ssh_config: http://www.opennet.ru/man.shtml?topic=ssh_config&category=5&russian=0
man sshd_config: http://www.opennet.ru/man.shtml?topic=sshd_config&category=5&russian=0
RFC на русском:
RFC 4251 — Архитектура протокола SSH http://rfc2.ru/4251.rfc
А так же куча RFC на буржуйском:
- RFC 4250 (англ.) — The Secure Shell (SSH) Protocol Assigned Numbers
- RFC 4251 (англ.) — The Secure Shell (SSH) Protocol Architecture
- RFC 4252 (англ.) — The Secure Shell (SSH) Authentication Protocol
- RFC 4253 (англ.) — The Secure Shell (SSH) Transport Layer Protocol
- RFC 4254 (англ.) — The Secure Shell (SSH) Connection Protocol
- RFC 4255 (англ.) — Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
- RFC 4256 (англ.) — Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
- RFC 4335 (англ.) — The Secure Shell (SSH) Session Channel Break Extension
- RFC 4344 (англ.) — The Secure Shell (SSH) Transport Layer Encryption Modes
- RFC 4345 (англ.) — Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
- RFC 4419 (англ.) — Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
- RFC 4432 (англ.) — RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
- RFC 4716 (англ.) — The Secure Shell (SSH) Public Key File Format
С Уважением, Mc.Sim!
/etc/ssh/ssh_config конфиг для клиента, а /etc/ssh/sshd_config конфиг для сервера. и при примере синтаксиса копирования по ssh забыли точку с запятой в конце. а за статью спасибо) прочитал кое что новое, которое как раз нужно было)
Пожалуйста. Приходите еще!
с замечанием немного не понял, где точку забыл и где конфиги указаны неверно?
Спасибо! Все очень по делу!
Замечательная статья. А в CentOS нету файлика /etc/default/ssh, и при его создании и добавлении параметров -u0 -4, с последующим перезапуском и проверкой ps aux | grep ssh нету в конце
root 17514 0.0 0.0 5500 976 ? Ss Feb08 0:00 usr/sbin/sshd
параметров -u0 -4
В CentOS каталог /etc/default имеет аналог в виде /etc/sysconfig. Вот в нем и будет лежать файл ssh, а скорей всего sshd. соответственно, после перезапуска и указания параметров в каталоге sysconfig эти параметры должны появиться.
Спасибо. Вот тут имя цепочки поправь, ато не пущает совсем =)iptables -A INPUT -m conntrack –ctstate NEW -p tcp –dport 22 -j ssh_brute_chec
Ога. Спасибо.
Уважаемый Mc.Sim, приветсвую.
В первую очередь хочется выразить огромную благодарность за проделанную Вами работу. Сильно помогли Ваши статьи.
А во вторую очередь, хочется спросить следующее: планируете ли Вы рассказать в будущем о ssh-тунелях? Если нет, буду очень признателен, если посоветуете дельный материал по интересующей теме..
Заранее признателен за ответ.
Приветствую, Vi
В обозримом будущем информация о ssh туннелях не планируется, хотя не исключено, что когда-то появиться.
Поделиться какой-то дельной статьей не могу, т.к. описывая какой-либо материал в статьях, я собираю информацию о теме по крупинкам. На данный момент я не встречал таких статей, которые бы мог рекомендовать по ssh туннелям, к сожалению. Лишь гугл вам в помощь )
Mc.Sim, спасибо за ответ.
Попробую собрать по крупинкам )
Еще раз спасибо за Ваш труд.
Пожалуйста. Приходите еще )
Добрый день.
Номера портов все же идут до 65536-1, то есть 65535 максимум. У вас же при описании алиасов SSH в примере порт больше указанного диапазона, то есть такого не может быть.