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-систем або серверів, що містять конфіденційні дані
Атаки man-in-the-middle, хоча й відносно рідкі, трапляються. У таких атаках зловмисник розташовується між вашим комп'ютером і легітимним сервером, перехоплюючи весь трафік.
Людська помилка та соціальна інженерія становлять 68% порушень безпеки, тому бути уважним критично важливо. Ви можете додатково захистити свої системи, вивчаючи запобігання brute-force атакам.
Нещодавна статистика IBM показує, що глобальна середня вартість витік даних склала 4,44 мільйона доларів у 2025 році, із середнім часом виявлення вісім місяців. Це демонструє, чому механізм верифікації хост-ключів SSH існує і чому ви ніколи не повинні ігнорувати ці попередження без розслідування.
Як перевірити, чи попередження безпечне
Перш ніж переходити до вирішення проблеми, виконайте ці кроки верифікації:
- Поговоріть із командою: Якщо ви ділитесь доступом до сервера, запитайте колег, чи вони робили зміни
- Перевірте логи сервера: Перевірте записи обслуговування або журнали змін на предмет нещодавної активності
- Зв'яжіться з хостинг-провайдером: Якщо ви використовуєте хмарні сервіси, перевірте, чи проводилось обслуговування
- Використовуйте захищений канал: Якщо можливо, підключіться через відому захищену мережу для верифікації відбитка
- Порівняти відбитки: Деякі хостинг-провайдери показують поточні відбитки SSH у своїх панелях керування
Якщо ви можете підтвердити, що зміна ключа була законною, ви можете спокійно видалити старий ключ і прийняти новий.
Якщо ви хочете уникнути переприсвоєння динамічних IP-адрес або конфліктів хост-ключів, то вибір інфраструктури відіграє важливу роль.
Cloudzy надає Хостинг SSH VPS з виділеними статичними IP-адресами. Ви працюєте на процесорах AMD Ryzen 9 з накопичувачем NVMe для миттєвого виконання команд. Наша мережа забезпечує 40 Gbps у 12 глобальних локаціях. Плюс ми включаємо безплатний захист DDoS для безпеки вашого з'єднання.
Як виправити помилку "Remote Host Identification Has Changed"
Виправлення просте: видаліть старий запис ключа з вашої системи. Це усуває невідповідність і дозволяє зберегти новий ключ при наступному підключенні. Перегляньте наш посібник щодо SSH клієнти для додаткових інструментів.
До того ж, ви можете зробити це однією командою або відредагувати файл вручну.
Спосіб 1: Командний рядок (найшвидше)
Цей метод працює для macOS, Linux та Windows 10+ (за допомогою OpenSSH). Це найшвидший спосіб розв'язати помилку. Для отримання додаткової інформації ви можете прочитати сторінку man 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 або Command Prompt, команда ssh-keygen з Способу 1 також тут працює.
Щоб змінити файл вручну:
- Натисніть Клавіша Windows + R.
- Тип %USERPROFILE%\.ssh та натисніть Enter.
- Відкрити known_hosts файл за допомогою Notepad.
- Видаліть рядок, який викликає помилку, і збережіть файл.
Для правильного керування ключами дивіться наш посібник щодо генерування SSH ключів в Windows.
Варіант 2: Використання PuTTY
PuTTY зберігає ключі в реєстрі Windows замість файлу.
- Відкрийте редактор реєстру (натисніть Клавіша Windows + 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 підключитися без перевірки, але це ризиковано. Це обходить захист від атак man-in-the-middle.
Використовуйте цей підхід тільки для локального тестування в довірених мережах. Для 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/ перед перевстановленням операційної системи. Відновіть їх потім, щоб запобігти попередженням для ваших користувачів.
Документуйте заплановані зміни: Попередьте користувачів перед змінюванням ключів і безпечно поділіться новими відбитками пальців. Це дозволить їм перевірити з'єднання.
Використовуйте сертифікати SSH: Великі команди повинні використовувати центральний центр сертифікації. Він підписує ключі хоста й усуває потребу в ручній перевірці.
Впроваджуйте ротацію ключів: Планируйте оновлення ключів хоста. Передбачувані оновлення легше управляти вашій команді, ніж несподівані.
Для звичайних користувачів
Ведіть інвентар: Ведіть особистий запис відбитків пальців сервера або використовуйте безпечну документацію вашої команди.
Перевірка поза основним каналом: Порівнюйте ключі з надійним джерелом — хмарною консоллю, а не випадковими повідомленнями.
Моніторити Журнали: Регулярно перевіряйте локальні журнали SSH на незвичайні закономірності з'єднань або повторювані помилки.
Використовуйте управління конфігурацією: Керуйте динамічними середовищами розробки за допомогою файлів конфігурації SSH без зниження безпеки.
Для динамічних хмарних середовищ
Використовуйте назви DNS: Підключайтесь через імена хостів замість IP-адрес. Це забезпечує консистентність при змінах базової адреси.
Використовуйте хмарні інструменти: Отримуйте поточні відбитки пальців через консолі провайдера. Перевіряйте ключі за цими інструментами перед прийняттям змін.
Інфраструктура як код: Автоматизуйте перевірку ключів за допомогою інструментів на зразок Terraform. Для складних налаштувань можна також використовувати SSH SOCKS5 проксі.
Хост-бастіони: Налаштуйте jump-сервери зі стабільними ключами. Вони слугують безпечними точками входу до вашої динамічної інфраструктури.
Висновок
Попередження «Warning: Remote Host Identification Has Changed» — це важливий механізм безпеки SSH, а не вада, яку можна ігнорувати. Хоча це попередження часто з'являється з легітимних причин, таких як обслуговування сервера або зміни конфігурації, воно грає ключову роль в захисті від атак «людина посередині» та несанціонованого доступу.
Коли ви бачите це попередження, перевірте причину перед продовженням. У більшості випадків рішення просте: видаліть старий ключ хоста за допомогою методів для вашої операційної системи, потім прийміть новий ключ при наступному підключенні.
Розуміючи, як працюють ключі хостів SSH та дотримуючись найкращих практик, ви зможете забезпечити як безпеку, так і зручність у робочих процесах віддаленого доступу. Більше про безпечне передавання файлів дивіться в копіювання файлів через SSH.
