Скопіюйте ssh-ключі з одного сервера на інший

У мене є сервер (припускаємо його ip бути abcd), який дозволяє користувачам входити через ssh. Тепер я хочу змінити фізичну машину, зберігаючи ip однаковим. Так що користувач, як цей, досі отримує доступ до нової машини

$ ssh abcd

Проблема полягає в тому, що кожного разу, коли один користувач намагається увійти, вона отримує таку помилку невідповідності ssh-key.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ ПОПЕРЕДЖЕННЯ: ВИДАЛЕНО ІДЕНТИФІКАЦІЯ ВІДМОВИХ ЗМІНИ @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
МОЖЛИВО, щоб хтось робив щось насті!
Хтось міг би підслухати вас прямо зараз (атака "посередник")!
Можливо також, що щойно змінено хост-ключ RSA.
Відбиток для ключа RSA, надісланий віддаленим хостом, є
02: dc: c6: 18: 1b: 34: b7: 1d: fa: 90: ab: e1: 95: 48: 69: 84.
Зверніться до системного адміністратора.
Додайте правильний ключ хоста в /home/user/.ssh/known_hosts, щоб позбутися цього повідомлення.
Ключ порушень у /home/user/.ssh/known_hosts:37
Ключ хоста RSA для випускників змінився, і ви вимагали суворої перевірки.
Помилка перевірки ключа хоста.

Я знаю, що користувач може видалити рядок №37 з файлу ~ / .ssh / known_hosts і наступного разу вона отримає підказку так / ні. Що я хочу, це те, що користувач повинен не знати про всю цю машину заміни і просто отримати запит на пароль.

Як це зробити?

ssh

— Сувік Пал
джерело

Чи знаєте ви, що це призведе до поразки sshєдиного захисту від людини при посередніх атаках і може призвести до того, що ви відправите свій пароль прямо нападнику замість призначеної машини? Якщо ви фактично не знаєте, що ви невразливі до активних атак (наприклад, ви знаходитесь в тій же захищеній внутрішній мережі, що і цільова машина), це руйнує sshмодель безпеки.

— Девід Шварц

Так. Обидва машини знаходяться в одних внутрішніх мережах. Навіть користувачі перебувають у одній внутрішній мережі. З огляду на таку ситуацію, які мої варіанти?

— Сувік Пал

Цього недостатньо. Вони повинні бути в одній безпечній внутрішній мережі. Тобто вони повинні абсолютно 100% довіряти тому, що жоден пристрій не підключений до тієї внутрішньої мережі, яка не є 100% захищеною, і вони повинні 100% довіряти всім, хто має контроль над цими пристроями або може приєднати пристрій до цієї мережі. Іншими словами, майже в будь-якому реалістичному сценарії це погана ідея.

— Девід Шварц

Це абсолютно розумна річ. Я реплікую ключі ssh-сервера на інший сервер для HA, так що при вході я отримую ці помилки. Крім того, я отримую електронне повідомлення про відмову.

— Метт H

Я згоден з Меттом. Якщо ви керуєте обома машинами і, отже, є власником ключів, переміщення хост-ключа з однієї машини на іншу в межах вашого управління НЕ є людиною, що перебуває в середній атаці чи ризику. Якщо користувач, що підключається, довіряє вашому хост-ключу, це не має значення.

— Росс

Відповіді:

Як згадував Ethabell , ви можете скопіювати поточні ключі хоста на новий сервер.

Ви можете знайти свої хост-ключі, відкривши sshd_configфайл (у вікні Ubuntu 12.04 його /etc/ssh/sshd_config). У конфігураційному файлі шукайте HostKeyзаписи. Ці записи підкажуть, де знаходяться файли ключів хоста. Ви повинні мати можливість скопіювати ці файли на новий сервер та оновити новий сервер, sshd_configщоб вказати на скопійовані ключі (або просто перезаписати файли, які вже є на новому сервері).

Крім того, зверніть увагу на цей розділ зі sshd_configсторінки man, зокрема частину про дозволи:

Вказує файл, що містить приватний ключ хоста, який використовується SSH. За замовчуванням /etc/ssh/ssh_host_keyдля протоколу версії 1, і /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_keyі /etc/ssh/ssh_host_rsa_keyдля протоколу версії 2. Зверніть увагу , що SSHD (8) буде відмовитися від використання файлу , якщо це група / всесвітньо доступним. Можна мати кілька файлів ключів хоста. Клавіші "rsa1" використовуються для версії 1, а "dsa", "ecdsa" або "rsa" використовуються для версії 2 протоколу SSH.

— обтяжений
джерело

Якби у вас був оригінальний ключ хосту, ви могли б відновити його, і це зупинить помилку.

Або ви можете вимкнути StrictHostKeyChecking у своєму файлі конфігурації sshd.

... Це, однак, є жахливою, жахливою ідеєю. Якщо є спосіб для запуску ssh-keygen -R server.example.comна клієнтських машинах, це було б найкращим способом - тому що вимкнути перевірку ключів хоста - це сказати: "Ей, атакуй мене". Я хочу бачити невідомість, коли все змінюється, але безпека повинна бути пріоритетом №1 перед затемненням змін.

— Етабел
джерело

Чи можете ви детальніше розповісти, як відновити ключі хоста на новіших машинах?

— Сувік Пал

Ви можете спробувати так

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'cat >> .ssh/authorized_keys && echo "Key copied"'

Зауважте, що якщо папка .ssh вже не існує, вищевказана команда не вдасться. Крім того, може бути краще при створенні файлу встановити мінімально можливий дозвіл (в основному, читати-писати лише для власника). Ось більш вдосконалена команда:

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'umask 0077; mkdir -p .ssh; cat >> .ssh/authorized_keys && echo "Key copied"'

Щоб дізнатися більше про цю проблему, вам доведеться зайти на цей веб-сайт: Помилка зміни ключа хоста SSH

— Говінд Карамта
джерело