Вы переустановили систему на сервере, пытаетесь подключиться по SSH, а вместо запроса пароля терминал выводит рамку из символов @, тревожную надпись WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! и обрывает соединение со словами Host key verification failed. Выглядит пугающе, но в большинстве случаев причина безобидна. В этой статье разберём, откуда берётся предупреждение, как убедиться, что всё в порядке, и как убрать его одной командой. Все команды мы проверили на тестовом сервере.
Так выглядит ошибка, IP-адрес сервера на скриншоте скрыт
Почему появляется предупреждение
Когда вы подключаетесь к серверу по SSH, соединение шифруется ещё до того, как вы введёте пароль. Однако шифрование само по себе не гарантирует, что на другом конце находится именно ваш сервер. Представим, что кто-то в сети между вами и сервером перехватил соединение и выдаёт себя за сервер. Вы установите зашифрованный канал, только не с сервером, а с перехватчиком, и спокойно отправите ему свой пароль. Чтобы такая подмена не прошла незамеченной, у каждого сервера есть собственная пара ключей хоста. Закрытый ключ хранится на сервере в каталоге /etc/ssh/, а открытый сервер предъявляет каждому, кто к нему подключается, и подтверждает, что действительно владеет парным закрытым ключом.
Остаётся вопрос, откуда ваш компьютер знает, какой ключ правильный. Ответ прост. Он запоминает его при первом подключении. Когда вы впервые заходите на сервер, SSH показывает отпечаток его ключа, короткую строку вида SHA256:ku3PZ…, и спрашивает, доверяете ли вы ему. После ответа yes ключ записывается в файл known_hosts на вашем компьютере рядом с IP-адресом сервера. При каждом следующем подключении SSH сравнивает ключ, который предъявил сервер, с тем, что записан в этом файле. Пока они совпадают, никаких вопросов не возникает.
Предупреждение появляется ровно тогда, когда ключи перестают совпадать. SSH не может сам определить причину, поэтому перечисляет обе возможности. Первая из них тревожная. Соединение перехвачено, и вам отвечает чужой сервер. Вторая будничная. Ключ сервера действительно сменился. Чаще всего это происходит после переустановки операционной системы. Новая система при первом запуске генерирует новые ключи хоста, а ваш компьютер по-прежнему помнит старые. То же самое случается, если IP-адрес, к которому вы раньше подключались, теперь принадлежит другому серверу. Поскольку пароль отправлять в такой ситуации опасно, SSH предпочитает оборвать соединение и оставить решение за вами.
1. Убедитесь, что ключ сменился по понятной причине
Если вы только что переустанавливали систему на этом сервере, причина ясна, и можно сразу переходить к следующему шагу. Если же вы ничего не меняли, а предупреждение появилось, проверьте отпечаток ключа на самом сервере. Подключиться к нему без SSH можно через консоль VNC в личном кабинете. Войдите в неё под root и выполните команду.
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
Отпечаток ключа, который хранится на самом сервере
Сравните отпечаток после SHA256: с тем, что показано в предупреждении в строке The fingerprint for the ED25519 key sent by the remote host is. На тестовом сервере они совпали, а значит, к нам отвечает наш сервер, просто с новым ключом.
Отпечатки не совпадают
Если ключ на сервере отличается от того, что пришёл при подключении, не вводите пароль и не удаляйте старый ключ. Попробуйте подключиться из другой сети, например через мобильный интернет, и напишите в поддержку.
2. Удалите старый ключ
Старая запись о сервере удаляется одной командой. Вместо IP-адрес-сервера подставьте адрес, к которому подключаетесь.
ssh-keygen -R IP-адрес-сервераКоманда одинаково работает в Windows, macOS и Linux.
- Windows. Откройте PowerShell или Командную строку. Ключи хранятся в файле
C:\Users\Имя_пользователя\.ssh\known_hosts. - macOS и Linux. Откройте Терминал. Ключи хранятся в файле
~/.ssh/known_hosts.
В ответ команда напишет, в какой строке нашла сервер, и сохранит копию прежнего файла с окончанием .old.
Если SSH на вашем сервере работает не на порту 22, адрес нужно записать вместе с портом в квадратных скобках и взять в кавычки, например так.
ssh-keygen -R "[IP-адрес-сервера]:2222"3. Подключитесь заново
Подключитесь к серверу как обычно. SSH сообщит, что не знает этот сервер, покажет отпечаток нового ключа и спросит, продолжать ли подключение.
ssh root@IP-адрес-сервераВведите yes и нажмите Enter. Новый ключ запишется в known_hosts, и SSH попросит пароль от сервера.
Старый ключ удалён, новый принят после ответа yes
Если вы подключаетесь через PuTTY или Termius
PuTTY хранит ключи серверов не в файле known_hosts, а в реестре Windows, поэтому команда ssh-keygen -R на него не влияет. При смене ключа PuTTY показывает собственное окно с заголовком WARNING - POTENTIAL SECURITY BREACH! и текстом The server's host key does not match the one PuTTY has cached for this server. Если вы уверены, что ключ сменился из-за переустановки системы, примите новый ключ в этом окне, и PuTTY запомнит его вместо старого.
В Termius и других программах с собственным списком серверов действуйте так же. Если программа предупреждает о смене ключа и вы знаете причину, примите новый ключ в её окне. Как подключаться через Termius, рассказано в отдельной статье.
Частые вопросы
Offending ED25519 key in known_hosts, а ssh-keygen -R не помогает
Сервер может быть записан в known_hosts несколько раз, например по IP-адресу и по доменному имени. Удалите обе записи.
ssh-keygen -R IP-адрес-сервера
ssh-keygen -R ваш-домен.ruВ конце строки Offending … key in указан номер строки в файле, например known_hosts:3. Если удобнее, откройте файл в текстовом редакторе и удалите эту строку вручную.
Host key verification failed без рамки с предупреждением
Так бывает, когда SSH запущен без возможности задать вопрос, например из скрипта или из программы для деплоя, и сервер ему ещё не знаком. Подключитесь к серверу один раз вручную в терминале и подтвердите ключ ответом yes, после этого скрипт будет работать.
Можно ли просто отключить эту проверку
Технически можно, но не стоит. Параметр StrictHostKeyChecking no заставляет SSH молча принимать любой ключ, и тогда вы не узнаете о перехвате соединения, если он когда-нибудь случится. Удалить один устаревший ключ быстрее и безопаснее.
Как не получать это предупреждение после каждой переустановки
После переустановки ключи сервера всегда новые, поэтому предупреждение появится снова, это нормальное и полезное поведение. Достаточно каждый раз выполнять ssh-keygen -R с адресом сервера. Как переустановить систему, рассказано в статье про переустановку ОС.
Наши ресурсы
Telegram-канал: https://t.me/f3cloud_news
Официальный сайт: https://f3cloud.com