如果不同,请忽略或replace主机密钥

通常我把服务器置于救援模式,这显然改变了主机密钥。 所以有些情况下,我知道SSH主机密钥会被暂时或永久地改变。 每次我需要做的是:

  • ssh-keygeyn -R xxxx
  • ssh xxxx并确认添加了新的密钥
  • 在救援模式下做一些事情,然后重启服务器
  • ssh-keygen -R xxxx
  • ssh xxxx如果需要,并接受新的主机密钥

如果有人提出了一个聪明的别名,或者有一个SSH客户端的configuration选项,如果不同的主机密钥要求replace主机密钥或只是暂时忽略问题,并进行,我发明了。

解决scheme1

您可以使用ssh-keyscan命令在login前扫描远程主机新公钥。

 ssh-keygen -R xxxx ssh-keyscan xxxx >> ~/.ssh/known_hosts ssh xxxx 

然后你可以从中创build一个脚本,使用主机作为参数,并把它放在PATH

要检查公钥是否有不同,你可以这样做:

 diff -q <(ssh-keygen -F xxxx | sed '1d') <(ssh-keyscan xxxx 2>/dev/null) 

解决scheme2

现在,如果您的基础设施中有DNS服务器,则应该设置SSHFP DNSlogging来集中处理机器的公钥更改,并避免各地自制脚本的麻烦。

检索DNS条目以configuration:

 ssh-keygen -r /etc/ssh/ssh_host_key.pub 

结果将如下所示:

 IN SSHFP 1 1 d3fa9bcf2d51979c53bcac2961f38b60e4e60886 IN SSHFP 2 1 f1f09814dd79eea523f490808cf3c096f1d1a432 

小解释:

  • 第一个字段:IN = Internet类
  • 第二栏:SSHFPloggingtypes
  • 第三场:algorithm(1 = RSA,2 = DSA,3 = ECDSA)
  • 第四栏:指纹types(1 = SHA-1,2 = SHA256)

用服务器名称前缀这些logging,并将它们放在您的DNSconfiguration中。

然后确保你所有的机器都会在/etc/resolv.conf联系你的DNS服务器。

最后,将VerifyHostKeyDNS=yes选项放在每个服务器上的.ssh/config文件中。

 ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null 

将欺骗ssh认为它的键列表是/dev/null ,并不会要求您确认将“添加”到(非远程)文件的密钥。 这样做的好处是不要将临时密钥添加到实际文件中。

你可以添加一个bash别名来使用它。

 alias sshnk="ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null"