Рис. 1. Разные реализации SSH, источник: Shodan

Формально протокол SSH определён в ряде стандартов RFC (список ниже). В то же время есть много реализаций этого протокола. OpenSSH — самая популярная из них, хотя не единственная. Например, вот альтернативная реализация SSH на Goнесколько примеров кастомных серверов на её основе). По статистике Shodan, вторым по популярности демоном SSH является Dropbear SSH (рис. 1). Все остальные далеко позади, если судить по количеству адресов на порту 22.

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

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


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

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

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


Такое противостояние «протокол — реализация» довольно часто встречается в компьютерной индустрии. Долгое время BIND считался чуть ли не синонимом DNS, вплоть до того, что в официальных документах RFC цитируются спецификации из BIND или других реализаций протокола. Например, RFC 1035 описывает синтаксис зональных файлов, который позаимствован из 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

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

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

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

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


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

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

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

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


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

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

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


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

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

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


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

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

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ????️

Комментарии (7)


  1. veryboringman
    02.08.2023 11:42
    +3

    Решил вспомнить, какие ssh клиенты использовал под windows:

    1. MobaXterm

    2. SecureCRT

    3. ZOC

    4. PuTTY

    5. WindTerm


    1. dunkelfalke
      02.08.2023 11:42

      и какой из них больше нравится?


      1. veryboringman
        02.08.2023 11:42
        +1

        В итоге - openssh под WSL.

        Просто для однообразия и быстрого переноса конфигов.


  1. kekoz
    02.08.2023 11:42
    +5

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

    Справедливости ради, djb попёрли из IETF не “за альтернативное мнение”, а за позицию “все козлы, RFC ваши — говно, а я д'Артаньян и знаю, как лучше.” Его заслугами интернет наполнился игнорантами “У меня qmail, и у меня всё работает, а раз почта не ходит, то это проблемы у вас, ставьте qmail”, хотя всему миру было очевидно — проблема именно в том, что djb в qmail решил всем показать “как надо”, откровенно верча ряд RFC на своём “конце”, и посылая всех нафиг. Но qmail мог “настроить” (там настраивать нечего было практически) любой пятиклассник, и стараниями множества юных админов, неспособных и/или нежелающих разбираться в exim или — ужас-ужас — sendmail (а postfix ещё не родился), интернет наполнился кучей почтовых проблем по всему миру.


    1. bear11
      02.08.2023 11:42
      +3

      Ну у него было обоснованно право считать себя дартаньяном. Так как количество уязвимостей в qmail было ничтожно по сравнению с sendmail который просто был решето.

      Вот новость тех времен: https://www.networkworld.com/article/2341093/sendmail-flaw-puts-systems-at-risk--again.html

      djb стандарты безопасного кодинга:

      • подели систему на простые процессы

      • процессы НЕ должны доверять данным своего входа

      были на порядок выше того что обычно делалось в то время


      1. Stanislavvv
        02.08.2023 11:42

        Безопасность безопасностью, но и класть на стандарты не стоило даже если они автору не нравятся. Помнится, qmail отлично принимал ВСЕ письма, доставляя далеко не каждое, вместо того, чтобы отпинывать отсутствующих юзеров и ломая тем самым некоторые настройки sender verify.


  1. speshuric
    02.08.2023 11:42

    Почти у всех (нужных) стандартов есть один или несколько периодов, когда стандарт очень сильно зависит от его основной реализации. Почти всегда в этом есть или появляется со временем некоторый конфликт - этот конфликт как минимум свидетельство, что стандарт ценен, что он не является просто спецификацией реализации.