--- title: 'known_hosts и host key в SSH | Zomro' description: '' image: 'https://cdn.zomro.com/uploads/blog/a48%40server-panel.net/2025/12/29/chatgpt-image-29-2025-22_54_04_q50.jpg' --- ![opened image]() * [Zomro](https://zomro.com/rus/) * [FAQ](https://zomro.com/rus/blog/faq/) * known_hosts и host key в SSH # known_hosts и host key в SSH 23-12-2025 ## ![](https://cdn.zomro.com/uploads/blog/a48%40server-panel.net/2025/12/29/chatgpt-image-29-2025-22_54_04_q50.jpg) ## ## ## Зачем вообще существует known_hosts Когда вы подключаетесь к серверу по SSH, клиент должен убедиться, что перед ним действительно тот самый сервер, а не подмена на маршруте. Для этого SSH хранит публичные ключи серверов в файле known_hosts и сравнивает их при каждом подключении. Если ключ совпадает, соединение считается доверенным и подключение проходит без вопросов. Если ключ новый, SSH задает вопрос подтверждения. Если ключ изменился, SSH предупреждает о возможной атаке или о том, что сервер переустановили. ## ## ## Где лежит known_hosts и чем отличается системный файл от пользовательского Обычно SSH использует два уровня хранения. Пользовательский файл: * ~/.ssh/known_hosts Системный файл (общий для всех пользователей): * /etc/ssh/ssh_known_hosts На практике новичкам проще начинать с ~/.ssh/known_hosts, а системный файл использовать, когда вы администрируете парк серверов и хотите централизованное доверие для всех пользователей. ## Как выглядит первое подключение и что происходит после подтверждения При первом подключении к неизвестному серверу вы увидите сообщение вроде: ssh root@server.example.com SSH покажет отпечаток ключа (fingerprint) и спросит, доверяете ли вы этому серверу. Если вы отвечаете yes, ключ сохраняется в known_hosts и дальше вопрос повторяться не будет. Скриншот из консоли: первое подключение по ssh с вопросом о доверии и отображением fingerprint. > подтверждайте ключ только после проверки отпечатка. В идеале отпечаток должен быть известен заранее из панели управления, тикета или внутренних записей. ## ## ## Почему не стоит отключать проверку ключа ради удобства Иногда в интернете советуют использовать StrictHostKeyChecking=no, чтобы SSH не задавал вопросов. Технически это работает, но это также означает, что вы можете незаметно подключиться к подмененному серверу. Если вам нужно автоматизировать подключение, безопаснее заранее положить ключ сервера в known_hosts, а не отключать проверку. Если вы все же делаете автоматизацию, рассмотрите вариант accept-new, который принимает только новые ключи и не игнорирует смену ключа. ## ## ## Как заранее добавить публичный ключ сервера в known_hosts через ssh-keyscan Самый практичный метод - получить публичные host keys сервера командой ssh-keyscan и записать их в known_hosts. Пример для стандартного порта 22: ssh-keyscan server.example.com >> ~/.ssh/known_hosts Если SSH на нестандартном порту, добавьте -p: ssh-keyscan -p 2222 server.example.com >> ~/.ssh/known_hosts Скриншот из консоли: вывод ssh-keyscan и затем хвост файла ~/.ssh/known_hosts через tail -n 3. Важный момент: ssh-keyscan получает ключ по сети без проверки, поэтому правильный процесс такой: * получить ключ * сравнить отпечаток с доверенным источником * только после этого фиксировать его как доверенный Чтобы посмотреть отпечаток добавленного ключа: ssh-keygen -lf ~/.ssh/known_hosts | grep server.example.com ## ## ## Как добавлять ключи с хешированием имен хостов Иногда в настройках включено HashKnownHosts. Тогда в known_hosts имена серверов будут храниться в хешированном виде. Это повышает приватность, если файл known_hosts попадет в чужие руки. Проверить значение можно в /etc/ssh/ssh_config или ~/.ssh/config, если у вас есть пользовательские настройки. Если нужно добавить запись сразу с хешированием, используйте -H: ssh-keyscan -H server.example.com >> ~/.ssh/known_hosts Если у вас уже есть записи и вы хотите захешировать существующий known_hosts: ssh-keygen -Hf ~/.ssh/known_hosts Скриншот из консоли: выполнение ssh-keygen -Hf ~/.ssh/known_hosts с сообщением о создании файла .old. > Практический совет Zomro: после хеширования храните .old осторожно, там будут незахешированные записи. Если приватность важна, удалите файл .old после проверки. ## ## ## Как найти запись о сервере в known_hosts и быстро убедиться, что она там есть Когда known_hosts разрастается, удобнее искать запись командой ssh-keygen. Поиск по хосту: ssh-keygen -F server.example.com -f ~/.ssh/known_hosts Если используется нестандартный порт, формат записи будет в виде [host]:port. Тогда ищите так: ssh-keygen -F "[server.example.com]:2222" -f ~/.ssh/known_hosts Скриншот из консоли: вывод ssh-keygen -F, где видно найденную строку и тип ключа. ## ## ## Что делать, если SSH ругается на смену ключа Если вы видите предупреждение о том, что идентификация хоста изменилась, это не повод паниковать, но это повод остановиться и проверить причину. Самые частые причины: * сервер переустановили * поменяли OpenSSH и пересоздались host keys * вы подключаетесь к другому серверу под тем же именем или IP * есть риск атаки man-in-the-middle Если вы уверены, что причина легитимная, удалите старую запись и добавьте новую. Удаление записи по хосту: ssh-keygen -R server.example.com Для хоста с портом: ssh-keygen -R "[server.example.com]:2222" Дальше заново добавьте ключ через ssh-keyscan, как показано выше. ## ## ## Минимальный безопасный сценарий для автоматизации в скриптах Если вы пишете скрипт и вам нужно подключаться без интерактива, используйте такой подход: * заранее добавить host key в known_hosts * включить строгую проверку Пример подключения: ssh -o StrictHostKeyChecking=yes -o UserKnownHostsFile=~/.ssh/known_hosts root@server.example.com "uptime" Если у вас отдельный файл known_hosts под конкретный проект: ssh -o StrictHostKeyChecking=yes -o UserKnownHostsFile=/opt/zomro/known_hosts root@server.example.com "uptime" Скриншот из консоли: выполнение ssh команды с uptime и отсутствие вопросов про доверие. ## ## Итог known_hosts - это простая, но критически важная часть безопасности SSH. Для стабильной работы и автоматизации не нужно отключать проверки. Правильнее один раз собрать и проверить host keys, положить их в known_hosts и дальше подключаться без сюрпризов. Похожие статьи [Как установить и настроить веб-сервер IIS на Windows Server](https://zomro.com/rus/blog/faq/349-kak-ustanovit-i-nastroit-vebserver-iis-php-i-mysql-na-windows-server) [VestaCP: Установка Wordpress в консоли (от создания домена до получения готового сайта)](https://zomro.com/rus/blog/faq/209-vestacp-ustanovka-wordpress-v-konsoli-ot-sozdanija-domena-do-poluchenija-gotovogo-sajta) [Fail2ban: автоматическая блокировка брутфорса SSH и веб-приложений](https://zomro.com/rus/blog/faq/728-fail2ban-automatically-block-ssh-and-web-application-brute-force-attacks) [Подключение к VPS серверу по SSH ключу](https://zomro.com/rus/blog/faq/235-podkljuchenie-k-serveru-cherez-ssh-po-kljuchu-s-nestandartnym-portom) [Подключение рабочих узлов к кластеру n8n Docker Swarm: подготовка серверов](https://zomro.com/rus/blog/faq/621-connecting-worker-nodes-to-a-n8n-docker-swarm-cluster-preparing-servers) [ Сервер для Forex от €7.95/мес ](/rus/server-for-forex)