解决ssh-copy-id时Host key verification failed的错误

Posted 2020-12-02

  如果因为某种原因（服务器系统重装，服务器间IP地址交换，DHCP，虚拟机重建，中间人劫持），这里笔者是因为虚拟机重建的缘故，该IP地址的公钥改变了，当使用 SSH 连接的时候会出现

 然后笔者把.ssh/knowns_hosts和.ssh/authorized_keys删除了，

重新ssh-copy-id把公钥复制给其他公钥试了一下，结果

  首先看下正常的步骤：

SSH 连接远程主机时，会检查主机的公钥。如果是第一次该主机，会显示该主机的公钥摘要，提示用户是否信任该主机
The authenticity of host ‘192.168.164.23 (192.168.164.23)‘ can‘t be established.
RSA key fingerprint is e9:0c:36:89:7f:3c:07:71:09:5a:9f:28:8c:44:e9:05.
Are you sure you want to continue connecting (yes/no)?

SSH对主机的public_key的检查等级是根据StrictHostKeyChecking变量来配置的。默认情况下，StrictHostKeyChecking=ask。简单所下它的三种配置值：
1.StrictHostKeyChecking=no
#最不安全的级别，当然也没有那么多烦人的提示了，相对安全的内网测试时建议使用。如果连接server的key在本地不存在，那么就自动添加到文件中（默认是known_hosts），并且给出一个警告。
2.StrictHostKeyChecking=ask #默认的级别，就是出现刚才的提示了。如果连接和key不匹配，给出提示，并拒绝登录。
3.StrictHostKeyChecking=yes #最安全的级别，如果连接与key不匹配，就拒绝连接，不会提示详细信息。

对于我来说，在内网的进行的一些测试，为了方便，选择最低的安全级别。在.ssh/config（或者/etc/ssh/ssh_config）中配置：
Host *
StrictHostKeyChecking no

Q:如何防止远程主机公钥改变导致 SSH 连接失败？
A:当确认中间人劫持×××风险比较小的情况下，才可以使用下面的方法，禁用 SSH 远程主机的公钥检查。 SSH 客户端提供一个 UserKnownHostsFile 配置，允许指定不同的 known_hosts 文件。那么将 known_hosts 指向不同的文件，不就不会造成公钥冲突导致的中断了么？
在.ssh/config（或者/etc/ssh/ssh_config）中配置：
Host *
UserKnownHostsFile /dev/null

综上
在.ssh/config（或者/etc/ssh/ssh_config）中配置
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null

或者将两个命令结合起来使用
ssh-copy-id -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /root/.ssh/id_rsa.pub [email protected]

同样第一次连接需要
ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]

以后就可以直接使用ssh hdp23连接了

然后scp复制文件也是同样的道理
scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -r /var/tmp/performance/moo.dat [email protected]:/var/tmp/

如有不当之处，请各位大神指教。