> Полный список статей есть в [llms.txt](https://docs.f3cloud.com/llms.txt). Markdown-версия есть у каждой страницы, достаточно добавить .md к её адресу. Эта страница в Markdown: [https://docs.f3cloud.com/ru/linux/remote-host-identification-changed.md](https://docs.f3cloud.com/ru/linux/remote-host-identification-changed.md). # Ошибка REMOTE HOST IDENTIFICATION HAS CHANGED в SSH – почему появляется и как исправить Что делать, если при подключении по SSH появляется WARNING REMOTE HOST IDENTIFICATION HAS CHANGED и Host key verification failed. Почему ключ сервера меняется после переустановки ОС, как проверить отпечаток и удалить старый ключ командой ssh-keygen -R в Windows, macOS и Linux. Вы переустановили систему на сервере, пытаетесь подключиться по SSH, а вместо запроса пароля терминал выводит рамку из символов `@`, тревожную надпись **WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!** и обрывает соединение со словами **Host key verification failed**. Выглядит пугающе, но в большинстве случаев причина безобидна. В этой статье разберём, откуда берётся предупреждение, как убедиться, что всё в порядке, и как убрать его одной командой. Все команды мы проверили на тестовом сервере.
Предупреждение 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](https://docs.f3cloud.com/ru/client-area/upravlenie-serverom.md#konsol-vnc) в личном кабинете. Войдите в неё под `root` и выполните команду. ```bash ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub ```
Вывод ssh-keygen -lf с отпечатком SHA256 ключа ED25519 сервера

Отпечаток ключа, который хранится на самом сервере

Сравните отпечаток после `SHA256:` с тем, что показано в предупреждении в строке **The fingerprint for the ED25519 key sent by the remote host is**. На тестовом сервере они совпали, а значит, к нам отвечает наш сервер, просто с новым ключом. > **Отпечатки не совпадают.** > > Если ключ на сервере отличается от того, что пришёл при подключении, не вводите пароль и не удаляйте старый ключ. Попробуйте подключиться из другой сети, например через мобильный интернет, и напишите в поддержку. *** ## 2. Удалите старый ключ Старая запись о сервере удаляется одной командой. Вместо `IP-адрес-сервера` подставьте адрес, к которому подключаетесь. ```bash ssh-keygen -R IP-адрес-сервера ``` Команда одинаково работает в Windows, macOS и Linux. * **Windows.** Откройте **PowerShell** или **Командную строку**. Ключи хранятся в файле `C:\Users\Имя_пользователя\.ssh\known_hosts`. * **macOS и Linux.** Откройте **Терминал**. Ключи хранятся в файле `~/.ssh/known_hosts`. В ответ команда напишет, в какой строке нашла сервер, и сохранит копию прежнего файла с окончанием `.old`. Если SSH на вашем сервере работает не на порту 22, адрес нужно записать вместе с портом в квадратных скобках и взять в кавычки, например так. ```bash ssh-keygen -R "[IP-адрес-сервера]:2222" ``` *** ## 3. Подключитесь заново Подключитесь к серверу как обычно. SSH сообщит, что не знает этот сервер, покажет отпечаток нового ключа и спросит, продолжать ли подключение. ```bash ssh root@IP-адрес-сервера ``` Введите `yes` и нажмите Enter. Новый ключ запишется в `known_hosts`, и SSH попросит пароль от сервера.
Удаление старого ключа командой ssh-keygen -R и повторное подключение с подтверждением нового отпечатка

Старый ключ удалён, новый принят после ответа 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, рассказано в [отдельной статье](https://docs.f3cloud.com/ru/vps/termius-connection.md). *** ## Частые вопросы
Offending ED25519 key in known_hosts, а ssh-keygen -R не помогает Сервер может быть записан в `known_hosts` несколько раз, например по IP-адресу и по доменному имени. Удалите обе записи. ```bash 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` с адресом сервера. Как переустановить систему, рассказано в статье про [переустановку ОС](https://docs.f3cloud.com/ru/client-area/reinstall-os.md).
*** ## Наши ресурсы **Telegram-канал:** [https://t.me/f3cloud_news](https://t.me/f3cloud_news)\ **Официальный сайт:** [https://f3cloud.com](https://f3cloud.com/ru)