我试图用ssh-copy-id myuser@myserver在Ubuntu服务器上设置无密码SSH，但我得到的错误是：
警告：'myserver'的ECDSA主机密钥与IP地址'192.168.1.123'的密钥不同
是什么原因造成的，我该如何修复？我试过删除远程机器上的.ssh目录，然后在本地运行ssh-keygen -R "myserver"，但这并不能解决这个错误。
我在我的局域网电脑和我的两个webhosting账户之间做了很多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，删除这一行，重新连接，就会出现这样的情况：
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:
# 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最近的变化，我认为这应该归咎于更新。我读了一个security.SE关于ecdsa的q/a，我已经从sshd_config我的新的Debian服务器中删除了这一行。(并运行了service ssh restart)
每次都会出现提示，因为在使用动态寻址时，IP地址会一直变化。尽量使用静态IP，这样你只需要添加一次密钥就可以了。
ssh-keygen -f “/root/.ssh/known/hosts” -R 192.168.1.123
这应该会替换掉现有的know/hosts.old下的密钥，然后创建一个新的密钥。在同样的情况下，这个解决方案对我来说是有效的。
你是用同一个用户连接吗？
如果你像用户John一样登录到本地电脑，然后像用户Adolf@B一样连接到服务器B，一切正常，但不代表一切正常，如果你像用户Jane一样登录到本地电脑，然后像用户Adolf@B一样连接到服务器B，一切正常。
如果你想以用户Beda的身份从PC A登录服务器B，不需要密码，可以试试这个命令，全部从PC A登录：
ssh-keygen -t rsa
这个命令会生成密钥，并将密钥存储在文件中。
ssh Beda@B mkdir -p .ssh
cd ~/.ssh
这条命令会创建一个目录，如果它们不存在的话，请留下passphrase。
cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'
ssh Beda@B
&001
这条命令将目录改为用户的主目录./ssh。 pub(你的公钥)到服务器上的authorized\keys**。 重要的是：Beda是你要连接的服务器上的用户名，B是你的服务器IP。
问题：………..我该如何修复？
正如其他人已经回答的那样，删除myserver的缓存ECDSA主机密钥，你的账户已经缓存了。
从本质上来说，你想把主机的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 那里的自动化过程。
在我这边，这种情况的发生是由于我认为较新的（ssh及以上的）客户端的一个OpenSSH_7.9p1 bug，当它试图学习一个更安全的ecdsa服务器密钥时，而此时已经有一个旧的rsa类型的密钥。我不知道有什么好的解决办法，唯一的解决办法是删除所有 “好的但旧的rsa密钥"，这样客户端可以重新学习 "新的更安全的ecdsa密钥"。所以：
第一步是删除所有好的旧的RSA密钥（警告！这将失去对MitM的保护）：
第二步是重新学习所有的主机密钥，这必须通过使用ssh手动连接到每个IP上。它和上面的IP是一样的! 所以看起来这个（已知）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>
WTF? 这里发生了什么事？从服务器上新学的新鲜密钥又失败了？而且问题竟然换了个地方！
不对，不是密钥的问题，也不是服务器的问题。一切都是正确的！
是ssh客户端无法验证正确的密钥 它无法处理一个主机密钥存在于多个变体中的问题!
我真的不知道。这可能只能在上游修复。
但有一个手动但笨拙的解决方法：
你必须手动删除所有旧的45类型的密钥的痕迹。 所以让我们删除错误的（匹配的）密钥：
$ 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
YAY! 问题终于解决了。但在known_hosts中的几个100个条目中，这个 "解决方案 "真的成了一个很大的PITA（也是榆树街的安全噩梦。
以下是如何在Chrome操作系统上删除已知的主机指纹（从known_hosts文件中删除）：
当连接失败时，在ssh输出中找到违规主机的索引。例如下面这一行中的违规索引是7：
Offending ECDSA key in /.ssh/known_hosts:7
打开安全壳窗口的JavaScript控制台(CTRL+Shift+J)，输入以下内容，将INDEX替换成适当的值(如7)：
term_.command.removeKnownHostByIndex(INDEX);
这个解决方案借用了Leo Gaggl的博客。