Тимчасово ігнорувати мій файл ~ ~ / .ssh / known_hosts`?


48

Чи є спосіб тимчасово проігнорувати мій ~/.ssh/known_hostsфайл?

mbp:~ alexus$ ssh 10.52.11.171
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Please contact your system administrator.
Add correct host key in /Users/alexus/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/alexus/.ssh/known_hosts:155
RSA host key for 10.52.11.171 has changed and you have requested strict checking.
Host key verification failed.
mbp:~ alexus$ 

ПРИМІТКА:

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


9
Ви ставите неправильне запитання. Ви не повинні «ігнорувати» проблему; ви повинні з'ясувати, що відбувається, і вирішити це.
Майкл Хемптон

9
Я не можу говорити за користувача, але одним із прикладів може стати ситуація, коли ви розробляєте автоматизований процес встановлення (наприклад, ударний старт), коли ваш ітеративний робочий процес включає будівництво, підключення, тестування, модифікацію процесу збирання та відновлення з дряпатися знову і знову.
Голадус

10
@MichaelHampton - я отримую це постійно, оскільки VMware і VirtualBox переробляють IP-адреси для гостей. Для мене це правильне питання :)

1
FWIW Я продовжую шукати цю відповідь, тому що у мене в системі локальна мережа, де я використовую дробей (з іншим хост-ключем) для введення пароля шифрування диска під час запуску.
Зулан

1
@jww Це неправильне питання / рішення для вашого сценарію. Натомість вам слід налаштувати SSH для ігнорування IP-адреси, але все-таки перевірити ключ хоста. Дивіться, наприклад, тут
Джон Бентлі

Відповіді:


56

Ви можете ssh -o StrictHostKeyChecking=noвимкнути перевірку на known_hostsмить. Але я б радив проти цього. Ви дійсно повинні перевірити, чому ключ хоста змінився.

Інший варіант - додати певний запис до вашого ~/.ssh/configхоста. Це може бути правильним підходом, якщо у вас є певний хост, який генерує нові хост-ключі щоразу, коли він перезавантажується, і він перезавантажується з поважної причини кілька разів на день.

Host <your problematic host>
  StrictHostKeyChecking no

це очікувана поведінка), тож це нормально (в моєму випадку)
alexus

1
@alexus Якщо це "очікувано", ви можете застосувати параметр до конкретного імені хоста / IP, для якого ви очікуєте, що це станеться.
chrylis -на страйк-

1
@alexus І пам'ятайте, що якщо ви це зробите, ви майже втратите весь захист, який забезпечує ssh. Можливо, ви також будете користуватися telnet, оскільки це було б банально, щоб хтось MITM вас і захоплював увесь ваш трафік.
Майкл Хемптон

1
Це більше не працює (принаймні для OpenSSH_5.3p1)
draeath

-o StrictHostKeyChecking=noвидаляє можливість входу за допомогою пароля. Хіба відсутність прапора для цього прямо не суперечить принципам Unix, що дозволяють користувачеві змусити поведінку? Зараз я намагаюся увійти на локальну машину з локальним IP-адресою. Ключ хоста змінився, оскільки я переформатував зазначену машину. Тут все має сенс, і ніщо не є ризиком для безпеки за обставин.
Wowfunhappy

31

Щоб повністю ігнорувати відомий файл хостів у середовищі POSIX, встановіть параметри GlobalKnownHostsFileта UserKnownHostsFileпараметри /dev/null:

ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null user@host

Якщо встановити цей StrictHostKeyChecking=noпараметр, ви зможете підключитися, але SSH все одно покаже попередження :

ssh -o StrictHostKeyChecking=no user@host

Як зазначали інші, можливо, краще вирішити основне питання. Ви можете розглянути можливість автентифікації SSH сертифікатів, наприклад, для перевірки хостів.


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

Я трохи збентежений тут: чи не ви повинні також використовувати -o StrictHostKeyChecking=no на додаток до в -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/nullваріантах - для остаточної відповіді: ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host?
Габріель Степлес

Пов’язане записування я знайшов в Інтернеті: shellhacks.com/disable-ssh-host-key-checking
Габріель

5

Якщо ви перевстановили сервер і, отже, ідентифікатор змінився, вам слід просто видалити вказаний рядок 155 /Users/alexus/.ssh/known_hostsі продовжити.

Якщо ви переключаєтесь між різними приватними мережами, вам слід використовувати замість імен хостів, щоб замість цього підключитися, оскільки ssh-клієнт також зберігатиме ключі залежно від імені хоста. Додайте щось подібне до свого /etc/hosts:

10.52.11.171 server1
10.52.11.171 server2

а потім використовувати ssh server1при підключенні до підмережі 1 та ssh server2підключенні до підмережі2. Таким чином, обидва сервери можуть мати різні хост-ключі.


Що робити, якщо ви переключитесь між двома приватними мережами та підключитесь до двох однакових IP-адрес?
alexus

1
Я відредагував свою відповідь.
етагенкло

2
@alexus Тоді вам потрібен IPv6 :) Але це була б корисна інформація у вашому оригінальному запитанні.
Майкл Хемптон

2

-o StrictHostKeyChecking=no працює, лише якщо хост ще не присутній у файлі знаних_хостів.

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

# Handle possible SSH key changes
host_key=$(ssh-keyscan -t rsa ${host_ip})
grep "${host_key}" ~/.ssh/known_hosts >/dev/null || {
    ssh-keygen -R ${host_ip}
    echo ${host_key} >>  ~/.ssh/known_hosts
}

# connect as normal way
ssh root@${host_ip} "hostname"

2

Деякі люди кажуть, що це не правильно, ви не робите це і так далі, але мені це потрібно ще раз, щоб перевірити пару вбудованих пристроїв. Вам потрібно відключити StrictHostKeyChecking=no, це правильно, але також скинути відомий файл хостів у /dev/null. Ось приклад з автологіном та psна віддаленому пристрої.

sshpass -p pass ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host 'ps ax'

-2

Увійдіть на всі свої сервери (і якщо RedHat), rm -f /etc/ssh/ssh_host_*а потім перезапустіть SSHD.

Це створить нові хост-ключі SSH, які не потрібно ігнорувати.

Я можу придумати лише один екземпляр, коли ключі SSH, клоновані на декількох серверах, не тільки бажані, але й не кидають жодних попереджень. Множини одного запису A. Усі хости із записом A мають однаковий ключ.


6
Ця відповідь невірна. Відбиток пальців місцевий для клієнта.
89c3b1b8-b1ae-11e6-b842-48d705
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.