Вопрос: «Добавить правильный ключ хоста в known_hosts» / несколько ключей хоста ssh для имени хоста?


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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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") предполагает, что должен быть какой-то способ добавить правильный ключ хоста, не удаляя старый.

Я не смог понять, как добавить новый ключ хоста, не удаляя старый.

Возможно ли это, или сообщение об ошибке просто крайне вводит в заблуждение?


119
2017-10-13 14:01


Источник


Это ключ хоста, который генерирует ошибку. Хост должен иметь один и только один ключ. Это не имеет ничего общего с клиентскими или пользовательскими ключами. У вас есть один IP-адрес, который плавает между отдельными хостами или чем-то еще? - David Schwartz
В моем случае я знаю, что в ближайшем будущем я буду переключаться между двумя клавишами во время игры с некоторыми вещами. Похоже, что это также было бы полезно в одном IP-адресе с несколькими ситуациями, которые вы предлагаете. В основном я просто хочу знать, возможно ли это для моего собственного образования, кроме какого-либо конкретного практического применения. - Samuel Edwin Ward


Ответы:


  1. получите ключ rsa вашего сервера:

    $ ssh-keyscan -t rsa server_ip
    # server_ip SSH-2.0-OpenSSH_4.3
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    
  2. и на клиенте добавьте этот ключ в ~/.ssh/known_hosts:

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key)
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    

124
2017-10-13 14:38



Это сработало! Тем не менее, я использую «HashKnownHosts», поэтому запись выглядела немного неуместно. К счастью, ssh_config (5) указал мне на ssh-keygen (1), в котором объяснялось, что я могу использовать «ssh-keygen -H» для хеширования нечётных записей. Спасибо! - Samuel Edwin Ward
Это «работает», но вы не проверяете ключ, поэтому вы уязвимы для мит-атак ... - JasperWallace
@JasperWallace, если первый шаг выполняется через безопасное соединение (например, с помощью localhost), он должен быть довольно безопасным, я думаю - ony
Есть ли способ собрать все типы ключей с сервера? Иногда вы не знаете, являются ли они RSA, DSA, ECDSA, RSA1 ... и т. Д. - Sopalajo de Arrierez
@SopalajodeArrierez же manpage также говорит, что вы можете разделить типы запятыми, так что ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip - но единственная причина, чтобы найти rsa1а также dsa ключи - определить серверы, которые необходимо обновить / переконфигурировать - kbolino


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

ssh-keygen -R *ip_address_or_hostname*

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

С man-страниц:

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


68
2018-02-09 06:49



«как добавить новый ключ хоста, не удаляя старый». - Samuel Edwin Ward
Это лучшее решение! - Thomas Decaux
Как у этого есть 19 голосов? Он не приближается к ответу на заданный вопрос. - Molomby
Ваш вопрос приходит второй, когда я google для «git ssh update host key автоматически». Этот ответ - то, что я искал. Открытие нового вопроса именно тем, что я хочу, может быть закрыто как дубликат. - Jason Goemaat
Хост-имя работает тоже - damluar


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

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

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

ssh name@computer

Он автоматически добавит новый ключ; затем сравните два файла. Программа, такая как meld, является хорошим способом сравнения двух файлов. Затем объедините файлы, чтобы make 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-адрес для псевдонима или подключиться к этому воплощению этого хоста с опцией alias evermore


15
2018-04-30 22:29



Это 'meld'? meldmerge.org - Samuel Edwin Ward
это meld :) apt-get / yum install name просто meld - Mark
Я сделал вариант вашего предложения, который работал хорошо - вместо cp, mv, затем ssh, затем cat ~ / .ssh / known_hosts.bak ~ / .ssh / known_hosts> tmp; mv tmp ~ / .ssh / known_hosts - Peter N Lewis


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

Мне было больно добавлять имена в файлы hosts каждый раз, когда я использовал новую систему, поэтому я придумал еще более ленивый способ, используя ведущие нули на IP-адресах, например:

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

Каждый вариант (неканонизированный) ip-адрес получает свою собственную запись в known_hosts.


7
2017-11-04 02:28



Люди OpenSSH получили мудрый для меня, эта лазейка больше не работает в более поздних версиях. - Mike
Вы можете использовать CheckHostIP no в ~/.ssh/config чтобы иметь возможность использовать лазейку. Вы даже можете определить свои псевдонимы, чтобы вам не приходилось возиться с /etc/hosts и определить CheckHostIP no только для этих 3 имен хостов. - GnP


Если у вашего клиента и сервера есть OpenSSH 6.8 или новее, вы можете использовать UpdateHostKeys yes в вашем ssh_config или ~/.ssh/config, Например:

Host *
    UpdateHostKeys yes

Это делает SSH хранить все ключи хоста, которые сервер должен known_hosts, и когда сервер изменяет или удаляет один ключ хоста, ключ также изменяется или удаляется в вашем known_hosts,


2
2017-09-22 04:28



Это, безусловно, самый полезный ответ! Хотя он явно не предлагает способ решить исходный вопрос, если ключ хоста уже был изменен, все остальные ответы небезопасны, поскольку они не проверяют новый ключ хоста. Эта опция позволяет вам защищать опрокидывание до новых ключей хоста. - Jaap Eldering


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

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

ssh -o StrictHostKeyChecking=no user@host

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

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

1
2017-10-13 14:49



StrictHostKeyChecking, похоже, не помогает в этом случае; по-видимому, он определяет только поведение, когда хост не находится в файле known_hosts. Упоминается здесь: gossamer-threads.com/lists/openssh/dev/45349#45349 - Samuel Edwin Ward
Он работает здесь. Вы получите предупреждение, но логин продолжается. - Sven♦
Странно. Используете ли вы аутентификацию по паролю? Вы используете OpenSSH? - Samuel Edwin Ward


если ты только ssh в локальной сети, тогда ...

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

например

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

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

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

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


0
2018-06-15 21:44



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