Рукопожатие SSH и аутентификация ключом хоста

SSH начинается с TCP-соединения с портом 22. После установления соединения клиент и сервер обмениваются строками версий, такими как SSH-2.0-OpenSSH_9.3, которые указывают версию протокола и реализацию. Этот обмен версиями позволяет обеим сторонам подтвердить совместимость до продолжения работы.

После обмена версиями обе стороны отправляют пакеты SSH_MSG_KEXINIT со списками поддерживаемых алгоритмов. Эти списки охватывают методы обмена ключами, типы ключей узлов, симметричные шифры, алгоритмы MAC и сжатие. Пересечение обоих списков определяет алгоритмы, выбранные для сеанса.

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

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

При первом подключении к новому серверу клиент ещё не знает открытый ключ узла. SSH показывает отпечаток ключа и предлагает пользователю принять его. Эта модель доверия при первом использовании сохраняет ключ в known_hosts и обнаруживает изменения при последующих подключениях, предупреждая о возможных атаках «человек посередине».

Самый безопасный способ проверить новый ключ узла сервера — использовать независимый канал связи. Администратор может получить отпечаток сервера лично или через проверенный защищённый канал, а затем сравнить его с отпечатком, который показывает клиент SSH. Это предотвращает незаметное принятие поддельного ключа при первом подключении.

Файл known_hosts хранит строки вида: hostname algorithm base64-key. Каждая запись представляет доверенную идентичность сервера. Когда Вы подключаетесь к узлу, уже указанному в known_hosts, SSH проверяет, совпадает ли предъявленный ключ с сохранённым, и отказывается от соединения при несоответствии.

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

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

Ключи RSA длиной 2048 или 4096 бит широко поддерживаются, но работают медленнее. Ключи ECDSA на кривых NIST работают быстрее, однако некоторые специалисты не доверяют параметрам кривых NIST. Ключи Ed25519 на основе Curve25519 рекомендуются как современный вариант: они небольшие, быстрые, обеспечивают высокий уровень безопасности и не зависят от параметров кривых NIST. Большинство современных серверов SSH предлагают Ed25519 по умолчанию.

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

Как клиент проверяет ключ узла сервера SSH при последующих подключениях после первого?

В этом уроке: TCP устанавливает соединение через порт 22, происходит обмен строками версий, согласование алгоритмов выбирает шифры и методы обмена ключами, ECDH или DH устанавливает общий секрет, ключи сеанса получают отдельно для каждого направления, сервер подтверждает свою подлинность подписью ключа узла, а клиент при первом подключении проверяет ключ по known_hosts с использованием TOFU.