SSH «Host key verification failed»: как безопасно исправить

При первом подключении SSH показывает отпечаток ключа сервера и просит подтвердить его, после чего запоминает в файле known_hosts. При последующих входах клиент сверяет ключ с сохранённым. Если ключ не совпал, или его не удалось подтвердить в неинтерактивном режиме, выводится «Host key verification failed», нередко с предупреждением «REMOTE HOST IDENTIFICATION HAS CHANGED».

Это защитный механизм, а не поломка. Он спрашивает: вы уверены, что говорите именно с тем сервером, что раньше? Поэтому автоматически «чинить» его без понимания причины не стоит.

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

Ещё причина: у вас несколько серверов за балансировщиком с разными ключами, либо в known_hosts записан ключ для адреса другого типа. Но настоящая подмена сервера в сети (атака посредника) тоже даёт такую ошибку, поэтому исключать её нельзя, особенно если вы ничего на сервере не меняли.

В автоматических сценариях ошибка появляется потому, что при отсутствии человека клиент не может спросить о подтверждении ключа. Заранее сохраните ключ сервера в known_hosts, тогда сценарий подключится без вопросов и не потеряет проверку подлинности.

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

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

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

Когда причина установлена и это безопасно, удалите старую запись для этого хоста. Сделать это можно штатной командой ssh-keygen с параметром удаления записи для хоста, либо вручную удалить нужную строку в known_hosts. При следующем подключении подтвердите новый отпечаток, предварительно сверив его.

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

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

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

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

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