OpenSSH против SSH

Формально протокол SSH определён в ряде стандартов RFC (список ниже ^[3]). В то же время есть много реализаций этого протокола. OpenSSH — самая популярная из них, хотя не единственная ^[4]. Например, вот альтернативная реализация SSH на Go ^[5] (и несколько ^[6] примеров ^[7] кастомных ^[8] серверов ^[9] на её основе). По статистике Shodan ^[2], вторым по популярности демоном SSH является Dropbear SSH ^[10] (рис. 1). Все остальные далеко позади, если судить по количеству адресов на порту 22.

На практике спецификации OpenSSH ^[11] содержат в себе все стандарты RFC для SSH, включая черновики, а также немножко сверх этого.

▍ Разные реализации SSH

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

По мнению некоторых экспертов ^[12], «OpenSSH как реализация представляет собой монолит, ориентированный на конкретный случай использования — общий доступ к одной компьютерной системе. Если у вас другой вариант использования (как у Github, например), то другие реализации могут показаться удобнее, чем попытки (безопасно) подстроить OpenSSH под свои нужды. Так что эти реализации всё равно имеют значение, даже если разработчики OpenSSH — единственные, кто действительно развивает протокол».

▍ Протокол vs. реализация

Такое противостояние «протокол — реализация» довольно часто встречается в компьютерной индустрии. Долгое время BIND ^[13] считался чуть ли не синонимом DNS, вплоть до того, что в официальных документах RFC цитируются спецификации из BIND или других реализаций протокола. Например, RFC 1035 ^[14] описывает синтаксис зональных файлов, который позаимствован из BIND или JEEVES:

The following is an example file which might be used to define the
ISI.EDU zone and is loaded with an origin of ISI.EDU:

@ IN SOA VENERA Action.domains (
20 ; SERIAL
7200 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM

NS A.ISI.EDU.
NS VENERA
NS VAXA
MX 10 VENERA
MX 20 VAXA

A A 26.3.0.103

VENERA A 10.1.0.52
A 128.9.0.32

VAXA A 10.2.0.27
A 128.9.0.33

То есть сначала какой-то софт реализует этот синтаксис, а потом комитет по стандартизации его принимает как всеобщий стандарт.

Некоторые считают, что зональные файлы должны оставаться деталями реализации, а не быть описаны в стандарте. Например, такого мнения придерживался Даниэль Бернштейн ^[15] (Daniel Bernstein), автор альтернативной реализации djbdns ^[16], за что его в итоге исключили из списка рассылки IETF DNS ^[17] и из соответствующего комитета IETF по стандартизации.

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

▍ Сертификаты OpenSSH

Аналогично тому, что OpenSSH — лишь отдельная реализация стандарта, также и сертификаты OpenSSH (и сертификаты SSH) не являются традиционными сертификатами TLS X.509 ^[18].

OpenSSH изначально развивался перпендикулярно системе SSL/TLS, не поддерживая стандартную систему PKI с центрами сертификации и их цепочкой доверия. Здесь собственные ключи, сертификаты и т. д. В каком-то смысле SSH-сертификаты можно сравнить с самоподписанными сертификатами HTTPS.

С другой стороны, поверх OpenSSH всё-таки реализуется поддержка сертификатов и центров сертификации ^[19], а также поддержка FIDO2 (в OpenSSH 8.2+), TOTP ^[20], LDAP, Kerberos с PAM и других систем аутентификации.

▍ Приложение. Протоколы SSH

Протоколы SSH-2 описаны в пяти основных документах:

1. Соединение (RFC 4254) ^[21]. Описывает расширенную поддержку приложений по транспортному каналу, в том числе мультиплексирование каналов, управление потоком, удалённое выполнение программ, распространение сигналов, переадресацию соединений и т. д.
2. Архитектура SSH (RFC 4251) ^[22]. Общее устройство протокола.
3. Транспорт (RFC 4253) ^[23]. Единое полнодуплексное байт-ориентированное соединение между клиентом и сервером с обеспечением конфиденциальности, целостности, аутентификации сервера и защиты от MiTM.
4. Аутентификация (RFC 4252) ^[24]. Идентифицирует клиента перед сервером.
5. Назначенные номера (RFC 4250) ^[25]. Здесь собраны и перечислены различные постоянные назначения, упомянутые в других документах.

Дополнительно к основным протоколам SSH принято несколько расширений и стандартов ^[26], которые играют роль вспомогательных механизмов для SSH:

• Использование DNS для безопасной публикации отпечатков ключей SSH (RFC 4255) ^[27]. Метод хранения отпечатков хост-ключей SSH в DNS. Он реализуется с помощью опции VerifyHostKeyDNS клиента OpenSSH. Стандарт расширен в RFC 6594 ^[28], где описаны хост-ключи на эллиптических кривых и SHA-2.
• Общая аутентификация обмена сообщениями для SSH (RFC 4256) ^[29]. Метод keyboard-interactive для аутентификации пользователя в «интерактивном режиме», то есть с клавиатуры. В рамках сессии допускает любое количество запросов сервера и ответов клиента. Позволяет использовать схемы «вызов-ответ», такие как одноразовые пароли, и часто реализуется в Unix с помощью PAM ^[30].
• Режимы шифрования на транспортном уровне (RFC 4344) ^[31]. В этом документе описаны новые методы симметричного шифрования для транспорта SSH и даны конкретные рекомендации по частоте повторного использования ключей в реализациях SSH в ответ на некоторые уязвимости протокола ^[32].
• Групповой обмен ключами Диффи — Хеллмана (RFC 4419) ^[33]. Базовые методы согласования ключей в транспортном протоколе на основе фиксированных, хорошо известных групп для алгоритма Диффи — Хеллмана. Этот метод позволяет серверу использовать набор локально сконфигурированных групп, а клиенту — запрашивать предпочтительный размер группы.
• Обмен ключами RSA для протокола транспортного уровня Secure Shell (SSH) (RFC 4432) ^[34]. Метод обмена ключами для SSH, основанный на шифровании с открытым ключом RSA. Он использует гораздо меньше процессорного времени клиента, чем, входящий в состав основного протокола, и поэтому особенно подходит для медленных клиентских систем.
• Аутентификация и обмен ключами GSSAPI для SSH (RFC 4462) ^[35]. Описывает методы использования GSS-API для аутентификации и обмена ключами в SSH. Он определяет метод аутентификации пользователя SSH, который использует указанный механизм GSS-API для аутентификации пользователя, и семейство методов обмена ключами SSH, которые используют GSS-API для аутентификации при обмене ключами Диффи — Хеллмана. При этом обычно используется Kerberos для обеспечения односигнальной, а также автоматической аутентификации сервера без хост-ключей.
• Формат файла открытого ключа SSH (RFC 4716) ^[36]. Документирует формат файла открытого ключа, используемый несколькими реализациями SSH.
• Интеграция алгоритма на эллиптических кривых в транспортный уровень SSH (RFC 5656) ^[37]. Алгоритмы, основанные на криптографии эллиптических кривых (ECC), для использования в транспортном протоколе SSH. В частности, в нём определены алгоритмы согласования ключей Диффи — Хеллмана на эллиптических кривых (ECDH), согласования ключей Менезеса — Ку — Ванстоуна на эллиптических кривых (ECMQV) и алгоритм цифровой подписи на эллиптических кривых (ECDSA) для использования в протоколе транспортного уровня SSH.
• Криптографические наборы Suite B для SSH (RFC 6239) ^[38]. Расширения SSH для обеспечения криптографии, соответствующей рекомендациям АНБ, известным как Suite B ^[39].
• Использование алгоритма SHA-256 с RSA, алгоритмом цифровой подписи DSA и алгоритмом DSA на эллиптических кривых (ECDSA) в записях ресурсов SSHFP (RFC 6594) ^[28]. Обновление RFC 4255 ^[27], определяющего метод хранения отпечатков хост-ключей SSH в DNS. В этом документе добавлена поддержка хост-ключей на эллиптических кривых (ECDSA), а также хэш-алгоритма SHA-2.
• Проверка целостности данных SHA-2 для протокола транспортного уровня SSH (RFC 6668) ^[40]. В этом меморандуме определены имена алгоритмов и параметры для использования некоторых из семейства безопасных хэш-алгоритмов SHA-2 для проверки целостности данных в протоколе SSH. В нём также обновлён RFC 4253 и указан новый рекомендуемый алгоритм проверки целостности данных.

Ещё несколько технологий пока находятся на стадии рассмотрения (черновики и предложения):

• Протокол передачи файлов SSH ^[41]. Протокол Secure Shell File Transfer Protocol (SSH FTP) обеспечивает безопасную передачу файлов по любому надёжному каналу. Это будет стандартный способ передачи файлов для использования с протоколом удалённого входа SSH. В данном документе описывается сам протокол и его интерфейс к набору остальных протоколов SSH.
• Аутентификация X.509 в SSH2 ^[42]. Определяет, как сертификаты, ключи и подписи X.509 используются в протоколе SSH2.
• Канал открытого ключа SSH ^[43]. Протокол для работы внутри канала SSH-TRANS для конфигурирования данных авторизации с открытым ключом для удалённой учётной записи. Он решает проблему множества специфических для конкретной реализации способов выполнения этой задачи (например, файлы authorized_keys, authorization, authorized_keys2, различные форматы хранения ключей и т. д.).

▍ Это может быть неправильно, но такова жизнь

Если одна конкретная реализация протокола становится настолько популярной, что фактически выполняет роль стандарта, то альтернативными реализациями уже никто не хочет пользоваться. По мнению Даниэля Бернштейна и некоторых представителей сообщества разработчиков протокола DNS, это неправильно. Другие же считают, что Даниэль сам вёл себя контрпродуктивно ^[44], а свою реализацию DNS написал в знак протеста и из чувства справедливости. Хотя это не умаляет его заслуги как выдающегося математика и криптографа, автора нескольких шифров и алгоритмов ^[45], в том числе Ed25519, Poly1305, Salsa20 и ChaCha20, которые в том или ином виде реализованы в ядре Linux, iOS, OpenSSH, Tor и других приложениях.

В целом, ситуация с SSH/OpenSSH как стандарта/реализации чем-то напоминает ту историю с BIND/DNS. Есть одна популярная реализация (программа), разработчики которой ведут за собой всех остальных и занимают ключевые позиции в комитете по стандартизации IETF, хотя он формально должен быть независимым органом. Но что делать… Возможно, в существующих условиях это наиболее продуктивная модель разработки SSH как открытого стандарта, такова жизнь.