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

288

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

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

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

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

Ответы:

417

Удалите кэшированный ключ для 192.168.1.123на локальной машине:

ssh-keygen -R 192.168.1.123
grawity
источник
14
У меня не работало на недавно установленном сервере Debian на работе, когда SSHing входил из дома. Кроме того, ответ довольно лаконичен.
Крис К
/home/wf/.ssh/known_hosts обновлен. Исходное содержимое сохраняется как /home/wf/.ssh/known_hosts.old «Предупреждение. Постоянно добавлен ключ хоста ECDSA для IP-адреса« xxxx »в список известных хостов». отображается. а потом похоже на работу
Вольфганг Фал
13
Вы можете обновить ключ вместо того, чтобы удалить его. Используйте ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hostsпосле этого вам не нужно проверять новый ключ при первом подключении к хосту.
Алекс
2
Для тех, кому не удается заставить его работать: я зарегистрировал несколько вхождений одного и того же IP: 1 / указанный IP-адрес (xx.xx.xx.xx), домен (tomsihap.fr), указанный vps-сервер провайдера адрес (vpsxxx.ovh.net). ssh-keygen -R для каждого из них сделал свою работу.
Томсихап
Сработало для меня, но путаница может быть с какого хоста должна запускаться эта команда? Ответ от того, который показал ошибку. Второй вопрос и ответ более очевидны, но на всякий случай: какой адрес передать ssh-keygen -R? Адрес, указанный в сообщении об ошибке.
Расс Бейтман
63

В моем случае 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 («оскорбляющий ключ»). Я попытался переподключиться, хозяин был постоянно добавлен, и все было хорошо после этого!

aardvarkk
источник
2
Работает как шарм. Можно исправить это в одной строке sed -e '8d' /home/myuser/.ssh/known_hosts, заменив номер строки 8и имя файла теми, которые отображаются в вашей системе.
Алекс П. Миллер
Моя проблема с этим подходом состояла в том, что это немного сбивает с толку, если known_hosts:8ссылка ссылается на значение с нулевым индексом или нет. Хорошо знать, что это отображение 1: 1 ...
Даниэль Ф
Я заметил, что это происходит, если вы используете нестандартный порт, такой как 2022. В этом случае вам нужно сделатьssh-keygen -R [hostname]:2022
Александр Малфей
Если я удаляю ~/.ssh/known_hosts, я получаю сообщение о том, что подлинность не может быть установлена, и «Вы уверены, что хотите продолжить подключение». Ответ "да" пытается и не удается подключиться. Если я пытаюсь подключиться второй раз, я получаю ту же ошибку ключа хоста ECDSA, с которой я начал.
Аарон Франке
19

Я много общаюсь между моими компьютерами в локальной сети и двумя учетными записями веб-хостинга, поэтому я разобрался со всеми видами шансов и заканчивается с помощью 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)

Крис К
источник
2
+1 за хороший блок сравнения. Не могли бы вы добавить URL-адрес, означающий «Отказ Ubuntu от отличной ОС Linux»?
bgoodr
@bgoodr, на мой взгляд, основано исключительно на настройке моего собственного файлового сервера RAID несколько раз за последние несколько лет. : / Дерьмо за ответ, но начните гуглить, ubuntu debian serverи вы поймете, что я имею в виду.
Крис К
1
@ChrisK Вы, сэр, босс. Спасибо за подробный, но краткий ответ.
Саргас
6

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

Гаурав Иосиф
источник
1
Хороший вопрос, я пропустил, где кто-то упоминал динамические IPS?
Крис К
6

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

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

Джинеш Равал
источник
3

Я добавил следующие строки в мой ~ / .ssh / config, таким образом отключив строгую проверку хоста для всех адресов .local. (с распределением адресов DHCP, IP-адреса моих локальных машин всегда меняются)

host *.local
    StrictHostKeyChecking no

Вы все еще получаете предупреждение, хотя, это хорошо для меня.

KimSJ
источник
2

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

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

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

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 (ваш открытый ключ) в авторизованные ключи на сервере.

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

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

ssh Beda@B
Петр Дериан
источник
1
Или просто используйте ssh-copy-id, чтобы заполнить файл author_keys ключом id_rsa.pub без лишних хлопот.
BlakBat
1

Нить здесь может помочь.

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

Пол А Юнгвирт
источник
1

Вопрос: что является причиной этого, ...?

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

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

Вопрос: ... и как мне это исправить?

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

Ларс Нордин
источник
2
Хороший совет, но на самом деле не отвечает на вопрос. Даже не пытался ответить на вопрос.
кодек
1

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

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
Использование значений конфигурации CanonicalizeHostnameи CanonicalDomainsпозволит избежать удалений строгой проверки и сделаю SSH рассмотреть хост и host.domain быть одинаковыми.
BlakBat
0

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

msersen
источник
Это излишне. Смотрите более простое решение в моем ответе здесь.
Алекс Юрша
0

Вот как удалить известный отпечаток хоста (из known_hostsфайла) в Chrome OS:

Найдите индекс ошибочной записи хоста в выводе ssh при сбое соединения. Например, в строке ниже обидного индекса 7 :

Offending ECDSA key in /.ssh/known_hosts:7

Откройте консоль JavaScript ( CTRL+ Shift+ J) окна Secure Shell и введите следующее, заменив INDEXего соответствующим значением (например, 7 ):

term_.command.removeKnownHostByIndex(INDEX);

Это решение было заимствовано из блога Лео Гагля .

Алекс Юрша
источник