В моем случае 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 -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)

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

host *.local
    StrictHostKeyChecking no

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

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

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

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

У меня это происходит из-за чего-то, что я считаю ошибкой более новой версии (OpenSSH_7.9p1и выше) клиентов, когда он пытается узнать более безопасный ключ сервера, где уже известен ключ более старого типа. Затем он представляет это вводящее в заблуждение сообщение!

Я не знаю хорошего решения этой проблемы. Единственное решение, которое я нашел, — это удалить все «хорошие, но старые ключи», чтобы клиент мог заново изучить «новые, более безопасные ключи».ecdsaключи». Итак:

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

           $ sed -i '/ ssh-rsa /d' ~/.ssh/known_hosts
   

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

Редактировать для Windows:

• В винде нетsed, поэтому лучшим решением, вероятно, будет удаление файла с помощью

          del %USERPROFILE%\.ssh\known_hosts`
  

• Предупреждение! При этом теряется защита от MitM до тех пор, пока все ключи не будут переучены.

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

      $ 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-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)? 

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

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

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

      $ sftp -v test@valentin.hilbig.de

показывает:

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

пока

      $ sftp -v test@gcopy.net

показывает:

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

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

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

Я действительно понятия не имею,. Вероятно, это можно исправить только в восходящем направлении.

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

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

      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

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

      ssh-keygen -R valentin.hilbig.de
# Host valentin.hilbig.de found: line 10
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

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

      $ sftp test@valentin.hilbig.de
The authenticity of host 'valentin.hilbig.de (136.243.197.100)' can't be established.
ECDSA key fingerprint is SHA256:tf7lwe10C2p1lK2UG9p//m/4sUBCpX+i9k5Ub63c6Os.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'valentin.hilbig.de' (ECDSA) to the list of known hosts.
Connected to test@valentin.hilbig.de.
sftp> 

$ sftp test@gcopy.net
Connected to test@gcopy.net.
sftp> 

sftp test@136.243.197.100
Connected to test@136.243.197.100.
sftp>

УРА! Проблема наконец-то ушла. Но с несколькими 100 записями в.ssh/known_hosts, это «решение» действительно становится серьезным PITA (и подверженным ошибкам кошмаром безопасности на улице Вязов. YMMV.)

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

Если вы вошли на локальный ПК, например, пользователь 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

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

ssh host

или же

ssh host.domain

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

затем указал мне на возможность изменения файла конфигурации. Смотрите мой скрипт /questions/47232/google-chrome-ne-zapominaet-parol/47235#47235 там для автоматизации процесса.

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

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

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

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

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

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

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

После безуспешной попытки отключить строгий режим мое решение — очиститьknown-hostsфайл. Например,

      echo "" > ~/.ssh/known-hosts && ssh user@host

Затем он автоматически и без ошибок добавит новый ключ. Изменилось ли что-то в хосте с прошлого раза.

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

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

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

Сообщение об ошибке содержало решение, включенное в одну строку, просто запустил его, и оно сработало как часы.

      ssh-keygen -f "/home/mymachine/.ssh/known_hosts" -R "[192.168.200.2]:2222"