Пытаясь подключиться к компьютеру, которым я управляю, я получаю знакомое сообщение:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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)
   

Удалите эту запись из known_hosts, используя:

ssh-keygen -R *ip_address_or_hostname*

Это удалит проблемный IP-адрес или имя хоста из файла known_hosts и попытается подключиться снова.

Из справочных страниц:

-R hostname
Удаляет все ключи, принадлежащие имени хоста, из файла known_hosts. Эта опция полезна для удаления хэшированных хостов (см. Опцию -H выше).

Очень простой способ:

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

Затем отредактируйте known_hosts, чтобы очистить исходный ключ, затем выполните ssh для хоста, используя:

ssh name@computer

Это добавит новый ключ автоматически; затем сравните два файла. Такая программа, как meld, - хороший способ сравнить два файла. Затем объедините файлы, чтобы в known_hosts содержались оба ключа.

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

РЕДАКТИРОВАТЬ 2015/06

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

1. Отредактируйте известные_хосты так, чтобы временно добавить # в начале «старой» записи в известных_хостах
2. Подключите [ssh к хосту], согласитесь на приглашение для добавления нового ключа «автоматически»
3. Затем заново отредактируйте known_hosts, чтобы удалить #

Есть даже опция HostKeyAlias, как в

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

затем, после того, как клиент ssh добавит новый ключ под псевдонимом, вы можете либо отредактировать known_hosts, чтобы заменить псевдоним «реальным» именем хоста / IP-адресом, либо подключиться к этому воплощению этого хоста с опцией псевдонима

У меня та же проблема с raspberry pi, который я загружаю с нескольких разных систем (система разработки для компиляции исполняемых файлов arm, project, xbmc и т. Д.) И столкнулся с той же проблемой. Они используют DHCP в локальной сети, и мой маршрутизатор всегда использовал один и тот же IP-адрес, поскольку MAC-адрес был одинаковым. Я решил это, используя разные доменные имена в моем файле hosts:

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-адреса получает свою собственную запись в known_hosts.

Если ваш клиент и сервер имеют 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'ы за пределами вашей локальной сети (например, универа или рабочего сервера).

В безопасной локальной сети это безопасно, потому что вы просто не можете получить человека в середине атаки.

Всегда лучше использовать код, который вы понимаете!

Так много ответов, но так много, которые отказываются от защиты, полностью отключая строгую проверку хоста, или уничтожая несвязанную информацию о хосте, или просто принуждают пользователя интерактивно принимать ключи, возможно, на более позднем этапе, когда это неожиданно.

Вот простой метод, позволяющий оставить строгую проверку хоста, но обновлять ключ контролируемым образом, когда вы ожидаете, что он изменится:

• Удалите старый ключ и обновите его одной командой

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

• Повторите с IP-адресом (ами) или другими именами хостов, если вы их используете.

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

Этот подход также проверяет подключение и выдает хорошее сообщение для журналов в команде 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