Открытая криптография. Конфигурирование SSH.во FreeBSD


Dru Lavigne
перевод Станислава Лапшанского
Впервые опубликован: http://www.computerra.ru.


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

В начале этой статьи я коснусь вопросов конфигурирования SSH, а в конце дам ссылки на утилиты, при помощи которых можно устанавливать SSH соединение между вашей FreeBSD и рядом других систем.

В прошлой статье мы отметили, что FreeBSD позволяет как устанавливать, так и принимать SSH соединения в первоначальной конфигурации, т.е. "из коробки". Кроме того, мы выяснили, что имеется возможность повысить защищенность системы аутентификации, если использовать предварительно сгенерированную пару ключей, открытый ключ которой должен быть скопирован на SSH сервер.

Пакет OpenSSH помимо прочего содержит утилиту ssh-agent. Это так называемый агент SSH аутентификации (говоря русским языком, это демон занимающийся кешированием ваших секретных ключей, для того, чтобы секретную фразу при обращении к ключу можно было вводить пореже - прим. переводчика). На сайте IBM DeveloperWorks (см. http://www-106.ibm.com/developerworks/library/l-keyc.html) есть отличная серия статей, в которой описывается использование этого агента. Кроме того, в этой серии статей, автор обстоятельно рассказывает, как в паре работают открытый и секретный ключи, а так же дает массу полезных ссылок для самостоятельного изучения.

Поскольку система SSH состоит из клиента и сервера, ее конфигурирование осуществляется при помощи двух файлов. Неудивительно, что один из них называется ssh_config, а другой - sshd_config. Лишняя буква "d" в названии произошла от слова "daemon" (тут подразумевается SSH демон или, другими словами, SSH сервер), о ней не следует забывать. Однажды во время одной из моих самых первых попыток изменения конфигурационных файлов системы SSH, я ошибочно добавила в конфигурационный файл клиента строку, предназначавшуюся для файла сервера, после чего долго чесала затылок в раздумьях, отчего же в моей системе не произошло никаких изменений. Никогда не забывайте, что "клиент" - это машина, за которой вы сидите, а "сервер" - компьютер, к которому вы собираетесь обратиться.

Каждый из этих конфигурационных файлов имеет подробнейшую страницу онлайнового man-руководства, в которой тщательно описана каждая конфигурационная опция. Поскольку вас могут заинтересовать неописанные в данной статье опции, обе страницы являются хорошими кандидатами для прочтения. Давайте начнем с просмотра клиентского конфигурационного файла, поставляемого с системой. (Некоторые строки разбиты на части для того, чтобы убраться в экран вашего браузера.)
$ cat /etc/ssh/ssh_config

# $OpenBSD: ssh_config,v 1.15 2002/06/20 20:03:34 stevesk Exp $
# $FreeBSD: src/crypto/openssh/ssh_config,v 1.2.2.6 2002/07/25 16:03:44
# fanf Exp $

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Это основной конфигурационный файл для ssh клиента.
# Для дополнительной информации смотрите man 5 ssh_config.
# В этом файле содержатся "умолчальные" настройки для пользователей
# их значения могут быть изменены в конфигурационных файлах конкретных
# пользователей или при помощи параметров командной строки.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Конфигурационные параметры используются в следующем порядке:
# 1. опции указываемые в командной строке
# 2. пользовательские файлы настройки
# 3. основной файл настройки
# Значение любого конфигурационного параметра присваивается
# однократно при первой его встрече
# Таким образом параметры относящиеся к конкретному хосту
# должны упоминаться в начале файла, остальные параметры могут
# располагаться в конце

# Site-wide defaults for various options
# Умолчальные значения для некоторых опций

# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsAuthentication no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# BatchMode no
# CheckHostIP no
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
# aes192-cbc,aes256-cbc
# EscapeChar ~
# VersionAddendum FreeBSD-20020629

Вероятно, вы уже заметили, что каждая строка в этом файле начинается на символ решетки "#" (т.е. это сплошные комментарии). Это не означает, что SSH клиент вообще не сконфигурирован. Наоборот, в этом файле демонстрируются "умолчальные" параметры конфигурации SSH клиента. Если вы хотите изменить некий параметр, уберите стоящую перед ним "решетку", и затем смените его значение на необходимое. Все возможные значения параметров описаны man-руководстве по ssh_config.

Посмотрев страницу man-руководства, вы заметите, что некоторые конфигурационные опции применимы только к определенным версиям SSH. Пользуйтесь SSH версии 2, где это только возможно. Если вы используете FreeBSD ssh клиент только для подключения к FreeBSD ssh серверу, то установка по умолчанию гарантирует использование SSH версии 2. Однако, если вы воспользуетесь своим FreeBSD ssh клиентом для подключения к серверам, на которых используются системы отличные от FreeBSD, то существует вероятность, что сервер вынудит вашего клиента использовать SSH версии 1, поскольку это все, на что он способен.

Каковы отличия между первой и второй версией протокола? Если вы попробуете поискать ответ на этот вопрос в Интернете, то наиболее частый ответ будет таким: версия "два" полностью переписана с учетом проблем в безопасности, обнаруженных в версии "один". Кроме того, эти две версии отличаются друг от друга списком поддерживаемых алгоритмов: Версия Шифрующий алгоритм
1 DES, 3DES, blowfish
2 AES-128, AES-192, AES-256, blowfish, CAST-128, ArcFour
Версия Функция дайджеста
1 нет
2 HMAC-MD5, HMAC-SHA-1, HMAC-RIPEMD


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

Вот строка из конфигурационного файла:
# Protocol 2,1

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

Если вы поменяете содержимое этой строки на:
Protocol 2

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

Две строки связаны с шифрами или шифрующими алгоритмами.
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,
arcfour, aes192-cbc,aes256-cbc

Первая строка используется при соединении по SSH версии 1. На странице man-руководства обращается внимание на то, что использовать алгоритм DES стоит только в исключительных случаях, когда ничто другое использовать нельзя. Обратите внимание, что по умолчанию для шифрования выбран алгоритм 3DES (тройной DES), вместо гораздо более мощного и эффективного алгоритма blowfish. Это сделано в целях совместимости, поскольку многие системы не поддерживают blowfish. К сожалению многие системы поддерживают SSH только первой версии и только алгоритм DES. Если это ваш случай, то все попытки соединения потерпят неудачу. Поменяйте в конфигурационном файле первую строку на:
Cipher DES

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

Вторая строка имеет дело с шифрами, применяемых при соединении по второй версии SSH. Если вам интересно, что означает аббревиатура "cbc", то определение, данное по адресу http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci344945,00.html может быть полезным для удовлетворения вашего любопытства. (Конечно интересно. CBC - cipher block chaining - режим шифрования "со сцеплением блоков". Термин относится к так называемым блочным шифрам (в которых данные шифруются блоками определенного размера). Грубо говоря, применение таких шифров дает более устойчивый к взлому шифротекст, из-за того, что каждый блок шифротекста связан с предыдущим блоком. Это, например, позволяет избегать порождения одинакового шифротекста для совпадающих блоков открытого текста - прим. переводчика.) Итак, эта строка содержит упорядоченный список алгоритмов шифрования. Первый алгоритм из этого списка, который примет SSH сервер, будет использоваться для шифрования всех данных SSH сессии.

Имейте в виду, что файл /etc/ssh/ssh_config является глобальным клиентским конфигурационным файлом. Это значит, что значения, определенные в этом файле, могут быть переопределены при помощи ключей программы ssh. Кроме того, если вам лень постоянно набирать одни и те же ключи, то вы можете написать индивидуальный конфигурационный файл в вашем домашнем каталоге. Например, вместо того, чтобы пользоваться ключом "l" для соединения под пользователем "biko", я могла создать файл ~/.ssh/config и написать там следующее:
HostName 10.0.0.1
User biko

Все параметры SSH являются регистрозависимыми, поэтому не забудьте букву "U" в слове "User" сделать заглавной.

Теперь, всякий раз когда я пишу ssh 10.0.0.1, мне не надо помнить о необходимости добавлять ключ "l", я сразу получу запрос на ввод пользовательского пароля biko.

Если в качестве параметра команды ssh, вместо IP адресов вы используете имя хоста или FQDN (full qualified domain name - полное имя хоста - прим. переводчика), то, вероятно, можете заметить, что ваш клиент "замирает" какое-то время, которое требуется ему для того, чтобы выполнить разрешение имени в IP адрес. Вы можете заметить разницу в скорости, если клиентской машине добавите сведения о SSH сервере в файл /etc/hosts.

Теперь давайте слегка сменим направление нашего повествования и перейдем к конфигурационному файлу SSH сервера /etc/ssh/sshd_config. Этот файл напоминает файл конфигурации клиента тем, что все строки в нем закомментированы символом "#" и тем, что все конфигурационные параметры описаны в соответствующей странице man-руководства.

Давайте поговорим о SSH демоне более обстоятельно. Помимо прочего, для нормальной работы SSH сервера в вашей системе должен быть открыт 22 порт (т.е. в настройках брандмауэра (файрволла), если он у вас есть, должно присутствовать соответствующее правило - прим. переводчика). Если ваша машина имеет доступ в Интернет, то любой желающий может обратиться на ваш компьютер по этому порту. Так что, если вы используете аутентификацию по паролю и злоумышленник подберет правильные имя пользователя и пароль, то он сможет получить доступ к вашему компьютеру с правами этого пользователя. Теперь вам ясно, почему пользователь root не может напрямую входить в систему через SSH, а так же почему использование системы аутентификации на базе открытого и секретного ключа совместно с секретной фразой гораздо надежнее парольной защиты?

Важно пользоваться свежей версией SSH демона. Для того, чтобы проверить, какая версия SSH установлена на вашей системе, следует, при помощи утилиты telnet, подключиться к 22 порту сервера. Если вы сидите за сервером, нижеприведенная команда должна сработать, иначе укажите параметром telnet'а IP адрес сервера.
telnet localhost 22
Trying ::1...
Connected to localhost.
Escape character is '^]'.
SSH-1.99OpenSSH_3.4p1 FreeBSD-20020702
quit ^^^^^
Connection closed by foreign host.

Удостоверьтесь, что используемая вами версия OpenSSH не ниже 3.3 (на самом деле следует удостовериться, что используемая версия самая свежая, рисковать в таких делах не стоит - прим. переводчика). Любые программы, включая программы, предназначенные для обеспечения безопасности, потенциально уязвимы, поэтому очень важно использовать программное обеспечение, пропатченное на предмет исправления всех известных на текущий момент уязвимостей. Это особенно важно для программ типа OpenSSH, т.е. программ, которые используются для удаленного доступа к компьютерам.

Если вы регулярно пользуетесь cvsup и portupgrade, то ваша FreeBSD, скорее всего, пребывает во вполне свежем виде. Кроме того, не будет лишним подписаться на лист рассылки security-notifications@freebsd.org, в котором сообщаются все последние обнаруженные уязвимости в системе FreeBSD. На официальном сайте проекта FreeBSD опубликованы инструкции, как подписаться на этот лист, а также список последних обнаруженных уязвимостей (см. http://www.freebsd.org/security).

Кроме того, вы можете установить самую новую версию OpenSSH, из коллекции портов /usr/ports/security/openssh (я, например, так и делаю, поскольку на мой взгляд обновить OpenSSH из порта несколько проще, чем пересобирать всю систему из-за появления очередной уязвимости - прим. переводчика). Эта статься подготовлена с использованием FreeBSD 4.7-RELEASE с OpenSSH, включенной в базовую поставку системы.

Существует несколько путей контроля того, кто и откуда будет иметь доступ к вашему демону SSH. Во-первых, это брандмауэр. Если вам не хочется, чтобы кто-нибудь забрался на ваш SSH сервер через Интернет, поместите его за брандмауэр, в котором будут установлены правила, запрещающие доступ к 22 порту. Однако, если у вас есть пользователи, которые пользуются SSH сервером через Интернет, вам, напротив, придется добавить правило, разрешающее доступ к 22 порту. Если клиенты имеют статические IP адреса, то можно задать правила на доступ только с указанных IP адресов.

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

Итак, я написала простенький баннер:
$ cat /etc/ssh/banner
************************************************************

This is a private system!!! All connection attempts are
logged and monitored. All unauthorized connection
attempts will be investigated and
handed over to the proper authorities.

Это частная система! Все соединения записываются и отслеживаются.
Все несанкционированные попытки доступа будут расследованы и
переданы куда следует.

*************************************************************

Теперь скажем демону, чтобы он показывал наш баннер, для этого замените следующую строку в файле /etc/ssh/sshd_config с:
#Banner /some/path

на
Banner /etc/ssh/banner

Баннер будет показываться перед запросом пароля или секретной фразы. Имейте в виду, что баннер показывается только клиентами, использующими протокол SSH версии 2, в версии 1 баннеры не поддерживаются.

Если ваши клиенты не имеют постоянных IP адресов или осуществляют доступ с нескольких компьютеров, то указать в правилах брандмауэра IP адреса, с которых будет можно обращаться к SSH серверу, будет не так просто. К счастью, при помощи конфигурационного параметра AllowUsers, вы можете ограничить круг пользователей, которые смогут авторизоваться на вашем SSH сервере. Эта строка устанавливает разрешения для пользователей biko и genisis:
AllowUsers genisis biko

При попытке соединения с SSH сервером, пользователи, не включенные в этот список, так же будут получать приглашение на ввод пароля, однако, несмотря на то, что даже если они введут правильные имя пользователя и пароль, они все равно получат сообщение об ошибке авторизации. Сообщение об ошибке авторизации будет выведено на консоль демона SSH, скопировано в /var/log/messages и послано администратору в составе ежедневного отчета о состоянии безопасности системы. Как вы убедились, это очень полезная опция, для того что бы вставить ее в конфигурационный файл. Точность никогда не бывает лишней, поэтому если ваши пользователи всегда пользуются одной и той же машиной, то для ужесточения ограничений, можно сделать так:
AllowUsers genisis@10.0.0.2 biko@10.0.0.2

Однако не увлекайтесь подобными вещами, если ваши пользователи сидят за несколькими компьютерами или не имеют статических IP адресов. Например, если пользователь genisis попробует подключиться с IP адреса 192.168.0.1, то он получит сообщение о запрете соединения.

В зависимости от ваших пожеланий, вы можете вставить в конфигурационный файл следующие строки:
ClientAliveInterval 120
ClientAliveCountMax 2

Первая строка указывает на то, что если клиент не пошлет серверу никаких данных на протяжении 120 секунд, то сервер пошлет ему запрос, на который клиент должен ответить, для того, чтобы обозначить свое присутствие. Во второй строке сказано, что если после 4 минут (120 секунд * 2) клиент не пошлет серверу ответ, то сервер закроет соединение.

Кроме этого, вы можете поменять параметр этой строки:
#Port 22

на какой-нибудь другой номер порта. Если вы поменяете номер порта, не забудьте удостовериться, что ваши клиенты знают, какой порт они должны использовать для того, чтобы подключиться к SSH серверу. Они могут указать его или в командной строке ssh, или в конфигурационном файле ssh_config. Таким способом вы чуть-чуть увеличиваете безопасность системы, предотвращая случайные или преднамеренные попытки подключения и сканирования 22 порта, однако это не поможет, если хитрый злоумышленник подключится к вашему порту программой telnet - он сразу увидит, что на нем "висит" SSH демон.

Если вы не хотите что бы весь мир узнал, что ваш SSH сервер работает на FreeBSD, поменяйте этот параметр:
# VersionAddendum FreeBSD-20020629

Вы наверное помните, что было выдано на экран, когда я, воспользовавшись telnet'ом, соединилась с 22 портом моего SSH сервера. Если я поменяю этот параметр на нечто подобное:
VersionAddendum For Authorized Users Only!!!!

то результатом обращения при помощи telnet'а будет следующая строка:
SSH-2.-OpenSSH_3.4p1 For Authorized Users Only!!!!

Обратите внимание, что несмотря на это, версия SSH демона все равно выводится на экран. Это еще один повод для того, чтобы всегда пользоваться только самой свежей и пропатченной версией сервера, поскольку любой, кто умеет пользоваться telnet'ом, может узнать, какие эксплоиты можно применить к вашему серверу.

Если компьютер, на котором установлен SSH сервер, имеет несколько IP адресов, то на всех них на 22 порту будут приниматься SSH соединения. Если вам требуется, чтобы соединения принимались только на одном из адресов, воспользуйтесь этим параметром:
#ListenAddress 0.0.0.0

Замените "0.0.0.0" на желаемый IP адрес.

Не забывайте о том, что если вы поменяли конфигурационный файл демона SSH, то для того, чтобы изменения вступили в силу, необходимо послать демону сигнал "1":
killall -1 sshd

После информирования sshd о изменениях, всегда следует проверить их при помощи клиентской программы ssh. Например, если я добавлю в конфигурационный файл следующую строку:
Allowusers genisis biko

но несмотря на это обнаружу, что пользователь dlavigne все еще может удаленно входить в систему, то самое время поискать синтаксическую ошибку в добавленной строке. Довольно просто забыть, что конфигурационные параметры регистрозависимы. В данном случае правильно было бы написать "AllowUsers", в то время как написание "Allowusers" тихо игнорируется и приводит к неприятностям. Вы ведь не хотите через полгодика случайно узнать, что любой желающий может получить удаленный доступ к серверу, в то время как вы думаете, что это могут делать всего два человека?

http://www.onlamp.com/pub/a/bsd/2002/11/28/FreeBSD_Basics.html.

Обновлено: 12.03.2015