Conchshell
RUEN
Загрузить

Отпечатки SSH-ключей — как их печатает ssh-keygen

Вставьте файл .pub, authorized_keys или known_hosts — или откройте его. Для каждого ключа — тип, длина, комментарий и оба отпечатка: SHA256 в base64, как сегодня печатает ssh-keygen -lf, и MD5 в шестнадцатеричном виде, как его до сих пор показывают старые программы и некоторые панели хостинга.

known_hosts с хэшированными именами (|1|…) тоже читается. Имена из такого файла не восстановить, но можно спросить, есть ли запись для названного вами хоста, — той же проверкой HMAC-SHA1, что делает сам ssh.

Вставьте или откройте файл

Ничего не загружается: в скрипте страницы нет ни fetch, ни XMLHttpRequest, ни отправки формы. SHA-256 и HMAC-SHA1 считает WebCrypto самого браузера, MD5 — скрипт страницы, счётчиков на странице нет.

Есть ли этот хост в файле?

Вставьте known_hosts выше и назовите хост. Проверка строит имя так же, как ssh, — строчными буквами и в виде [имя]:порт для любого порта, кроме 22, — и сверяет каждую строку: хэшированные — через HMAC-SHA1 с солью из строки, обычные — по имени и по шаблону. Это тот же вопрос, на который отвечает ssh-keygen -F host.

Как сверять отпечаток правильно

Отпечаток что-то доказывает, только если он пришёл к вам по каналу, которому вы уже доверяете. Прочитайте ключ сервера там, где это может только его владелец, — в веб-консоли хостинга или в сеансе, проверенном раньше, — командой ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub и сравните с тем, что клиент показывает при первом подключении. Отпечаток, полученный через то же соединение, которое вы проверяете, не доказывает ничего: тот, кто способен его перехватить, покажет вам любой ожидаемый отпечаток.

Две разные строки для одного ключа — не противоречие. До версии 6.8 (март 2015 года) OpenSSH печатал MD5 в шестнадцатеричном виде, с тех пор — SHA256 в base64; ssh-keygen -E md5 -lf по-прежнему даёт старый вид, а некоторые панели и старые клиенты показывают только его. Оба — хэши одних и тех же байт, поэтому страница показывает оба.

Как устроен хэшированный known_hosts

С HashKnownHosts yes — Debian и Ubuntu ставят его в /etc/ssh/ssh_config — ssh пишет вместо имени хоста |1|соль|хэш: случайную соль в 20 байт и HMAC-SHA1 от имени с этой солью в качестве ключа, оба в base64. Прочитав файл, никто не узнает, куда вы подключаетесь. Вы тоже не узнаете — для этого и нужна проверка выше.

Порт — часть имени. Сервер на порту 2222 записан как [git.example.org]:2222, и запись для голого имени его не покрывает, а запись вида [10.0.0.5]:22 не сработает никогда: порт 22 ssh ищет без скобок. ssh-keygen -H хэширует готовый файл и оставляет оригинал как known_hosts.old; строки с шаблонами и метками остаются как были.

Почему в блоке ssh-keygen не все ключи

Список показывает каждый ключ, который страница смогла прочитать, а блок в точности повторяет ssh-keygen -lf — и ssh-keygen пропускает некоторые строки, которые сам ssh использует: строку known_hosts, начинающуюся с @cert-authority или @revoked, строку с двумя пробелами между именами хостов или опциями и типом ключа, ключи DSA (в OpenSSH 10.0 DSA удалён) и блоки SSH2 в формате RFC 4716, которым сначала нужен ssh-keygen -i. Каждый такой ключ помечен в списке с причиной.

У комментария тоже есть странность, которую стоит знать. Если у ключа своего комментария нет, ssh-keygen печатает то, что стояло в строке перед ключом, — имена хостов из known_hosts или опции из authorized_keys. Так ведёт себя ssh-keygen, и блок повторяет это поведение.

Как это проверено

По ssh-keygen из OpenSSH 10.2p1, 24 сентября 2026 года: 50 файлов ключей — RSA от 1024 до 4096 бит, ECDSA на всех трёх кривых, Ed25519, ключи на аппаратных токенах (FIDO), сертификаты пользователя и хоста, — плюс authorized_keys с опциями и странностями и known_hosts на 68 строк, обычный и хэшированный. Блок SHA256, блок MD5 и рисунки сверены с ssh-keygen -lf, -E md5 -lf и -lv, каждый поиск хоста — с ssh-keygen -F. Совпало всё.

Вопросы, которые задают на самом деле

Мой ключ куда-нибудь отправляется?

Нет. Файл читается в этой вкладке: в скрипте страницы нет ни fetch, ни XMLHttpRequest, ни отправки формы, счётчиков на странице нет. SHA-256 и HMAC-SHA1 считает WebCrypto самого браузера; MD5, которого в WebCrypto нет, считает скрипт страницы. Откройте вкладку «Сеть» и вставьте файл — наружу ничего не уйдёт.

Чем отпечаток SHA256 отличается от MD5?

Только хэшем и записью. Оба считаются по одним и тем же байтам ключа. OpenSSH перешёл с MD5 в шестнадцатеричном виде на SHA256 в base64 в версии 6.8, в марте 2015 года; ssh-keygen -E md5 -lf по-прежнему печатает старый вид для панелей и старых клиентов, которые показывают только его.

Как узнать отпечаток ключа своего сервера?

На самом сервере или через консоль хостинга: ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub, и так же для файлов rsa и ecdsa, если они есть. Снаружи ssh-keyscan host | ssh-keygen -lf - покажет, что предъявляет сервер, — но это приходит по той самой сети, которую вы проверяете, и само по себе ничего не доказывает.

Можно ли восстановить имена хостов из хэшированного known_hosts?

По одному файлу — нет. Каждое имя — это HMAC-SHA1 со своей случайной солью, обращать там нечего; остаётся только угадать имя и проверить его, что и делают проверка на этой странице и ssh-keygen -F. Значит, и короткий список вероятных имён проверяется за мгновения: хэширование прячет имена, но не делает их неугадываемыми.

Есть ли у SSH-сертификата свой отпечаток?

ssh-keygen печатает отпечаток ключа внутри сертификата, поэтому у сертификата и ключа, на который он выпущен, отпечаток один и тот же. Эта страница делает так же и вдобавок показывает ID ключа, серийный номер, принципалов, срок действия и отпечаток удостоверяющего центра, который его подписал.

Что будет, если по ошибке вставить приватный ключ?

Он не обрабатывается. Текст проверяется на признаки приватного ключа до всякого разбора: поле сразу очищается и появляется предупреждение. При уходе со страницы поле и результаты тоже очищаются.

Откуда это взялось

Conchshell показывает ключ нового сервера так же: отпечатком SHA256, той самой строкой, что печатает ssh-keygen -lf, в окне, которое рисует операционная система, а не приложение. При первой установке, пока его собственного хранилища доверия ещё нет, он один раз читает ваш ~/.ssh/known_hosts и закрепляет что может, — серверы, которые ваш ssh уже проверил, больше не спрашивают. Хэшированные записи закрепить нельзя — имён в файле нет, — поэтому по этим хостам окно первого подключения появится один раз. В Windows и Linux отвечайте в этом окне кнопкой: в версии 2.16.0 закрытие окна считается согласием.

Что честно знать до решения: он входит по паролю, через keyboard-interactive или по файлу приватного ключа — с парольной фразой и без, включая .ppk из PuTTY. С ssh-agent он не работает и ключи на аппаратных токенах (sk-) использовать не умеет.

Скачать Conchshell бесплатно

Что почитать дальше