Удаленное управление Linux-сервером по протоколу SSH
Изначально UNIX-системы проектировались для многопользовательской работы. Для обеспечения удаленного доступа к ПК служит целый ряд приложений и протоколов — наиболее известными в Linux-системах являются rlogin, rsh, rcp и telnet. Многие годы они исправно справлялись со своими задачами, но в условиях стремительного роста Сети их применение стало создавать серьезную угрозу для безопасности. Работа подобных программ оставляет злоумышленнику множество путей для перехвата и анализа рабочего трафика и использования полученных данных с недобрым умыслом или в корыстных целях.
Для обеспечения достаточного уровня безопасности был разработан SSH (Secure Shell) — так называется и набор программ, необходимых для входа на удаленный компьютер, исполнения команд и перемещения файлов между машинами, и задействованный в нем протокол. SSH обеспечивает высокий уровень аутентификации и безопасности передачи данных при использовании незащищенных каналов. Появившись в 1995 году, SSH завоевал доверие пользователей и стал очень популярным, в настоящее время он рассматривается как проект стандарта Интернет. Фактически SSH уже негласно завоевал статус стандарта Интернет на безопасные терминальные соединения. На данный момент существуют две реализации протокола SSH — SSH1 и SSH2. Правда, применение SSH1 не рекомендуется по причине подверженности атакам типа man-in-the-middle (временная подмена сервера).
Сегодня известно множество типов атак и способов перехвата секретных данных. Противостоять всем им в одном проекте — очень трудоемкая задача, поэтому разработчики создавали новую систему на основе анализа наиболее распространенных атак, таких как:
- IP spoofing — злоумышленник посылает свои пакеты, маскируя их с помощью подмены адреса под пакеты разрешенной машины;
- IP source routing — атакующий изменяет содержание проходящих через него пакетов с разрешенной машины;
- DNS spoofing — злоумышленник подменяет записи в сервере имен (nameserver);
- прослушивание нешифрованных паролей и других данных (как в командах rsh, telnet и др.);
- подслушивание данных аутентикации X11 и подлог соединения к серверу X11.
В дополнение разработчики снабдили SSH возможностью сжатия передаваемых данных и туннелирования каналов внутри установленного соединения, что позволяет гибко использовать систему, сделав безопасными практически любые соединения. Сложность возникает при попытке туннелирования комплексных протоколов, таких, например, как FTP (напомним, что он создает два соединения: одно для команд, а другое для передачи данных). Некоторые пакеты SSH позволяют обезопасить оба tcp-канала протокола FTP, для чего следует применять утилиту sftp.
Безопасность в SSH обеспечивается широким использованием криптоалгоритмов. Для аутентификации сервера и клиента используются алгоритмы с открытым ключом, в которых для работы создается пара ключей: открытый (public key) и секретный (private key). Сообщение шифруется одним ключом, а дешифруется другим, причем расшифровку невозможно провести с помощью ключа шифрования. Клиент публикует свой открытый ключ и любой другой пользователь может послать ему зашифрованное данным ключом сообщение. При этом никто, кроме обладателя секретного ключа, не может расшифровать послание. Поэтому секретный ключ должен надежно храниться обладателем.
При каждом соединении выполняется аутентификация сервера, что не позволяет выполнить подмену сервера или трафика. Клиент, который хочет установить соединение, шифрует данные известным ему открытым ключом сервера и отправляет их серверу, который должен расшифровать их при помощи известного только ему секретного ключа и отправить их назад. Клиент сравнивает отосланные и полученные данные — таким образом клиент может быть уверен в том, что сервер является именно тем, к которому он обращался. Аутентификация клиента может выполняться одним из нескольких доступных способов: host-based (как в устаревших r-командах), с помощью открытых ключей, с помощью Kerberos, парольная, интерактивный обмен с помощью дополнительных средств. Это повышает надежность аутентификации, а также делает систему более гибкой и упрощает ее использование. При установке соединения сервер отсылает список поддерживаемых методов аутентификации, которые клиент по очереди пытается применить. По умолчанию порядок следующий: host-based, с помощью открытых ключей, парольная (при этом пароль шифруется асимметрическим алгоритмом). После этого из имеющихся у клиента и сервера пар ключей генерируется ключ симметрического шифрования, который используется далее для шифрования всего соединения. Проверка целостности пакетов с помощью контрольных сумм md5 или sha в протоколе SSH2 позволяет отследить любые их изменения, при обнаружении которых соединение незамедлительно разрывается.
Рассмотрим наиболее популярный свободный набор сетевого инструментария SSH — OpenSSH. Изначально он был реализован для OpenBSD, а затем портирован под другие ОС. Разработчики данного пакета приложили немало усилий, чтобы он был свободен от каких-либо патентных ограничений и не создавал проблем с авторскими правами. К примеру, запатентованный алгоритм IDEA в нем не поддерживается. Патентное ограничение на использование RSA больше не действует, поэтому данный алгоритм реализован в OpenSSH в полной мере. Кроме того, в современной реализации OpenSSH учтены и исправлены все известные уязвимости и недоработки, а открытый код проекта OpenSSH позволяет компьютерному сообществу быстро находить все его недочеты. OpenSSH можно найти как на домашней странице http://www.openssh.com/, так и на других ресурсах Интернета.
Для успешной установки OpenSSH из исходных текстов необходимо наличие в системе таких пакетов, как ZLib и OpenSSL, а также, конечно, утилиты make, компилятора и т.п. Для реализации дополнительных возможностей потребуются некоторые другие пакеты, список которых можно найти в файле INSTALL пакета OpenSSH.
После того как получен архив исходных текстов, необходимо распаковать его (например, ‘tar xzvf openssh-4.7p1.tzr.gz’) и перейти в полученный каталог (‘cd openssh-4.7p1’). Сборка пакета в общем случае тривиальна и выполняется последовательностью команд
‘./configure’, ‘make’. Для установки следует выполнить ‘make install’ с правами суперпользователя (root). При этом по умолчанию OpenSSH будет установлен в структуру каталогов с префиксом /usr/local (исполнимые модули —
/usr/local/bin, файлы конфигурации —
/usr/local/etc, сервер — /usr/local/sbin и т.п.). Для изменения путей установки следует указать желаемое в первой команде configure, например установка в домашний каталог пользователя user: ‘./configure --prefix=/home/user’ —
в этом случае всю установку и запуск сервера может произвести непривилегированный пользователь. Все доступные параметры настройки сборки пакета можно получить с помощью команды ‘./configure --help’. Впоследствии запуск сервера ssh (демона sshd) обычно выполняется автоматически при загрузке ОС из командного файла наподобие
/etc/rc.d/rc.local.
После установки сервер, как правило, работоспособен без каких-либо изменений файла конфигурации shd_config, который представляет собой набор действующих и пустых строк и строк-комментариев. Действующая строка содержит название параметра и его значение, например Port 10022 определяет, что сервер SSH должен прослушивать непривилегированный порт 10022 — это может пригодиться для запуска демона sshd от имени некоторого пользователя без прав root. В данной статье нет возможности описать все многообразие параметров, поэтому кратко рассмотрим лишь некоторые из них.
Пример части файла конфигурации sshd_config см. на листинге 1.
Листинг 1
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
LoginGraceTime 60
PermitRootLogin No
RhostsAuthentication no
IgnoreRhosts yes
PermitEmptyPasswords no
Subsystem sftp /usr/libexec/sftp-server
X11Forwarding yes
X11UseLocalHost yes
Port определяет порт для ожидания ssh-соединения.
Protocol определяет версии протокола SSH. По соображениям безопасности лучше отключить прием соединений SSH1.
HostKey указывает расположение файлов с закрытыми ключами для аутентификации хоста (создаются командой ssh-keygen).
LoginGraceTime устанавливает время в секундах, за которое клиент должен войти в систему после создания соединения.
PermitRootLogin — значение No предотвращает непосредственную регистрацию пользователя root.
Установленные в примере значения параметров RhostsAuthentication и IgnoreRhosts запрещают .rhost-аутентификацию.
PermitEmptyPasswords no не допускает использования пустых паролей.
Subsystem описывает дополнительные подсистемы. В данном примере определена подсистема с именем sftp для безопасной передачи файлов. Третий необходимый параметр указывает на команду, которая выполняется по запросу подсистемы. По умолчанию ни одна подсистема не определена.
Параметры X11Forwarding yes и X11UseLocalHost yes определяют, что сервер sshd будет шифровать трафик X11, перенаправляя его через порт локальной машины. При этом клиент SSH тоже должен уметь работать с перенаправленным соединением X11.
Для генерации ключей в OpenSSH следует запустить команду ssh-keygen, указав тип генерируемого ключа (обычно используют ssh-keygen –t rsa). Утилита запросит ввода секретной фразы, которую стоит сделать устойчивой ко взлому, то есть использовать спецсимволы, различные регистры и т.п. В результате будет создано два файла (по умолчанию ~/.ssh/id_rsa и ~/.ssh/id_rsa.pub) с секретным и открытым ключами; второй необходимо безопасно передать на сервер и дополнить им файл ~/.ssh/authorized_keys, который содержит по одной строке на каждый ключ.
В случае если при входе на сервер не обнаруживается подходящих ключевых записей, то выполняется проверка пользователя с помощью пароля. Генерация ключей для аутентификации хоста производится командой ‘ssh-keygen –t rsa –f PATH_TO_KEYFILE -N’, где PATH_TO_KEYFILE — путь с минимально возможными правами доступа к создаваемому файлу секретного ключа, который необходимо указать в файле настройки sshd_config директивой HostKey. Таким же образом создаются ключи DSA. Открытая часть ключа передается клиенту при первом его соединении с сервером. Клиент, как правило, задает пользователю вопрос о принятии ключа, на который необходимо ответить утвердительно для установки соединения.
Соединение с сервером выполняется в общем случае командой ‘ssh [-l remoteuser] host [command]’ или ‘ssh remoteuser@host [command]’. Команду ssh также можно применять для защиты других сервисов, перенаправив их соединение через защищенный канал с помощью ключа командной строки ‘-L port:host:hostport’. В этом случае система прослушивает порт port на локальной машине и при появлении соединения к нему перенаправляет его по защищенному каналу на host:hostport. Для шифровании X-сессии при работе в графической среде необходимо указать опцию ForwardX11 yes в файле настройки ssh-клиента (ssh_config).
Кроме клиента ssh-пакета OpenSSH, существует целый ряд проектов для обеспечения удаленной работы пользователя с ssh-сервером.
Рассмотрим клиент Putty, являющийся наиболее популярным. Данный продукт свободного программного обеспечения распространяется как в бинарном виде для выполнения на платформах Microsoft Windows, так и в исходных текстах, что позволяет при желании собрать пакет для работы в большинстве операционных систем. Его популярность сподвигла сторонних разработчиков на выпуск неофициальных портов под мобильные телефоны под управлением Symbian OS и коммуникаторы с Windows Mobile, что позволяет владельцам таких устройств при необходимости создать соединение с сервером, не имея рядом компьютера. Putty — это SSH-клиент, который позволяет гибко устанавливать параметры соединения с каждым из серверов, а также ведет журналы соединений, дает возможность настраивать шрифты, цвет, разрешение и тип консоли, перекодировку символов, поддерживает работу через прокси-сервер и обслуживает перенаправленные через SSH соединения X11. Клиент Putty работает с оборудованием по протоколам SSH1, SSH2, telnet, rlogin и raw. Интерфейс входящих в него утилит довольно простой и не требует особых пояснений.
Весь набор утилит Putty можно установить как путем запуска инсталлятора, так и просто скопировав исполняемые файлы. В состав набора утилит входят: putty — клиент ssh, telnet, rlogin и raw; puttytel — только telnet-клиент; puttygen — генератор dsa- и rsa-ключей, pagent — агент аутентификации; plink — интерфейс командной строки для Putty; pscp — безопасное копирование файлов и psftp — безопасный ftp-клиент.
Для использования аутентификации клиента с помощью алгоритмов с открытым ключом необходимо предварительно создать ключи с применением утилиты puttygen. При нажатии на кнопку Generate происходит создание пары ключей, запись которых производится кнопками Save public key и Save private key. Закрытый ключ, как уже отмечалось, следует надежно хранить у себя в системе, а открытый передать на сервер. Если на сервере установлен пакет OpenSSH, перед отправкой файла открытого ключа его необходимо скорректировать. Дело в том, что файл, сгенерированный программой puttygen, выглядит следующим образом (см. листинг 2). Следует удалить первую, вторую и последнюю строки, а остальные соединить в одну, добавив в конце пробел, а в начале — «ssh-rsa» для RSA-ключа или «ssh-dsa» для DSA-ключа и отделив эти фразы от самого ключа пробелом. Скорректированной строкой необходимо дополнить файл ~/.ssh/authorized_keys на сервере в каталоге пользователя.
Листинг 2
—— BEGIN SSH2 PUBLIC KEY ——
Comment: “rsa-key-20070915”
AAAAB3NzaC1yc2EAAAABJQAAAIEAq3tF++nL16ojh9ayTSE66nyrBM6THMzm1Grp
L1vZmDYhp8F+ZZGlfan32G2eC6ACzU4LtWTbXppBmnuQ1utzsS2uAFnOAh5mocQv
OUTcp10HnxIp5Lhr2PN9OzJ5P1hwZWoBeNBFu60jc5fCqO50kLQmfeTRSioP1oY7
QIAgVtE=
—— END SSH2 PUBLIC KEY ——
В данной статье описаны основные особенности и возможности протокола SSH и способы его применения. Все многообразие настроек и способов использования SSH в рамках одной статьи рассмотреть невозможно, однако все они необходимы, как правило, только для администрирования «тяжелых» серверов. Даже минимально настроенный сервер SSH обеспечивает высокую защищенность от большинства видов атак. Тем не менее при проектировании стойкости системы необходим комплексный подход к данному вопросу, предусматривающий, например, отключение всех неиспользуемых сервисов, грамотную настройку межсетевого экрана, отказ от любых протоколов с нешифрованной передачей пароля и т.п. Не стоит также исключать человеческий фактор — небрежное отношение клиента к секретным ключам или к информации о серверных логинах может поставить под угрозу безопасность сервера.
 |
|
