R

В моем случае 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 строку (“offending key”). Я попробовал переподключиться, хост был добавлен навсегда, и после этого все было в порядке!

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

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

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

ssh-keygen -f “/root/.ssh/known_hosts” -R 192.168.1.123

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

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

host *.local
    StrictHostKeyChecking no

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

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

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

Если вы хотите войти на сервере B в качестве пользователя Beda с PC A без пароля, попробуйте эту команду, все с PC 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 (ваш публичный ключ) в authorized_keys на сервере.

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

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

ssh Beda@B
```.

Вопрос: Что вызвало это, …?

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

• Был ли sshd на myserver начал использовать ECDSA ключи, так что это новый тип ключа?

• Был ли myserver недавно переустановлен?

• Был ли sshd на myserver недавно переустановлен, так что был сгенерирован новый ключ хоста ssh?

• Был ли кто-то повторно сгенерирован или заменен ключ хоста sshd?

• Был ли изменен IP-адрес myserver так, чтобы другой хост отвечал на этот IP-адрес?

Вопрос: … и как это исправить?

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

Поток здесь может помочь.

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

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

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 для автоматизации процесса.

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

На моей стороне это происходит из-за того, что я считаю ошибкой ssh более новых (OpenSSH_7.9p1 и выше) клиентов, когда он пытается узнать более безопасный ключ сервера ecdsa, где уже известен более старый ключ типа rsa. Я не знаю, как это исправить, единственное решение, которое я нашел - это удалить все “хорошие, но старые ключи rsa”, чтобы клиент мог заново выучить “новые, более безопасные ключи ecdsa”. Итак:

1. Первый шаг состоит в том, чтобы удалить все старые добрые ключи RSA ( Предупреждение! Это теряет защиту от MitM):

2. Второй шаг - это переучивание всех ключей хоста, что нужно сделать вручную, подключившись к каждому IP снова, используя ssh.

• *

Вот что я наблюдаю:

$ sftp test@136.243.197.100
Connected to test@136.243.197.100
sftp> 

$ sftp test@valentin.hilbig.de
Connected to test@valentin.hilbig.de.
sftp>

Теперь попробуйте подключиться к вновь введенному псевдониму этого же уже известного хорошего сервера:

$ sftp test@gcopy.net
Warning: the ECDSA host key for 'gcopy.net' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:44
Are you sure you want to continue connecting (yes/no)?

Пожалуйста, посмотрите на IP-адрес. Это тот же самый IP, что и выше! Похоже, что (хороший) ключ (известного) IP внезапно себя оскорбляет (это не так, так как клиент ssh смешивает два несовместимых ключа, см. ниже).

Теперь мы пытаемся это исправить:

$ ssh-keygen -R 136.243.197.100
# Host 136.243.197.100 found: line 45
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

Попробуем еще раз:

$ sftp test@gcopy.net
Warning: Permanently added the ECDSA host key for IP address '136.243.197.100' to the list of known hosts.
Connected to test@gcopy.net.

$ sftp test@valentin.hilbig.de
Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10
Are you sure you want to continue connecting (yes/no)?

WTF? Что здесь произошло? Новый свежий ключ, извлеченный из сервера, снова не работает? И проблема даже поменялась сторонами?!?

Нет, это не ключ, ни сервер. Все верно!

Это клиент ssh, который не может проверить правильность ключа! Теперь ввод 45 в known_hosts содержит ключ типа ecdsa-sha2-nistp256, в то время как ключ, который был извлечен клиентом из сервера, имеет тип rsa-sha2-512 (и поэтому не может совпадать с другим ключом!).

$ sftp -v test@valentin.hilbig.de

показывает:

показывает:

debug1: kex: host key algorithm: rsa-sha2-512

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

Как исправить?

Понятия не имею. Наверное, это можно исправить только вверх по течению.

Но есть ручной, но неуклюжий обходной путь:

Нужно вручную удалить все следы старого ключа типа rsa. Ключ в вопросе отображается в выводе, но он не отмечен непосредственно как проблема:

$ sftp -v test@gcopy.net

проверить:

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

дает

Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10

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

awk 'NR==45 { print $2 }' /home/test/.ssh/known_hosts
awk 'NR==10 { print $2 }' /home/test/.ssh/known_hosts

Теперь проверьте еще раз:

ecdsa-sha2-nistp256
ssh-rsa

YAY! Проблема наконец-то ушла. Но с несколькими 100 записями в .ssh/known_hosts, это “решение” действительно становится основным PITA (и Error Prone Security Nightmare на Elm Street. YMMV.).

Вот как удалить известный отпечаток пальца хоста (из файла 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);

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