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. Измените known_hosts, чтобы временно добавить # в начало 'старой' записи в known_hosts
2. Подключите [ssh к хосту], согласитесь с предложением добавить новый ключ "автоматически"
3. Затем повторно отредактируйте known_hosts, чтобы удалить #

Есть даже вариант HostKeyAlias, как в

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

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

У меня такая же проблема с raspberry pi, которую я загружаю с несколькими разными системами (система разработки для компиляции двоичных файлов руки, проект, 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-адреса получает свою запись в известном_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, похоже, не возвращают ошибку, если сервер, который вы пытаетесь удалить, не существует в файле известных хостов. Если это проблема для вас, используйте две команды последовательно.

Этот подход также проверяет подключение и выдает приятное сообщение для журналов в команде ssh (которая входит в систему, обновляет ключ хоста и выводит Ключ хоста SSH обновлен затем сразу уходит.

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

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

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

Все, что я сделал, было sudo nano /home/user/.ssh/ host_allow и стер ключ.

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

Используйте команду 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