SSH сообщает о смене ключа сервера: что проверить до входа

При REMOTE HOST IDENTIFICATION HAS CHANGED остановите подключение и подтвердите новый отпечаток ключа сервера через доверенный независимый канал. Переустановка или перенос могут объяснить смену, но сами по себе не подтверждают подлинность узла. Обновлять сохранённое доверие можно после проверки конкретного сервера и ключа.

Предупреждение о сервере, а не о вашем пароле

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

Не путайте это сообщение с отказом принять ваш пользовательский ключ. Замена пароля сотрудника или повторная загрузка его открытого ключа не подтверждает новый ключ сервера. Это разные стороны проверки и разные основания для действий.

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

Сначала установите, какой узел ожидался

Сверьте имя назначения, порт и принятую в вашей инфраструктуре схему подключения. Один короткий псевдоним может использоваться в разных рабочих окружениях. Догадка «это наш старый сервер» слабее записи о конкретном экземпляре и его назначении.

Если менялись DNS, маршрутизация или конфигурация клиента, восстановите ожидаемый путь по журналу изменений. Не считайте найденное объяснение доказательством. Нужно подтвердить, что текущий адрес действительно относится к нужному узлу, а предлагаемый ключ принадлежит ему.

Что объясняет событие и что подтверждает ключ

Ниже — учебная таблица решений для владельца инфраструктуры. Она не описывает инцидент какой-либо компании. Для каждого наблюдения предусмотрено независимое подтверждение, потому что правдоподобная причина и проверенная идентификация — разные результаты.

Откуда брать эталон для сравнения

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

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

В разборе GitLab для собственного сервера среди причин указано пересоздание узла с прежним именем или адресом. При принятии нового ключа предлагается сверить отпечаток с администратором. Это частный контекст: ключи чужого публичного сервиса не являются эталоном вашего VPS.

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

Зафиксируйте, к какому алгоритму ключа относится отпечаток и как он представлен. OpenSSH описывает разные способы представления отпечатков. Нельзя объявлять несовпадение или совпадение по двум строкам разного назначения без нормализации условий сравнения.

Для учебного объяснения назовём старое значение «А», предложенное клиенту «Б», а полученное из доверенной консоли — «В». Совпадение Б и В в одинаковом представлении подтверждает конкретное сравнение. Запись о переустановке объясняет, почему А могло отличаться. Настоящие значения здесь не нужны.

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

Что делать с known_hosts после подтверждения

В known_hosts клиент хранит сведения о доверенных ключах узлов. Изменение соответствующей записи — изменение доверия, а не косметическое исправление ошибки. Сначала зафиксируйте подтверждение, затем обновляйте только относящиеся к нему сведения по принятому регламенту.

В описании StrictHostKeyChecking различается отношение к новым и изменившимся ключам. В частности, accept-new допускает автоматическое добавление новых узлов, но не разрешает подключение при сменившемся ключе известного узла. Это не универсальная кнопка разрешения данного предупреждения.

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

Если изменение осталось необъяснённым

Прекратите попытки для этого назначения и передайте событие ответственному за инфраструктуру. Укажите время, ожидаемый узел, маршрут и полученное предупреждение. Само сообщение ещё не доказывает атаку, но неподтверждённость не позволяет считать продолжение входа штатным действием.

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

Порядок возвращения к работе

1. Остановите соединение с предупреждением и сохраните его контекст.
2. Определите точное ожидаемое назначение, окружение и порт.
3. Установите, было ли согласованное изменение сервера.
4. Получите эталонный отпечаток через доверенный независимый канал.
5. Сравните ключ и отпечаток в одинаковом представлении.
6. При подтверждении адресно обновите доверие и запишите основание; при несовпадении продолжайте разбор.

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