Кратко

  • Подтверждённое DNSSEC совпадение SSHFP связывает алгоритм и отпечаток предъявленного ключа SSH с выбранным доменным именем. Оно не доказывает, что выбрана нужная служба, и ничего не говорит о порте, пользователе или команде.
  • Решение складывается из выбора имени, состояния DNSSEC, точного сравнения, доказательства владения закрытым ключом и политики клиента. При ротации добавляются независимые часы DNS-кэша и known_hosts.

Правильное доказательство для неверно выбранного имени

В исходном эпизоде никто не подделывал подписи. Резолвер получил полное имя, DNSSEC подтвердил набор SSHFP, а сервер подписал обмен соответствующим закрытым ключом. Не был проверен более ранний шаг: почему db разрешили превратить именно в это имя.

RFC 4255 отдельно предупреждает об использовании неполных имён. Подменённый поисковый путь может направить клиента к другому узлу, поэтому для таких имён стандарт предлагает сначала обращаться к локальной базе ключей. DNSSEC подтверждает подлинность ответа на заданный вопрос, но не подтверждает разумность самого вопроса.

В журнале доказательств необходимо раздельно хранить введённое имя, фактически запрошенное имя, поисковый суффикс или CNAME, владельца SSHFP, адрес и порт. Сведение этой цепочки к отметке «DNSSEC прошёл» уничтожает именно тот контекст, в котором возникает ошибка намерения.

Что содержится в SSHFP — и чего там нет

SSHFP имеет DNS-тип 44. Его RDATA содержит номер алгоритма ключа, тип отпечатка и сам отпечаток; имя владельца находится снаружи RDATA. Для принятия должны совпасть и алгоритм предъявленного ключа, и вычисленный по блоку открытого ключа дайджест.

Затем транспорт SSH требует подписи обмена и тем самым доказывает владение соответствующим закрытым ключом в этой сессии. Это не доказательство исключительного владения: украденная копия способна создать столь же корректную подпись.

В записи нет порта, учётной записи, команды, IP-адреса, роли или срока действия. Совпадение для имени не выбирает между двумя SSH-службами на разных портах, не отличает промежуточный узел от цели и не устанавливает среду исполнения.

Secure — состояние валидации, а не общая оценка доверия

RFC 4255 разрешает доверять SSHFP только тогда, когда использованная запись аутентифицирована доверенной подписью DNS. Если валидацию выполняет внешний резолвер, путь от клиента до него также должен быть защищён.

Состояния Secure, Insecure, Bogus и Indeterminate нельзя смешивать. Совпадающий отпечаток в Insecure не получает автоматического доверия. Bogus нельзя понижать до Insecure ради доступности. Даже Secure подтверждает набор записей под запрошенным владельцем, а не то, что клиент должен был принять суффикс DHCP или выбранный результат канонизации.

Несовпадение SHA-256 нельзя спасать совпадением SHA-1

В текущем реестре IANA для SSHFP перечислены RSA, DSA, ECDSA, Ed25519 и Ed448, а для отпечатков — SHA-1 и SHA-256. Наличие значения в реестре не означает, что конкретная реализация его поддерживает.

RFC 6594 задаёт важную отрицательную проверку: если клиент поддерживает SHA-256 и опубликованы оба типа дайджеста, SHA-256 имеет приоритет. Если проверенный SHA-256 не совпал, ключ требуется отвергнуть; совпадающий SHA-1 не может его оправдать. Поэтому телеметрия должна хранить имя владельца, алгоритм, тип дайджеста, вычисленное значение и каждый результат, а не один флаг sshfp=match.

Последнее решение принимает локальная политика

RFC 4255 допускает настраиваемый порядок проверки SSHFP и локальных баз. В OpenSSH значение VerifyHostKeyDNS по умолчанию равно no. При yes совпадение со статусом Secure получает неявное доверие, а незащищённое совпадение обрабатывается как ask. В режиме ask решение для нового ключа по-прежнему определяется StrictHostKeyChecking.

Системные и пользовательские файлы known_hosts, блоки Host и Match, канонизация и правила CNAME могут изменить реально выполненную ветвь. Для воспроизводимой проверки нужна итоговая конфигурация после применения всех этих источников.

OpenSSH умеет хранить в known_hosts форму [hostname]:port, тогда как ssh-keygen -r публикует SSHFP для имени узла, а сама запись порта не несёт. У переходного узла также есть собственное решение о ключе: аутентификация конечного сервера не распространяется назад на бастион.

Ротация идёт по нескольким часам

SSHFP может безопасно объявить новый ключ, а удаление старого отпечатка при обязательной политике может участвовать в отзыве. Но одновременно действуют TTL DNS, срок подписи RRSIG, кэши валидаторов и локальные закрепления. Удаление записи на авторитетном сервере не превращается в мгновенный отказ у всех клиентов.

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

Проверка узла не авторизует пользователя

Архитектура SSH отделяет аутентификацию сервера на транспортном уровне от последующей аутентификации пользователя. Принятый ключ защищает канал к выбранному серверу, но не разрешает учётную запись, оболочку, пересылку или команду.

Набор отрицательных тестов должен менять поисковый путь, состояние DNSSEC, значение SHA-256, локальный pin, порт, переходный узел, копию закрытого ключа и последующий отказ пользователю или команде. Каждый успешный тест обязан назвать владельца записи, состояние, ключ, порт, соединение, источник политики и последующее разрешение.