Вопрос Как исправить предупреждение о ключе главного ключа ECDSA


Я пытаюсь настроить SSH без пароля на сервере Ubuntu с ssh-copy-id myuser@myserver, но я получаю сообщение об ошибке:

Предупреждение: ключ хоста ECDSA для «myserver» отличается от ключа для IP-адреса «192.168.1.123»

Что вызывает это, и как его исправить? Я попытался удалить .ssh на удаленном компьютере и ssh-keygen -R "myserver" локально, но это не устраняет ошибку.


210
2018-05-05 19:05


происхождения


в моем случае я изменяю привязку сервера (ip) к домену, затем The ECDSA host key for server has changed, Мой путь - удалить связанную строку кэша о домене в ~/.ssh/known_hosts, Затем работает ssh. - Ninja


ответы:


Удалите кеш-ключ для 192.168.1.123 на локальном компьютере:

ssh-keygen -R 192.168.1.123

300
2018-05-05 20:20



Не работала для меня на новой установке сервера Debian на работе, когда SSHing из дома. Кроме того, ответ довольно короткий. - Chris K
/home/wf/.ssh/known_hosts обновлено. Исходное содержание сохранено как /home/wf/.ssh/known_hosts.old «Предупреждение: Постоянно добавлен ключ хоста ECDSA для IP-адреса« x.x.x.x »в список известных хостов». отображается. и, похоже, это работает - Wolfgang Fahl
Вы можете обновить ключ, а не удалять его. использование ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts после этого вам не нужно проверять новый ключ при первом подключении к хосту. - Alex
Для кого не удается заставить его работать: у меня были зарегистрированные множественные вхождения одного и того же IP: 1 / указанного IP-адреса (xx.xx.xx.xx), домена (tomsihap.fr), предоставленного провайдером vps-сервера адрес (vpsxxx.ovh.net). ssh-keygen -R для каждого из них выполняли работу. - tomsihap
Работала для меня, но может возникнуть путаница, с которой хозяин должен запускать эту команду? Ответ - тот, который показал ошибку. Второй вопрос и ответ более очевидны, но на всякий случай: какой адрес перейти к ssh-keygen -R? Адрес, который фигурирует в инструкции ошибки. - Russ Bateman


В моем случае ssh-keygen -R ... не зафиксировал предупреждение. У меня была дополнительная информация:

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

Я просто отредактировал вручную ~/.ssh/known_hosts и удалил строку 8 («оскорбительный ключ»). Я попытался переподключиться, хозяин был постоянно добавлен, и после этого все было в порядке!


40
2018-03-11 18:52



Это сработало для меня. Благодаря! - Organic Marble
Работает как шарм. Можно исправить это в одной строке с помощью sed -e '8d' /home/myuser/.ssh/known_hosts, заменяя номер строки 8 и имя файла с отображаемыми в вашей системе. - Alex P. Miller


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

Решив эту проблему и не довольный ответами, я хотел действительно узнать «почему» ...

Триггер для моего дела: установленная новая серверная ОС при работе и при установке пакета openssh-server на сервере работы был создан новый набор ключей хоста. Раньше все мои серверные ОС были Ubuntu, и на этот раз он был заменен на Debian (и я подозреваю, что существует тонкая разница в разрешениях).

Когда все ОС были Ubuntu, и я переустанавливаю ОС сервера, при первом 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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Затем я открываю ~ / .ssh / known_hosts на компьютере, инициирующем ssh, удалите эту строку, повторно подключите и это произойдет:

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

Этот бит о: 11122 - номер порта, на который я отправляю SSH с брандмауэра

Я проверил резервные копии с прежнего сервера Ubuntu и отказался от моей новой установки Debian:

Ubuntu:                                            Debian:
# Package generated configuration file             # Package generated configuration file
# See the sshd(8) manpage for details              # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for      # What ports, IPs and protocols we listen for
Port 22                                            Port 22
# Use these options to restrict which interface    # Use these options to restrict which interfaces
#ListenAddress ::                                  #ListenAddress ::
#ListenAddress 0.0.0.0                             #ListenAddress 0.0.0.0
Protocol 2                                         Protocol 2
# HostKeys for protocol version 2                  # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key                  HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key                  HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------   HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security    #Privilege Separation is turned on for security
UsePrivilegeSeparation yes                         UsePrivilegeSeparation yes

Итак, да, вероятно, хозяин недавно начал использовать ecdsa-ключи, основанные на изменениях Ubuntu в последнее время, я бы обвинил в обновлении. Переход Ubuntu в сторону от мощной операционной системы Linux, на которую я рассчитывал, - это то, почему я установил Debian на этот раз.

Я прочитал security.SE q / a на ecdsa и уже удалили эту строку из sshd_config мой новый сервер Debian. (и побежал service ssh restart)


14
2018-01-16 08:12



+1 для красивого параллельного блока сравнения. Не могли бы вы добавить URL clariying «смещение Ubuntu в сторону от рок-твердой операционной системы Linux»? - bgoodr
@bgoodr, это мое мнение и исключительно основано на настройке моего собственного файлового сервера RAID несколько раз за последние несколько лет. : / Дерьмо для ответа, но начинайте искать ubuntu debian server и вы увидите, что я имею в виду. - Chris K
@ChrisK Ты, сэр, босс. Спасибо за подробный, но сжатый ответ. - sargas


ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123

Это должно заменить существующие ключи под именем known_hosts.old и создать новый. Это решение работало для меня в том же сценарии


5
2018-05-14 18:16





Запрос появляется каждый раз, потому что IP-адреса все время меняются при использовании динамической адресации. Попробуйте использовать статический IP-адрес, поэтому вам нужно добавить ключ только один раз.


4
2018-01-16 09:06



Хороший момент, я пропустил, где кто-то упомянул динамические ips? - Chris K


Используете ли вы один и тот же пользователь для подключения?

Если вы вошли в локальный ПК, как пользователь Джон и подключен к серверу В как пользователь Adolf @ B и все в порядке, это не значит, что все в порядке, если вы вошли на локальный ПК, как пользователь Джейн и подключение к серверу В как пользователь Adolf @ B,

Если вы хотите войти на сервер B в качестве пользователя Beda с ПК  без пароля, попробуйте эту команду, все с ПК :

ssh-keygen -t rsa

Эта команда генерирует ключ и сохраняет ключ в файле. Пожалуйста, оставьте ключевая фраза пустой.

ssh Beda@B mkdir -p .ssh

Эта команда создает каталог, если они еще не существуют. В противном случае не печатайте сообщение об ошибке.

cd ~/.ssh

Эта команда изменяет каталог в домашний каталог ваших пользователей ./ssh.

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

Эта команда печатает файл id_rsa.pub (ваш открытый ключ) в authorized_keys на сервере.

ВАЖНО: Beda - это ваше имя пользователя на сервере, с которым вы подключаетесь, B - ваш IP-адрес сервера.

Теперь вы можете подключиться к серверу B без пароля или парольной фразы:

ssh Beda@B

2
2017-10-21 09:17





Нить Вот может помочь.

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


1
2017-12-20 16:47





Вопрос: Что вызывает это, ...?

Таким образом, ключ хоста ssh-сервера изменился. Что вызвало изменение? Сложно сказать. Вот некоторые догадки:

  • Разве sshd на myserver начал использовать ключи ECDSA, так что это новый тип ключа?
  • Обновлен ли myserver недавно?
  • Был ли sshd на myserver недавно повторно заблокирован, поэтому был создан новый ключ хоста ssh?
  • Кто-нибудь заново сгенерировал или заменил ключ хоста sshd?
  • Изменен ли IP-адрес myserver, чтобы другой хост отвечал на этот IP-адрес?

Вопрос: ... и как я могу это исправить?

Как уже ответили другие, удалите кешированный ключ ECDSA для myserver, который был заблокирован вашей учетной записью.


1
2017-08-07 15:42



Хороший совет, но на самом деле не отвечает на вопрос. Даже не пытается ответить на вопрос. - boatcoder


Эта ошибка продолжала раздражать меня в течение длительного времени. По какой-то причине это имело значение, будет ли я делать

ssh host

или

ssh host.domain

https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh

затем указал мне на возможность изменения файла конфигурации. См. Мой сценарий https://askubuntu.com/a/949731/129227 там для автоматизации процесса.


1
2017-08-25 12:43





Я исправил это на Chromebook, удалив и переустановив Secure Shell ... Он работал как шарм.


0
2018-05-18 23:26



Это перебор. См. Более простое решение в моем ответе. - Alex Yursha