Кратко

  • RFC 9644 унифицирует YANG-представление возможностей и упорядоченной политики алгоритмов SSH, но не создаёт журнал результата каждого сеанса.
  • Надёжное утверждение связывает версию реестра и модели, возможности реализации, утверждённую конфигурацию, оба предложения SSH_MSG_KEXINIT, выбор по направлениям, ключ хоста, NEWKEYS, аутентификацию и результат приложения.
  • Предлагаемая квитанция — эксплуатационный контроль, а не требование RFC; отсутствие наблюдения должно сужать вывод.

Два зелёных индикатора и один неизвестный факт

Система управления способна показать, что устройство приняло упорядоченный список. Инвентаризация способна показать заявленную поддержку алгоритма. Журнал согласования способен назвать автора решения. Эти документы полезны, но ни один из них не содержит предложения удалённой стороны и результата живых переговоров.

RFC 9644 определяет переиспользуемые группировки ietf-ssh-common, ietf-ssh-client и ietf-ssh-server, а также генерацию четырёх модулей перечислений на основе реестров SSH, которые ведёт IANA. Благодаря этому контроллеры и реализации могут использовать согласованный словарь.

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

Регистрация имени не утверждает риск

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

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

Revision или хэш модуля нельзя заменять сегодняшним перечнем имён. Иначе аудит переносит современную семантику в прошлое. Features и deviations, меняющие доступную схему, также относятся к первой части цепочки.

Поддержка описывает пространство возможностей

Опциональная feature algorithm-discovery предоставляет supported-algorithms как операционные данные config false. Это хороший материал для планирования миграции: видно, какие методы обмена ключами, host key, шифрования и MAC реализация заявляет.

Но поддержка не означает разрешение и не означает использование. Поддерживаемый алгоритм может быть запрещён. Разрешённый может отсутствовать у peer. Общий вариант может проиграть более приоритетному. Наблюдение нужно связывать с временем, версией программного обеспечения и конкретной сборкой.

Пустой или отсутствующий список конфигурации тоже не даёт универсального ответа. RFC 9644 оставляет допустимое множество на усмотрение реализации. Если эффективное поведение продукта не установлено, честное значение — «не определено», а не выдуманный безопасный default.

Политика становится выбором только при встрече с peer

В transport-params-grouping списки key exchange, host key, шифрования и MAC упорядочены по убыванию предпочтения. Доказательство должно сохранять исходный порядок, revision конфигурации, согласовавшего и целевое устройство.

По RFC 4253 обе стороны отправляют списки в SSH_MSG_KEXINIT. Для key exchange и host key выбирается первый вариант по предпочтению клиента, который также предложен сервером и отвечает требованиям метода. Шифрование и MAC выбираются независимо для направлений клиент-сервер и сервер-клиент.

Единое поле «cipher соответствует политике» стирает часть результата. Нужны оба предложения и оба направления. При отсутствии допустимого пересечения соединение прекращается. Успешное применение конфигурации никогда не обещало совместимость с любым удалённым узлом.

Алгоритм, ключ и идентичность

Выбранный алгоритм host key описывает процедуру, но не сам предъявленный ключ и не основание доверия к нему. RFC 8332 показывает различие: один формат открытого RSA-ключа может использоваться с rsa-sha2-256 или rsa-sha2-512. Наличие RSA-ключа не восстанавливает алгоритм подписи.

RFC 9644 отдельно моделирует идентичность клиента и параметры аутентификации сервера, включая ссылки на keystore и truststore. Следовательно, отдельно фиксируются выбранная процедура, fingerprint предъявленного ключа, правило и результат проверки, способ аутентификации клиента и прикладное разрешение.

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

Граница NEWKEYS и то, что находится за ней

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

Эксплуатационная квитанция может связывать:

  • снимок IANA и revision либо хэш сгенерированных YANG-модулей;
  • реализацию, версию ПО, features и deviations;
  • датированное наблюдение поддерживаемых алгоритмов;
  • точные упорядоченные списки, revision конфигурации и согласовавшего;
  • защищённые копии или хэши обоих KEXINIT;
  • выбранные KEX, host key, шифрование и MAC с сохранением направления;
  • fingerprint ключа хоста, основание и результат проверки;
  • подтверждение завершения NEWKEYS;
  • метод и результат аутентификации без раскрытия секретов;
  • прикладную операцию, критерий приёмки и результат;
  • отсутствующие наблюдения и ответственного за формулировку вывода.

Цитируемые RFC не предписывают такой единый формат. Это проект эксплуатационного контроля на границах конфигурации, протокола и сервиса.

Минимальное утверждение, которое можно защитить

Принцип minimum initial specification Хэнга Лу предлагает начать не с максимального сбора данных, а с фразы, которую организация обязуется доказать. «SSH безопасен» слишком широко. Проверяемая формулировка звучит иначе: для указанной операции и временного окна наблюдаемый выбор связан с утверждённой политикой, проверенным peer и ожидаемым результатом.

Running-code primacy задаёт порядок при противоречии. Реестр и YANG создают символическую структуру; выполненный обмен ограничивает рассказ о событии. Если намерение расходится с наблюдением, сеанс описывается наблюдением, а расхождение становится инцидентом контроля.

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

Источники

  1. Minimum initial specification
  2. Reality layers and symbolic power
  3. Running-code primacy
  4. RFC 9644 в Datatracker
  5. Информационная страница RFC 9644
  6. RFC 9644 в HTML
  7. RFC 9644 в текстовом формате
  8. RFC 9644 в XML
  9. Встроенные errata RFC 9644
  10. Параметры протокола SSH в IANA
  11. Параметры YANG в IANA
  12. RFC 4250: назначенные номера SSH
  13. RFC 4252: протокол аутентификации SSH
  14. RFC 4253: транспортный уровень SSH
  15. RFC 6187: сертификаты X.509v3 для SSH
  16. RFC 8332: RSA-ключи и подписи SHA-2
  17. RFC 9142: обновление методов обмена ключами SSH
  18. RFC 7950: YANG 1.1
  19. RFC 8341: контроль доступа к конфигурации
  20. RFC 8342: архитектура management datastore