Эта статья является переводом текста Dru Lavigne (читать).
Я получил много откликов на мою предыдущую статью, посвященную использованию 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. Лишняя буква в названии произошла от слова (тут подразумевается 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. Если вам интересно, что означает аббревиатура , то определение данное по адресу http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci344945,00.html может быть полезным для удовлетворения вашего любопытства. (Конечно интересно. CBC - cipher block chaining - режим шифрования <со сцеплением блоков>. Термин относится к так называемым блочным шифрам (в которых данные шифруются блоками определенного размера). Грубо говоря применение таких шифров дает более устойчивый к взлому шифротекст, из-за того, что каждый блок шифротекста связан с предыдущим блоком. Это, например, позволяет избегать порождения одинакового шифротекста для совпадающих блоков открытого текста - прим. переводчика.) Итак, эта строка содержит упорядоченный список алгоритмов шифрования. Первый алгоритм из этого списка. который примет SSH сервер, будет использоваться для шифрования всех данных SSH сессии.
Имейте в виду, что файл /etc/ssh/ssh_config является глобальным клиентским конфигурационным файлом. Это значит, что значения определенные в этом файле, могут быть переопределены при помощи ключей программы ssh. Кроме того, если вам лень постоянно набирать одни и те же ключи, то вы можете написать индивидуальный конфигурационный файл в вашем домашнем каталоге. Например, вместо того что бы пользоваться ключом для соединения под пользователем , я мог создать файл ~/.ssh/config и написать там следующее: HostName 10.0.0.1
User biko
Все параметры SSH являются регистрозависимыми, поэтому не забудьте букву в слове сделать заглавной.
Теперь, всякий раз когда я пишу ssh 10.0.0.1, мне не надо помнить о необходимости добавлять ключ , я сразу получу запрос на ввод пользовательского пароля 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 все еще может удаленно входить в систему, то самое время поискать синтаксическую ошибку в добавленной строке. Довольно просто забыть, что конфигурационные параметры регистрозависимы. В данном случае правильно было бы написать , в то время как написание тихо игнорируется и приводит к неприятностям. Вы ведь не хотите через полгодика случайно узнать, что любой желающий может получить удаленный доступ к серверу, в то время как вы думаете, что это могут делать всего два человека?
Наконец, несколько полезных ссылок:
- Десятка частозадаваемых вопросов от автора книги (см. http://sysadmin.oreilly.com/news/sshtips_0101.html)
- Список бесплатных SSH клиентов и серверов для разнообразных операционных систем (см. http://www.freessh.org/)
- Руководство о конфигурировании SSH сервера на аппаратуре Cisco (см. здесь)
В следующей статье я расскажу об основах виртуальных частных сетей и семействе протоколов защищенной передачи данных IPSec.
|
