Наполнить known_hosts для нового сервера
-H хеширует имя хоста в файле — так же, как это делает сам ssh при
первом подключении (см. ssh-client).
ssh-keyscan — собрать ключи хостов
Заранее наполнить known_hosts ключами серверов — без интерактивного «yes» при первом ssh.
Шпаргалка
6 команд Версия для печати-
ssh-keyscan server.example.comпубличные ключи хоста (в stdout) -
ssh-keyscan -H server.example.com >> ~/.ssh/known_hostsдобавить, хешируя имя хоста -
ssh-keyscan -t ed25519 server.example.comтолько один тип ключа -
ssh-keyscan -p 2222 server.example.comнестандартный порт -
ssh-keyscan -f hosts.txtсписок хостов из файла -
ssh-keygen -lf <(ssh-keyscan server.example.com 2>/dev/null)отпечатки для сверки
Обзор
ssh-keyscan опрашивает один или несколько серверов и печатает их публичные
ключи хоста — то же самое, что ssh получает при первом подключении и
спрашивает: «The authenticity of host … can't be established, continue
connecting?». ssh-keyscan делает это без интерактивного диалога и без
проверки: он не может подтвердить, что ключ настоящий (см. «Опасно»), —
только собирает его для последующей сверки или наполнения known_hosts.
Типичное применение — автоматизация: подготовить known_hosts заранее (для
CI, cloud-init, свежих ВМ в лабе), чтобы первый ssh/scp/rsync не
упирался в вопрос про новый хост в неинтерактивном скрипте.
Ключи
5Ниже — основные ключи; полный список — в man ssh-keyscan.
| Ключ | Что делает | Пример |
|---|---|---|
-H |
Захешировать имена хостов в выводе — как их хранит known_hosts по умолчанию. | ssh-keyscan -H server.example.com >> ~/.ssh/known_hosts |
-t TYPE |
Опросить только указанный тип ключа (ed25519, rsa, ecdsa). | ssh-keyscan -t ed25519 server.example.com |
-p PORT |
Порт SSH, если сервер слушает не 22. | ssh-keyscan -p 2222 server.example.com |
-f FILE |
Взять список хостов из файла (по одному на строку) вместо аргументов. | ssh-keyscan -f hosts.txt |
-4 |
Опрашивать только по IPv4. | ssh-keyscan -4 server.example.com |
Ничего не найдено. Попробуй запрос короче.
Рецепты
3Несколько хостов из списка
Удобно перед разворачиванием группы ВМ или в cloud-init/Ansible-плейбуке,
когда known_hosts собирают одним шагом для всего парка.
Сверить полученный ключ с отпечатком
Неполадки
3ssh всё равно спрашивает про new host key
Хешированное имя в known_hosts (-H) не совпадёт, если подключаешься по
другому имени/алиасу или порту, — known_hosts привязан к конкретной паре
хост:порт. Добавь ключ и под тем именем, которым реально подключаешься.
После переустановки сервера ssh ругается на «REMOTE HOST IDENTIFICATION HAS CHANGED»
Это ожидаемо: у сервера новый ключ хоста. Убери старую строку
(ssh-keygen -R server.example.com) и добавь новую заново через
ssh-keyscan — только после проверки, что сервер действительно
переустановлен, а не подменён (см. «Опасно»).
Пустой вывод / таймаут
Хост недоступен по SSH-порту (упал, фаервол, не тот порт — проверь -p) или
DNS не резолвит имя. Проверь ssh -v к тому же хосту для диагностики.
Опасно
1ssh-keyscan НЕ проверяет подлинность ключа
Команда просто спрашивает сервер «покажи ключ» — без проверки, тот ли это
сервер, за который себя выдаёт. Слепое добавление ssh-keyscan ... >>
known_hosts в скрипте отключает главную защиту SSH от MITM (подмены
сервера): дальше ssh доверяет ЛЮБОМУ ключу, который был собран, даже
подложному. Безопасно — только когда канал до сервера доверенный (тот же
датацентр, приватная сеть) или отпечаток сверен отдельно (телефон, консоль
провайдера, cloud-init-вывод при создании ВМ).
См. также
- ssh-client — Подключение по SSH и копирование файлов — ssh, scp, конфиг клиента.
- ssh-keys — Ключи SSH — генерация, агент, добавление на сервер.
- sshd — SSH-сервер — конфигурация, ограничение доступа, диагностика.
Есть неточность? Сообщить об ошибке в статье