Эта проблема встречается часто, особенно при обновлении серверов, смене 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 выбирает безопасность, что правильно для критичных систем. Но для разработчиков, работающих с десятками серверов, это может быть раздражающим.

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