Я пытаюсь настроить SSH без пароля на сервере Ubuntu с помощью ssh-copy-id myuser@myserver , но получаю ошибку:
Предупреждение: ключ хоста ECDSA для «myserver» отличается от ключа для IP-адреса «192.168.1.123»
Что вызывает это, и как я могу это исправить? Я попытался удалить .ssh на удаленном компьютере и запустить ssh-keygen -R "myserver" локально, но это не устраняет ошибку.
Удалите кэшированный ключ для 192.168.1.123 на локальном компьютере:
ssh-keygen -R 192.168.1.123
В моем случае 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 ("нарушающий ключ"). Я попытался переподключиться, хозяин был постоянно добавлен, и все было хорошо после этого!
Я провожу много ssh-поиска между моими компьютерами локальной сети и двумя учетными записями веб-хостинга, поэтому я разобрался со всеми видами шансов и заканчивается с помощью 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.
Я прочитал безопасность.SE q/a на ecdsa и уже удалил эту строку из sshd_config моего нового сервера Debian. (и запустил service ssh restart)
ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123
Это должно заменить существующие ключи в known_hosts.old и создать новый. Это решение работало для меня в том же сценарии
Запрос появляется каждый раз, потому что IP-адреса все время меняются при использовании динамической адресации. Попробуйте использовать статический IP-адрес, чтобы добавить ключ только один раз.
Вы используете тот же пользователь для подключения?
Если вы вошли в систему на локальном ПК, таком как пользователь 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
Нить здесь может помочь.
По сути, вы хотите удалить оба ключа RSA и ECDSA для этого хоста, а затем использовать ssh-keyscan чтобы поместить их обратно в файл known_hosts таким образом, чтобы не вызвать этот конфликт. Это сработало для меня, когда у меня была такая же проблема.
Я добавил следующие строки в мой ~/.ssh/config, таким образом отключив строгую проверку хоста для всех адресов .local. (с распределением адресов DHCP, IP-адреса моих локальных машин всегда меняются)
host *.local
StrictHostKeyChecking no
Вы все еще получаете предупреждение, хотя, это хорошо для меня.
Эта ошибка долго меня раздражала. По какой-то причине это имело значение, буду ли я делать
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 там для автоматизации процесса.
Вопрос: что является причиной этого, ...?
Таким образом, ключ хоста сервера ssh изменился. Что вызвало изменение? Трудно сказать. Вот некоторые догадки:
Вопрос: ... и как мне это исправить?
Как уже отвечали другие, удалите кэшированный ключ хоста ECDSA для myserver, который кэшировал ваш аккаунт.
Вот как удалить известный отпечаток хоста (из файла known_hosts ) в ОС Chrome:
Найдите индекс ошибочной записи хоста в выводе ssh при сбое соединения. Например, в строке ниже индекс обидчика равен 7:
Offending ECDSA key in /.ssh/known_hosts:7
Откройте консоль JavaScript (CTRL+Shift+J) окна Secure Shell и введите следующее, заменив INDEX на соответствующее значение (например, 7):
term_.command.removeKnownHostByIndex(INDEX);
Это решение было заимствовано из блога Лео Гагля.
Я исправил это на Chromebook, удалив и переустановив Secure Shell ... Оно работало завораживающе.