Намагаючись ввійти в комп’ютер, яким я керую, я отримую знайоме повідомлення:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

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

Але я хотів би, щоб ssh прийняв і старий, і новий ключ. Мова у повідомленні про помилку (" Add correct host key") говорить про те, що повинен бути певний спосіб додати правильний ключ хоста, не видаляючи старий.

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

Це можливо, чи повідомлення про помилку просто вкрай оманливе?

1. отримати ключ rsa вашого сервера, де server_ipзнаходиться IP-адреса вашого сервера, наприклад 192.168.2.1:

   $ ssh-keyscan -t rsa server_ip
   

   Зразок відповіді:

   # server_ip SSH-2.0-OpenSSH_4.3
   server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
   

2. а на клієнті скопіюйте весь рядок відповідей server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...та додайте цей ключ у нижній частині ~/.ssh/known_hostsфайлу:

   server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key, and/or the very bottom of the `known_hosts` file)
   server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG... (line you're adding, copied and pasted from above)
   

Видаліть цей запис із відомих_хостів за допомогою:

ssh-keygen -R *ip_address_or_hostname*

Це видалить проблемний IP-адресу або ім'я хоста з відомого файла_hosts та спробує знову підключитися.

З чоловічої сторінки:

-R hostname
Видаляє всі ключі, що належать імені хоста, з відомого файлу_hosts. Цей параметр корисний для видалення хешованих хостів (див. Опцію -H вище).

Дуже простий спосіб:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

Потім відредагуйте unknown_hosts, щоб очистити вихідний ключ, а потім ssh на хост, використовуючи:

ssh name@computer

Він додасть новий ключ автоматично; потім порівняйте два файли. Така програма, як meld - хороший спосіб порівняння двох файлів. Потім об'єднайте файли, щоб знамениті_хости містили обидва ключа

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

EDIT 2015/06

Я повинен додати, переглядаючи це зараз, що я помічаю ще простіший спосіб [доки запис може бути ідентифікований, як правило, від імені хоста / IP-адреси зовсім осторонь від повідомлення про помилку, що посилається на його конкретне місцезнаходження];

1. Відредагуйте відомі_хости, щоб тимчасово додати # на початку "старого" запису у відомому_хості
2. Підключіть [ssh до хоста], погодьтесь із запитом, щоб додати новий ключ "автоматично"
3. Потім відредагуйте відомі_хости, щоб видалити #

Існує навіть варіант HostKeyAlias ​​як в

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

потім згодом, після того, як ssh-клієнт додасть новий ключ під псевдонімом, ви можете або відредагувати відомі_hosts, щоб замінити 'справжнє' ім’я хоста / IP-адресу на псевдонім, або підключитися до цього втілення цього хоста опцією псевдоніму

У мене ж проблема з малиновим пі, який я завантажую з декількох різних систем (система розробників для складання бінарних файлів, проект, xbmc тощо) і зіткнулася з тією ж проблемою. Вони використовують DHCP в локальній мережі, і мій маршрутизатор завжди використовував один і той же IP, оскільки MAC-адреса була однаковою. Я вирішив це, використовуючи різні доменні імена у моєму файлі хостів:

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 pi-etc

Файл known_hosts зберігає відбитки пальців за назвою хоста, тому навіть якщо це одна і та сама IP-адреса, кожне унікальне ім’я хоста отримує різний запис.

Мені стало нудно додавати імена до файлів хостів щоразу, коли я використовував нову систему, тому я придумав ще більш лазерний спосіб, використовуючи провідні нулі на ip-адресах на зразок:

$ ssh pi@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

Кожна варіація (неканонізованої) ip-адреси отримує власний запис у відомих_хостях.

Якщо у вашого клієнта та сервера є OpenSSH 6.8 або новішої версії, ви можете скористатися цією UpdateHostKeys yesопцією у вашому ssh_configабо ~/.ssh/config. Наприклад:

Host *
    UpdateHostKeys yes

Це змушує SSH зберігати всі хост-ключі, які повинен виконати сервер known_hosts, а коли сервер змінює або видаляє один ключ хоста, ключ також змінюється або видаляється у вашому known_hosts.

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

Іншим рішенням може бути використання StrictHostKeyChecking=noпараметра для цього конкретного хоста:

ssh -o StrictHostKeyChecking=no user@host

який ви можете поставити в псевдонім у вашому ~/.profileчи щось подібне.

alias hc=ssh -o StrictHostKeyChecking=no user@host

Якщо ви лише ssh на локальну мережу, то ...

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

напр

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Потім натисніть пробіл, backspace cntl + x і 'y', щоб зберегти новий буфер (файл). Його погана практика, але добре, якщо ви не регулярно перебуваєте поза локальною мережею (наприклад, універсал або робочий сервер)

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

Завжди краще використовувати код, який ви розумієте!

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

Ось проста методика, яка дозволяє вам залишати сувору перевірку хоста, але оновити ключ контрольованим чином, коли ви очікуєте, що він зміниться:

• Видаліть старий ключ та оновіть в одній команді

  ssh-keygen -R server.example.com && \
      ssh -o StrictHostKeyChecking=no server.example.com echo SSH host key updated.
  

• Якщо ви їх використовуєте, повторіть із IP-адресами або іншими іменами хостів.

Перевага такого підходу полягає в тому, що він рекетує сервер рівно один раз. Більшість версій ssh-keygen, здається, не повертають помилку, якщо сервер, який ви намагаєтеся видалити, не існує у відомому файлі хостів, якщо це проблема для вас, використовуйте дві команди послідовно.

Цей підхід також перевіряє підключення та видає приємне повідомлення для журналів у команді ssh (яка входить у систему, оновлює ключ хоста та виводить ключ хостингу SSH, оновлений та одразу ж виходить.

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

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

У мене була така ж проблема.

Все, що я зробив, було sudo nano /home/user/.ssh/ host_allowі стерти ключ.

Коли я повернувся до сервера, він додав новий ключ.

Використовуйте команду sed, щоб видалити рядок порушень

OUTPUT: as show in above example
Offending key in /home/user/.ssh/known_hosts:86

Видаліть рядок 86, як згадується у відомих хостах.

CODE: 
sed -i '86d' /home/user/.ssh/known_hosts

Наступного разу при доступі за допомогою ssh система автоматично додасть новий ключ.

новіші версії ssh

використання:

ssh-keygen -R <hostname|ip address>

Це видалить запис імені хоста і взяти резервну копію старого , .known_hostякknown_hosts.old