ssh: Неможливо встановити справжність хоста "ім'я хоста"

Коли я ssh на машину, я колись отримую це попередження про помилку, і воно вимагає сказати "так" або "ні". Це спричиняє певні проблеми при запуску із сценаріїв, які автоматично надходять на інші машини.

Попереджувальне повідомлення:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

Чи є спосіб автоматично сказати «так» або проігнорувати це?

Залежно від вашого ssh-клієнта, ви можете встановити параметр StrictHostKeyChecking не в командному рядку та / або надіслати ключ до нульового файла знаних_хостів. Ви також можете встановити ці параметри у своєму конфігураційному файлі для всіх хостів або для заданого набору IP-адрес або імен хостів.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

EDIT

Як зазначає @IanDunn, для цього є ризики для безпеки. Якщо ресурс, до якого ви підключаєтесь, був підроблений зловмисником, він може потенційно відтворити виклик цільового сервера до вас, змусивши вас думати, що ви підключаєтесь до віддаленого ресурсу, а насправді вони підключаються до цього ресурсу з ваші повноваження. Ви повинні уважно розглянути, чи є відповідний ризик, перш ніж змінити механізм підключення, щоб пропустити HostKeyChecking.

Довідково .

Старе питання, яке заслуговує на кращу відповідь.

Ви можете запобігти інтерактивному запиту без відключення StrictHostKeyChecking(що є небезпечним).

Включіть у свій сценарій таку логіку:

if [ -z "$(ssh-keygen -F $IP)" ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

Він перевіряє, чи є відкритий ключ сервера known_hosts. Якщо ні, він запитує відкритий ключ із сервера та додає його до known_hosts.

Таким чином, ви піддаєтеся нападу "Людина в середині" лише один раз, який може бути пом’якшений:

• гарантуючи, що сценарій підключається вперше через захищений канал
• перевірка журналів або знань_хостів для перевірки відбитків пальців вручну (робиться лише один раз)

Щоб вимкнути (або керувати відключенням), додайте наступні рядки до початку /etc/ssh/ssh_config...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

Параметри:

• Підмережа Хост може бути *дозволена необмеженим доступом до всіх IP-адрес.
• Редагування /etc/ssh/ssh_configдля глобальної конфігурації або ~/.ssh/configдля конфігурації користувача.

Дивіться http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

Аналогічне запитання щодо superuser.com - див. Https://superuser.com/a/628801/55163

Переконайтесь, що ~/.ssh/known_hostsце можливо для запису. Це зафіксувало це для мене.

Найкращий спосіб зробити це - використовувати "BatchMode" на додаток до "StrictHostKeyChecking". Таким чином, ваш сценарій прийме нове ім’я хоста і запише його у відомий файл_hosts, але не вимагатиме втручання «так / ні».

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

Відредагуйте свій конфігураційний файл, який зазвичай розташований у "~ / .ssh / config", і на початку файлу додайте рядки нижче

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

Користувач налаштовано, your_login_userщо ці параметри належать вашому_login_user
StrictHostKeyChecking, встановленому таким чином, щоб не уникнути швидкого
IdentityFile - це шлях до ключа RSA

Це працює для мене та моїх сценаріїв, удачі вам.

Це попередження видається через функції безпеки, не відключайте цю функцію.

Він відображається лише один раз.

Якщо воно все ж з’являється після другого підключення, проблема, ймовірно, полягає у написанні у known_hostsфайл. У цьому випадку ви також отримаєте таке повідомлення:

Failed to add the host to the list of known hosts 

Ви можете виправити це, змінивши власника, щоб змінити права доступу до файлу для запису користувачем.

sudo chown -v $USER ~/.ssh/known_hosts

Посилаючись на відповідь Корі, я змінив її і використав команду нижче, яка працює. Без цього exitзалишилася команда насправді входила в систему на віддаленій машині, чого я не хотів у сценарії

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

Зробіть це -> chmod +w ~/.ssh/known_hosts. Це додає дозвіл на запис у файл у ~/.ssh/known_hosts. Після цього віддалений хост буде доданий у known_hostsфайл при наступному підключенні до нього.

В ідеалі вам слід створити авторитетний сертифікатний орган. Почніть з створення пари ключів: ssh-keygen -f cert_signer

Потім підпишіть відкритий ключ хоста кожного сервера: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Це створює підписаний відкритий хост-ключ: /etc/ssh/ssh_host_rsa_key-cert.pub

В /etc/ssh/sshd_config, направте HostCertificateна дане зображення: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Перезапустіть службу sshd: service sshd restart

Потім на клієнті SSH додайте наступне ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Сказане містить:

• @cert-authority
• Домен *.example.com
• Повний вміст відкритого ключа cert_signer.pub

cert_signerВідкритий ключ буде довіряти будь-якого сервера , чий публічний ключ хоста підписується cert_signerзакритим ключем.

Хоча для цього потрібна одноразова конфігурація на стороні клієнта, ви можете довіряти декільком серверам, включаючи ті, які ще не передбачені (якщо ви підписуєте кожен сервер, тобто).

Детальніше дивіться на цій сторінці вікі .

Зазвичай ця проблема виникає, коли ви дуже часто змінюєте клавіші. На основі сервера може знадобитися деякий час, щоб оновити новий ключ, який ви створили та вставили на сервер. Тому після генерації ключа та вставки на сервері почекайте 3 - 4 години, а потім спробуйте. Проблему слід вирішити. Це сталося зі мною.

Додайте їх до / etc / ssh / ssh_config

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Запустіть це на хост-сервері, це проблема передчуття

chmod -R 700 ~/.ssh

Я мав таку ж помилку і хотів звернути увагу на той факт, що - як це зі мною тільки що трапилось - у вас можуть бути просто неправильні привілеї.
Ви створили свій .sshкаталог як звичайний або rootкористувальницький, і тому вам потрібно бути правильним користувачем. Коли з’явилася ця помилка, я був, rootале я налаштований .sshяк звичайний користувач. Вихід rootвиправлений.

Я вирішую проблему, яка подає нижче письмову помилку:
Помилка:
Неможливо встановити справжність хоста 'XXX.XXX.XXX'.
Відбиток ключа RSA - 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Рішення:
1. встановіть будь-який інструмент openSSH.
2. запустити команду ssh
3. вона попросить вас u додати цей хост, як. прийняти ТАК.
4. Цей хост додасть у відомий список хостів.
5. Тепер ви можете з'єднатися з цим хостом.

Це рішення працює зараз ......