Удалите эту запись из 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 в локальной сети, то...

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

например

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Затем нажмите пробел, backspace cntl+x и 'y', чтобы сохранить новый буфер (файл). Это плохая практика, но все в порядке, если вы не регулярно используете ssh'ы за пределами вашей локальной сети (например, универа или рабочего сервера).

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

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

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

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

ssh -o StrictHostKeyChecking=no user@host

который вы могли бы поместить в псевдоним в вашем ~/.profile или что-то подобное.

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

Вам нужно удалить старый ключ с клиентского сервера

ssh-keygen -R 192.168.0.25 #1st remove on client server

затем повторно сгенерируйте ключ

ssh -o HostKeyAlias=192.168.0.25 root@192.168.0.25 #on client server

проверьте, есть ли новая строка

nano ~/.ssh/known_hosts

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

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

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

  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