Что за предупреждение и почему оно такое громкое
Клиент SSH при первом подключении запоминает отпечаток открытого ключа сервера и записывает его в файл known_hosts в каталоге .ssh пользователя. При следующих заходах он сравнивает то, что предъявил сервер, с сохранённым значением. Если отпечатки различаются, выводится крупный блок с надписью «WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!» и текстом о возможной атаке «man-in-the-middle». Вход при этом прекращается.
Строгость намеренная: механизм защищает от подмены сервера. Но в повседневной практике в подавляющем большинстве случаев причина скучная, а не злонамеренная. В сообщении обычно указан номер строки в known_hosts, где лежит старая запись, и путь к файлу, что заметно ускоряет разбор.
Причины по убыванию вероятности: SSH «REMOTE HOST IDENTIFICATION HAS CHANGED»
Самая частая причина: сервер переустановили или пересоздали. У новой системы появляются новые ключи хоста, а адрес остался прежним. То же бывает с виртуальными машинами и облачными инстансами, когда на старый IP-адрес выдан новый сервер.
Вторая по частоте: адрес перешёл к другому устройству. Так происходит с домашними стендами, где DHCP выдаёт один и тот же адрес разным машинам, и с одноразовыми контейнерами. Третья: администратор намеренно сменил ключи хоста, например после обновления или из-за политики безопасности. Четвёртая: подключение идёт через балансировщик или по общему имени к нескольким серверам с разными ключами, и вам попадается то один, то другой.
Наконец, остаётся настоящая подмена. Это редкий вариант, но именно ради него предупреждение и существует, поэтому сначала стоит убедиться, что изменение ожидаемо.
Как проверить, что смена ключа законна
Прежде чем что-то удалять, спросите себя: был ли у сервера повод поменять ключи. Переустановка, миграция, смена провайдера, замена железа: если вы или коллеги что-то из этого делали, ответ, скорее всего, положительный.
Дальше сверьте отпечаток по независимому каналу. Если у вас есть консоль хостинга или физический доступ, выполните на сервере команду ssh-keygen -lf для файла открытого ключа хоста из каталога /etc/ssh и сравните результат с отпечатком, который показывает клиент при новом подключении. Совпадение означает, что вы говорите с нужной машиной. Если независимого канала нет, спросите администратора сервера. Не подтверждайте отпечаток вслепую, привычка нажимать «yes» на любые вопросы сводит защиту к нулю.
Как исправить запись
Когда смена подтверждена, старую запись нужно убрать. Проще всего командой ssh-keygen с ключом -R и именем или адресом хоста: она удалит соответствующие строки из known_hosts и оставит резервную копию файла с суффиксом old. Можно открыть файл в редакторе и удалить строку с номером из сообщения, но команда надёжнее, потому что учитывает и хэшированные имена.
После этого подключитесь снова. Клиент покажет новый отпечаток и спросит подтверждение. Сравните его с эталонным и только затем введите yes. Если вы заходите и по имени, и по голому IP-адресу, в known_hosts могут быть две отдельные записи, и убрать придётся обе. Ту же ошибку по другому пути дают нестандартные порты: запись хранится в виде имени с номером порта в квадратных скобках.
Когда стоит насторожиться
Поведение подозрительно, если ключ изменился, хотя никто ничего не переустанавливал, а предупреждение появилось внезапно на давно стабильном сервере, особенно при подключении из чужой или общественной сети. В такой ситуации не вводите пароль. Зайдите на сервер другим способом, через консоль хостинга, и проверьте, менялись ли файлы ключей хоста и когда.
Отдельно не стоит отключать проверку совсем через StrictHostKeyChecking no или указывать в качестве known_hosts пустое устройство. Для одноразовых тестовых стендов это допустимый компромисс, но для рабочих серверов он лишает вас единственной защиты от подмены. Разумнее хранить ключи серверов в общем доверенном месте и обновлять их осознанно.
Управление known_hosts в командах и на нескольких машинах
Если вы подключаетесь к большому числу серверов, полезно понимать, как устроен файл известных хостов. В нём каждая строка содержит имя или адрес хоста, тип ключа и сам ключ. По умолчанию имена могут храниться в хэшированном виде, поэтому глазами найти нужную строку не всегда получается, и здесь выручает команда ssh-keygen с ключом -F, которая ищет запись по имени.
В командах, где серверы часто пересоздаются, например в тестовых окружениях, разумно хранить отпечатки в едином доверенном источнике и обновлять их скриптом после каждой пересборки. Так вы не приучаетесь игнорировать предупреждения. Кроме того, у одного сервера может быть несколько ключей разных типов, и клиент выбирает один из них. Смена предпочтительного типа иногда порождает видимость подмены, хотя сервер на месте: проверьте, какой тип ключа записан и какой предъявляется.