SSH 'remote host identification has changed' — как решить

kirilljsx

Если при подключении к серверу по SSH вдруг появляется ошибка про изменение идентификации хоста, это не конец света, но игнорировать её нельзя. Ошибка возникает неожиданно и может заблокировать доступ к важным системам. Разберёмся, почему это происходит и как быстро вернуть всё в норму.

Эта проблема встречается часто, особенно при обновлении серверов, смене IP-адресов или ротации ключей безопасности. Знание способов её решения поможет вам не потерять время в критические моменты.

Почему SSH ругается на изменение хоста

Когда вы впервые подключаетесь к серверу по SSH, клиент запрашивает у сервера его публичный ключ для проверки подлинности. Этот процесс называется аутентификацией хоста — сервер доказывает, что он именно тот, на кого выдаёт себя. Если вы согласны с подключением, публичный ключ сохраняется в локальном файле ~/.ssh/known_hosts на вашем компьютере.

В следующий раз, когда вы пытаетесь подключиться к этому же серверу, SSH сравнивает полученный ключ с сохранённым. Если они совпадают — всё хорошо, подключение проходит без вопросов. Но если ключ отличается, SSH выдаёт предупреждение и блокирует доступ. Это сделано для защиты: вдруг кто-то пытается выдать себя за ваш сервер?

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

Как выглядит ошибка и что она значит

Ошибка обычно выглядит примерно так:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:bWaEpc+YCgTvppCmDyIbnFTCnjhsGCQOsGGGHjMFqes.
Please contact your system administrator.
Add correct host key in /Users/you/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/you/.ssh/known_hosts:10
RSA host key for rita.server.com has changed and you have requested strict checking.
Host key verification failed.

Разберём, что здесь важно:

WARNING — это действительно предупреждение, но не обязательно угроза
The fingerprint for the RSA key — отпечаток нового ключа, который прислал сервер
Offending RSA key in ~/.ssh/known_hosts:10 — строка номер 10 в вашем файле known_hosts содержит старый ключ
strict checking означает, что SSH настроен на жёсткую проверку

Этот вывод содержит все данные, которые вам понадобятся для решения проблемы.

Самый быстрый способ: удалить старый ключ из known_hosts

Самое популярное решение — это удалить старую запись о хосте из файла known_hosts. Когда вы подключитесь заново, SSH запросит согласие и сохранит новый ключ. Это займёт буквально несколько секунд.

Чтобы удалить запись по имени хоста или IP-адресу, используйте команду:

ssh-keygen -R hostname_or_ip -f ~/.ssh/known_hosts

Замените hostname_or_ip на имя или адрес вашего сервера. Например:

ssh-keygen -R example.com -f ~/.ssh/known_hosts
ssh-keygen -R 192.168.1.100 -f ~/.ssh/known_hosts

Если вы хотите просто удалить весь файл known_hosts (это опасно, если вы часто подключаетесь ко множеству серверов, но может помочь при массовом обновлении ключей), выполните:

rm ~/.ssh/known_hosts

Об этом более подробно:

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

Ручное редактирование файла known_hosts

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

Файл ~/.ssh/known_hosts содержит по одной записи на каждый хост. Каждая строка состоит из имени хоста, типа ключа и самого ключа. Вы можете открыть файл в любом текстовом редакторе:

nano ~/.ssh/known_hosts

Или:

vi ~/.ssh/known_hosts

Поиск нужной строки может быть затруднён, если ключ длинный. Но ошибка SSH подскажет вам номер строки — посмотрите на строку “Offending RSA key in /Users/you/.ssh/known_hosts:10”. Это значит, что проблемный ключ на строке 10. Просто удалите эту строку и сохраните файл.

Рекомендации по ручному редактированию:

Сделайте резервную копию перед редактированием: cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old
Найдите строку по номеру — сообщение об ошибке вам это подскажет
Удалите только нужную строку — не трогайте остальные записи
Сохраните и закройте редактор

Что делать на Windows с PuTTY

Если вы используете Windows и клиент PuTTY, процесс немного другой. PuTTY хранит ключи не в текстовом файле, а в реестре Windows.

Вот как удалить старый ключ в PuTTY:

Откройте Registry Editor (введите regedit в поиск Windows)
Перейдите по пути: HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\SshHostKeys
Найдите запись, соответствующую вашему серверу (например, rsa2@22:example.com)
Щёлкните правой кнопкой и выберите Delete
Закройте Registry Editor

При следующем подключении PuTTY спросит согласие на новый ключ — просто согласитесь.

Особенности PuTTY:

Ключи хранятся в реестре, а не в файлах
Процесс немного более сложный, чем на Linux/Mac
После удаления нужно заново принять ключ при подключении

Проверка отпечатка ключа перед принятием

Им важный момент — перед тем как согласиться с новым ключом, убедитесь, что это действительно ваш сервер. Отпечаток (fingerprint) ключа — это уникальный идентификатор, который намного короче самого ключа и удобнее для сравнения.

Если администратор сервера опубликовал новый отпечаток, например в письме или в документации, сравните его с тем, что выдаёт вам SSH:

The fingerprint for the RSA key sent by the remote host is
SHA256:bWaEpc+YCgTvppCmDyIbnFTCnjhsGCQOsGGGHjMFqes.

Если совпадает — можете смело согласиться. Если отпечаток неизвестен или не совпадает, свяжитесь с администратором перед тем как продолжать.

Проверка отпечатка — это критически важный шаг безопасности:

Убедитесь, что администратор действительно обновил ключи
Получите отпечаток из надёжного источника (официальное письмо, чат, прямая беседа)
Сравните его перед принятием нового ключа
Никогда не игнорируйте предупреждение об изменении хоста без проверки

Как уведомить клиентов об изменении ключей

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

Напишите письмо или объявление с информацией:

Когда произойдёт обновление (или когда оно уже произошло)
Почему вы обновляете ключи (плановое обслуживание, смена IP, ротация для безопасности)
Что нужно сделать пользователям: удалить старый ключ из known_hosts
Отпечаток нового ключа для проверки
Команду, которую нужно выполнить

Пример письма:

Обновление SSH-ключей на сервере example.com

Внимание: 18 февраля мы обновили SSH-ключи на нашем сервере.
Если при подключении вы видите ошибку "remote host identification has changed",
выполните команду:

ssh-keygen -R example.com -f ~/.ssh/known_hosts

Это удалит старый ключ из вашего файла known_hosts.
При следующем подключении примите новый ключ.

Отпечаток нового RSA-ключа (для проверки):
SHA256:bWaEpc+YCgTvppCmDyIbnFTCnjhsGCQOsGGGHjMFqes

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

Шаги для администратора:

Уведомите пользователей до или сразу после обновления
Предоставьте точный отпечаток нового ключа
Дайте готовую команду для удаления старого ключа
Будьте готовы ответить на вопросы в первые часы

Продвинутые решения: SSHFP-записи и автоматизация

Для больших сетей с множеством серверов существуют более автоматизированные подходы. Один из них — использование SSHFP DNS-записей.

SSHFP (SSH Public Key Fingerprint) — это запись в DNS, которая содержит отпечаток SSH-ключа вашего сервера. Клиент может автоматически проверить отпечаток по DNS вместо того, чтобы хранить его локально. Это особенно полезно при частых обновлениях ключей или в облачной инфраструктуре, где серверы часто пересоздаются.

Добавить SSHFP-запись можно через панель управления вашим DNS-хостером. После этого клиенты смогут конфигурировать SSH для автоматической проверки по DNS.

Для очень больших инфраструктур используют:**

Централизованное управление ключами — хранение всех публичных ключей в одном месте
Автоматическое распределение — скрипты, которые обновляют known_hosts на всех машинах
Конфигурационный менеджмент — Ansible, Puppet или Chef для управления SSH-ключами

Эти решения требуют больше времени на настройку, но окупаются в крупных организациях с сотнями или тысячами серверов.

Когда быть осторожнее всего

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

Когда нужна повышенная бдительность:

Вы подключаетесь к серверу в облаке или на виртуальном хосте, где вы не администратор
Никто вас не предупреждал об обновлении ключей
Это критический сервер с важными данными
Вы подключаетесь с открытой сети (например, через мобильный интернет)

В таких случаях:

Свяжитесь с администратором и спросите, действительно ли ключи обновлялись
Получите отпечаток из независимого источника
Проверьте другие способы доступа (веб-панель, консоль в облаке)
Только после этого удаляйте старый ключ

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

Что остаётся за кадром

Саmo явление изменения хоста — это баланс между удобством и безопасностью. SSH выбирает безопасность, что правильно для критичных систем. Но для разработчиков, работающих с десятками серверов, это может быть раздражающим.

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