OpenSSH против SSH

в 9:00, , рубрики: BIND, djbdns, DNS, Dropbear, ECC, ECDH, ecdsa, ECMQV, GSS-API, IT-стандарты, open source, openssh, rsa, ruvds_статьи, secure shell, ssh, SSH FTP, ssh-2, Suite B, алгоритм Диффи-Хеллмана, Блог компании RUVDS.com, Даниэль Бернштейн, информационная безопасность, протоколы, эллиптические кривые
OpenSSH против SSH - 1
Рис. 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 и постами о ретроиграх 🕹️

Автор:
ru_vds

Источник

* - обязательные к заполнению поля

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js