如何修复有关ECDSA主机密钥的警告

#1 楼

删除本地计算机上192.168.1.123的缓存密钥：

ssh-keygen -R 192.168.1.123

#2 楼

就我而言，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行（“违规键”）。我尝试重新连接，将主机永久添加，之后一切正常！

#3 楼

我在局域网计算机和两个Web托管帐户之间进行了很多切换，因此我使用SSH进行了各种处理，包括使用ssh -v的身份验证问题，以了解问题出在哪里和出了什么问题。

刚刚解决了这个问题并且对答案不满意，我想真正地了解自己的“为什么” ...

我的案例的触发因素是：在工作时安装了新的服务器操作系统在安装openssh-server软件包后，在工作服务器上生成了一组新的主机密钥。以前，我所有的服务器操作系统都是Ubuntu，但这次更改为Debian（我怀疑权限存在细微差别）。

当所有操作系统都是Ubuntu时，我重新安装了服务器的OS第一次使用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的原因。

我在ecdsa上阅读了security.SE q / a，并且已经从sshd_config我的新Debian服务器上删除了该行。 （并运行service ssh restart）

#4 楼

每次都会出现该提示，因为使用动态寻址时IP地址始终会更改。尝试使用静态IP，这样您只需添加一次密钥即可。

#5 楼

我在〜/ .ssh / config中添加了以下几行，从而禁用了对所有.local地址的严格主机检查。 （使用DHCP地址分配后，本地计算机的ip地址始终在变化）。

host *.local
    StrictHostKeyChecking no

您仍然会收到警告，但这对我来说很好。 >

#6 楼

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

这将替换known_hosts.old下的现有密钥并创建一个新密钥。
此解决方案有效在相同的情况下对我来说

#7 楼

您使用的是同一用户进行连接吗？

如果您登录到本地计算机（例如John用户）并连接到服务器B（例如Adolf @ B用户）并且一切正常，这并不意味着一切都正确如果您以Jane用户身份登录到本地PC并以Adolf @ B用户身份连接到服务器B，就可以了。

如果要从PC A以用户Beda的身份登录服务器B而没有密码，请尝试此命令全部来自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

#8 楼

本质上，您想要删除该主机的RSA和ECDSA密钥，然后使用ssh-keyscan将它们放回known_hosts文件中，而不会导致这种情况。冲突。当我遇到相同的问题时，它对我有用。

#9 楼

问题：是什么原因造成的……？

因此ssh服务器主机密钥已更改。
是什么引起了变化？
很难说。
这里有一些猜测：


myserver上的sshd是否开始使用ECDSA密钥，因此它是新的密钥类型？
最近是否重新安装了myserver？
最近是否重新安装了myserver上的sshd，从而生成了新的ssh主机密钥？
有人重新生成或替换了sshd主机密钥吗？
myserver的IP地址是否已更改，因此

问题：...以及如何解决它？

其他人已经回答了，请删除缓存的ECDSA主机密钥您的帐户已缓存的myserver。

#10 楼

这个错误使我很烦了很长时间。由于某些原因，我是否要执行

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，以实现流程自动化。

#11 楼

我通过卸载并重新安装Secure Shell在Chromebook上解决了此问题。

#12 楼

以下是在Chrome操作系统上删除已知主机指纹（从known_hosts文件）的方法：

连接失败时，在ssh输出中查找有问题的主机条​​目的索引。例如，在下面的行中，有问题的索引为7：

Offending ECDSA key in /.ssh/known_hosts:7

打开Secure Shell窗口的JavaScript控制台（CTRL + Shift + J）并键入以下内容，替换为INDEX具有适当的值（例如7）：

term_.command.removeKnownHostByIndex(INDEX);

此解决方案是从Leo Gaggl的博客中借用的。

#13 楼

在我这方面，发生这种情况的原因是我认为是较新的ssh和更高版本客户端的OpenSSH_7.9p1错误，当它尝试学习更安全的ecdsa服务器密钥时，已经知道较旧的rsa类型密钥。然后，它会显示此误导性消息！
对此我不知道有什么好的解决办法，我发现的唯一解决方法是删除所有“好的但旧的rsa密钥”，以便客户端可以重新学习“新的更安全” ecdsa键”。因此：


第一步是删除所有旧的RSA密钥（警告！这会失去针对MitM的保护）：

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

然后，第二步是重新学习所有主机密钥，必须通过使用ssh再次连接到每个IP手动完成。


为Windows编辑：


在Windows上没有sed，因此最好的解决方法可能是使用

del %USERPROFILE%\.ssh\known_hosts`

删除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> 

请查看IP地址。与上面相同的IP！因此，看起来（已知）IP的（好）密钥突然冒犯了自己（不是，因为ssh客户端混合了两个不兼容的密钥，请参见下文）。
现在我们尝试修复它：

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

让我们再试一次：

$ 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

WTF？发生了什么事？
从服务器学到的新的新密钥再次失败了？
问题甚至切换了？！？

不是，不是密钥，也不是服务器。一切都正确！
是ssh客户端无法验证正确的密钥！
现在，45中的条目known_hosts带有ecdsa-sha2-nistp256类型的密钥，而从客户端从服务器拉出的密钥是rsa-sha2-512类型（因此无法与其他密钥匹配！）。

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

显示：

$ sftp -v test@valentin.hilbig.de

而

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

显示：应对存在多个变体的主机密钥！
或者落入陷阱以请求过时的密钥变体。

如何解决？
我真的有不知道。这可能只能在上游修复。
但是有一个手动但笨拙的解决方法：
您必须手动删除ssh类型的旧密钥的所有痕迹。有问题的密钥显示在输出中，但没有直接标记为问题：

$ 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  }' /home/test/.ssh/known_hosts
awk 'NR==10 { print  }' /home/test/.ssh/known_hosts

现在再次检查：

ecdsa-sha2-nistp256
ssh-rsa

是的！问题终于消失了。但是在rsa中有几百个条目，此“解决方案”实际上成为了主要的PITA（以及Elm街上容易出错的安全梦Night。）。