SSH: как устроено защищённое удалённое управление

SSH, Secure Shell, появился как ответ на проблему, что старые средства удалённого доступа, telnet и rsh, передавали пароли и команды открытым текстом. Любой узел на пути мог их прочитать. SSH шифрует весь сеанс, проверяет подлинность сервера и позволяет надёжно войти на удалённую машину, выполнить команду или передать файл. Стандартный порт — TCP 22.

Сегодня протокол — основной способ управления серверами, сетевым оборудованием и многими устройствами, работающими под Linux. Он встроен в Linux, macOS и современные версии Windows как готовая программа командной строки.

Сначала стороны обмениваются версиями и списками поддерживаемых алгоритмов и выбирают общий набор. Затем происходит обмен ключами с использованием алгоритма типа Диффи — Хеллмана, в результате чего получается общий секрет, которого не увидит наблюдатель. Из него выводятся ключи симметричного шифрования и проверки целостности сообщений. Подробнее о самом принципе написано на странице про Диффи — Хеллмана.

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

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

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

Помимо терминала протокол переносит файлы: на нём построены scp и SFTP, о котором есть отдельная страница. Он умеет пробрасывать порты: локальный, когда порт вашего компьютера передаётся через сервер на другой адрес, и удалённый, когда наоборот. Так можно безопасно открыть в браузере панель, доступную только с самого сервера, не публикуя её наружу.

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

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

Порт 22 часто считают недостатком и меняют номер, полагая, что это защита. Смена порта уменьшает шум в журналах от автоматических сканеров, но безопасность даёт только стойкая аутентификация. Другое заблуждение: SSH сам по себе неуязвим. Слабый пароль, устаревшее программное обеспечение или утёкший закрытый ключ сводят защиту на нет.

Чтобы посмотреть, что происходит, запустите клиент с ключом -v: он покажет выбранные алгоритмы и способ аутентификации. На стороне сервера настройки лежат в файле sshd_config, а попытки входа фиксируются в системных журналах. Как правильно создавать и хранить ключи, описано на странице про ключи SSH.

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