SSH — защищённый сетевой протокол, создающий зашифрованный туннель между системами. Он по-прежнему востребован среди разработчиков, которым нужен удалённый доступ к компьютерам без графического интерфейса. Несмотря на многолетнюю историю и надёжную работу, SSH не застрахован от определённых ошибок.
Многие из этих ошибок хорошо известны в сообществе SSH, а способы их устранения подробно задокументированы. К ним относятся: несовместимость с межсетевым экраном, проблемы с внедрением публичного ключа SSH, проблемы с режимом файлового ключа SSH, и ошибку «Warning: Remote Host Identification Has Changed».
Эта ошибка встречается на всех основных операционных системах, включая Windows, Linux и macOS. Причина может быть не просто техническим сбоем, а реальной угрозой безопасности. В этой статье мы разберём, почему это происходит, что это значит для безопасности вашего SSH-соединения и как устранить проблему на каждой из платформ.
Почему появляется предупреждение «Warning: Remote Host Identification Has Changed» — и стоит ли беспокоиться?
Предупреждение «Warning: Remote Host Identification Has Changed» возникает, когда публичный ключ SSH, сохранённый в файле known_hosts не совпадает с ключом, который сервер предъявляет сейчас. Это расхождение активирует встроенный механизм защиты SSH, предупреждающий о возможных угрозах.
Когда смена ключа хоста не является проблемой
Существует несколько безопасных причин, по которым ключ хоста сервера может измениться. В зависимости от типа ключа сообщение может выглядеть иначе, например «RSA host key has changed».
Изменения на стороне сервера:
- Операционная система сервера была переустановлена или обновлена
- Сервер был пересобран или восстановлен из резервной копии
- Конфигурация SSH на сервере была сброшена
- Физическая или виртуальная машина была заменена
- Миграция сервера на новое оборудование
Изменения в сетевой конфигурации:
- Облачные провайдеры со временем переназначают IP-адреса, либо подключение проходит через балансировщик нагрузки.
- DHCP присвоил IP-адрес другой машине
- IP-адрес выведенного из эксплуатации сервера был назначен новой системе
- Записи DNS были обновлены и теперь указывают на другой сервер
Управление ключами:
- Системные администраторы вручную перегенерировали ключи хоста в целях безопасности
- Серверное программное обеспечение SSH было переустановлено
- Политика безопасности потребовала ротации ключей
Важно понимать, что смена пароля пользователя не влияет на ключи хоста. Это отдельные механизмы аутентификации. Ключи хоста меняются только при изменении самого сервера или его конфигурации SSH.
Когда стоит отнестись к предупреждению серьёзно
Большинство изменений ключей хоста вполне законны, однако в некоторых случаях это может быть реальной угрозой безопасности. Стоит насторожиться, если:
- Вы не вносили изменений на сервере и не знаете о запланированных работах
- Вы не можете выяснить причину смены ключа у администратора сервера
- Сервер доступен через публичные сети или ненадёжные соединения
- Вы подключаетесь к production-системам или серверам с конфиденциальными данными
Атаки типа «человек посередине» случаются относительно редко, но всё же происходят. В ходе такой атаки злоумышленник встаёт между вашим компьютером и легитимным сервером и перехватывает весь трафик.
Человеческий фактор и социальная инженерия — причина 68% утечек данных, поэтому бдительность критически важна. Дополнительно защитить свои системы можно, изучив методы защиты от брутфорс-атак.
По данным IBM, средняя мировая стоимость утечки данных в 2025 году составила 4,44 млн долларов, а среднее время обнаружения — восемь месяцев. Именно поэтому в SSH существует механизм проверки ключей хоста и почему нельзя игнорировать эти предупреждения без предварительного расследования.
Как проверить, безопасно ли предупреждение
Прежде чем устранять проблему, выполните следующие шаги проверки:
- Проверьте с коллегами: Если доступ к серверу разделён, спросите у коллег, не вносили ли они изменения
- Просмотрите логи сервера: Проверьте записи о техническом обслуживании или журнал изменений на предмет недавней активности
- Свяжитесь с хостинг-провайдером: Если используете облачные сервисы, уточните, проводились ли технические работы
- Используйте защищённый канал: По возможности подключитесь через заведомо защищённую сеть, чтобы проверить отпечаток
- Сравните отпечатки: Некоторые хостинг-провайдеры отображают актуальные отпечатки SSH в своих панелях управления
Если вы уверены, что смена ключа была законной, можно безопасно удалить старый ключ и принять новый.
Если вы хотите избежать динамической переназначения IP или конфликтов host-ключей, выбор инфраструктуры имеет большое значение.
Cloudzy предоставляет Хостинг SSH VPS с выделенными статическими IP. Работает на процессорах AMD Ryzen 9 с хранилищем NVMe для мгновенного выполнения команд. Наша сеть достигает 40 Gbps в 12 точках присутствия по всему миру. Также в комплект входит бесплатная защита DDoS для безопасного соединения.
Как исправить ошибку «Remote Host Identification Has Changed»
Решение простое: удалите старую запись ключа из вашей системы. Это устранит несоответствие и позволит сохранить новый ключ при следующем подключении. Смотрите наше руководство по клиентам SSH для получения дополнительных инструментов.
Это можно сделать одной командой или вручную отредактировав файл.
Способ 1: командная строка (быстрее всего)
Этот способ подходит для macOS, Linux и Windows 10+ (с использованием OpenSSH). Это самый быстрый способ устранить ошибку. Подробнее можно прочитать на странице руководства ssh-keygen.
- Откройте терминал.
- Выполните эту команду (замените hostname на IP-адрес или домен вашего сервера):
ssh-keygen -R hostnameЕсли вы предпочитаете визуальный редактор, можно удалить ключ вручную. Сообщение об ошибке обычно точно указывает, какую строку нужно удалить.
Откройте терминал и отредактируйте файл с помощью Nano:
nano ~/.ssh/known_hosts
Найдите строку из сообщения об ошибке. Удалите её, затем нажмите Ctrl + X и Y для сохранения.
Решение для Windows
Пользователи Windows обычно используют либо встроенный клиент OpenSSH, либо PuTTY.
Вариант 1: Windows OpenSSH (Windows 10/11)
В Windows 10 и 11 OpenSSH является опциональным компонентом. Добавьте его через Параметры > Приложения > Дополнительные компоненты. В Server 2025 клиент уже включён, но его нужно активировать вручную.
Если вы используете PowerShell или командную строку, то ssh-keygen Команда из метода 1 здесь тоже подходит.
Чтобы отредактировать файл вручную:
- Нажмите Windows Key + R.
- Тип %USERPROFILE%\.ssh и нажмите Enter.
- Откройте файл known_hosts файл с помощью Notepad.
- Удалите строку, вызывающую ошибку, и сохраните файл.
Подробнее об управлении ключами читайте в нашем руководстве по генерация ключей SSH в Windows.
Вариант 2: использование PuTTY
PuTTY хранит ключи в реестре Windows, а не в файле.
- Откройте редактор реестра (нажмите Windows Key + Rвведите regedit, и нажмите Enter).
- Перейдите по пути: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
- Найдите запись, соответствующую имени хоста или IP-адресу вашего сервера.
- Нажмите на него правой кнопкой мыши и выберите Удалить.
Решение для Linux
Параметр ssh-keygen команда, которую мы рассмотрели в Метод 1 является стандартным способом решить эту проблему в Linux. Он быстрый и поддерживается нативно.
Ручное редактирование
Если вы хотите видеть содержимое файла, можно отредактировать его в текстовом редакторе, например в Nano.
- Откройте терминал.
- Тип nano ~/.ssh/known_hosts и нажмите Enter.
- Найдите номер строки, указанный в сообщении об ошибке.
- Удалите строку, затем нажмите Ctrl + X и Y для сохранения.
Можно также использовать Vim (vim ~/.ssh/known_hosts), если вы знакомы с ним.
Об отключении проверок
Можно принудительно подключить SSH без проверки, но это рискованно: такой подход обходит защиту от атак типа «человек посередине».
Используйте этот способ только при локальном тестировании в доверенных сетях. Для macOS и Linux введите следующее:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]Если вы используете Windows, путь Unix не сработает. Нужно указать NUL чтобы обход заработал:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]Не применяйте эти параметры в публичных сетях или на рабочих серверах.
Исправление несовпадения ключей — стандартная задача обслуживания, но можно сделать соединение ещё надёжнее. Боты часто атакуют порт 22 по умолчанию методом перебора. Большую часть этого фонового шума можно устранить, изменив порты SSH в Linux на что-то менее предсказуемое.
Никогда не применяйте этот метод на рабочих серверах или в ненадёжных сетях.
Как избежать сообщения «Remote Host Identification Has Changed» в будущем
Не всегда можно предотвратить законную смену ключа хоста, но можно сократить число сбоев и придерживаться более строгих правил безопасности.
Краткий справочник
| Ваша роль | Ключевые стратегии |
| Системные администраторы | Делайте резервные копии ключей, документируйте изменения, используйте сертификаты и регулярно меняйте ключи |
| Обычные пользователи | Ведите учёт, проверяйте через защищённые каналы и отслеживайте логи |
| Облачная среда
Пользователи |
Используйте имена DNS, инструменты провайдера и подход инфраструктуры как кода |
Для системных администраторов
Резервное копирование ключей хоста: Сохраните ключи из /etc/ssh/ перед переустановкой ОС. Восстановите их после — это избавит пользователей от предупреждений.
Документируйте плановые изменения: Предупреждайте пользователей перед сменой ключей и передавайте новые fingerprint по защищённому каналу. Это позволит им подтвердить подлинность соединения.
Используйте сертификаты SSH: В крупных командах стоит развернуть централизованный центр сертификации. Он подписывает ключи хостов и устраняет необходимость ручной проверки.
Настройте ротацию ключей: Планируйте смену ключей хоста по расписанию. Предсказуемые обновления проще воспринимаются командой, чем внезапные.
Для обычных пользователей
Ведите учёт: Храните личный список fingerprint серверов или пользуйтесь защищённой документацией команды.
Проверяйте через независимый канал: Сверяйте ключи с доверенным источником — например, с облачной консолью, а не через мессенджеры.
Мониторинг логов: Регулярно проверяйте локальные логи SSH на предмет подозрительных шаблонов подключений или повторяющихся ошибок.
Управление конфигурацией: Используйте конфигурационные файлы SSH для работы с динамическими средами разработки без снижения уровня безопасности.
Для динамических облачных сред
Используйте имена DNS: Подключайтесь по именам хостов, а не по IP-адресам. Это обеспечивает стабильность при смене базового адреса.
Облачные инструменты: Используйте консоли провайдера для получения актуальных отпечатков. Сверяйте ключи с этими инструментами перед принятием изменений.
Инфраструктура как код: Автоматизируйте проверку ключей с помощью таких инструментов, как Terraform. Для продвинутых конфигураций можно также использовать SOCKS5-прокси SSH.
Хосты-бастионы: Настройте промежуточные серверы со стабильными ключами. Они служат защищёнными точками входа в вашу динамическую инфраструктуру.
Заключение
Предупреждение «Warning: Remote Host Identification Has Changed» — это важная функция безопасности SSH, а не ошибка, которую можно игнорировать. Хотя оно нередко появляется по вполне законным причинам — например, при обслуживании сервера или изменении конфигурации — оно защищает вас от атак типа «человек посередине» и несанкционированного доступа.
Если вы видите это предупреждение, выясните причину до продолжения работы. В большинстве случаев решение простое: удалите старый ключ хоста одним из описанных способов для вашей операционной системы, затем примите новый ключ при следующем подключении.
Разобравшись в том, как работают ключи хостов SSH, и следуя лучшим практикам, вы сохраните и безопасность, и удобство при удалённой работе. О безопасной передаче файлов читайте здесь: копирование файлов через SSH.
