这是一个很简单的问题，我们都可以面对，也许手动解决，而不需要太多的考虑。
当服务器发生更改，重新configuration或重新分配IP地址时，我们将在下面收到SSH主机validation消息。 我感兴趣的是简化工作stream程来解决这些ssh识别错误。
鉴于以下消息，我通常vi /root/.ssh/known_hosts +434并删除（ dd ）违规行。
我看到其他组织中的开发人员/用户因为看到这个消息而失去了他们的完整的 known_hosts文件。 虽然我不那么远，但我知道有一个更好的方法来处理这个问题。
提示？
[root@xt ~]# ssh las-db1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:434 RSA host key for las-db1 has changed and you have requested strict checking. Host key verification failed.
您可以使用ssh-keygen命令通过主机删除特定条目：
ssh-keygen -R las-db1
如果你没有这个命令，你总是可以使用sed：
sed -i '/las-db1/d' /root/.ssh/known_hosts
作为一个puppet用户，我解决这个问题的方法是实际让我的puppet服务器收集我的SSH主机密钥，并将它们发布到所有build立SSH连接的系统上。
这样我不必担心删除它们。 百分之九十九的时间傀儡已经运行并更新了我的钥匙，因为我有我的代理运行每三十分钟。 我的例外情况非常罕见，所以如果我不愿意等待，我不介意快速编辑known_hosts系统。
class ssh::hostkeys { @@sshkey { "${::clientcert}_rsa": type => rsa, key => $sshrsakey, tag => 'rsa_key', } if 'true' == $common::params::sshclient { Sshkey <<| tag == 'rsa_key' |>> { ensure => present } } file {'/etc/ssh/ssh_known_hosts': ensure => present, owner => 'root', group => 'root', mode => 0644, } }
我想增加一个build议，可以帮助你在非常特殊的情况下安全性不太关心。
我有一个实验室环境，经常重新安装机器。 每次发生这种情况，都会生成新的主机密钥（我可能将主机密钥保存在某处并将其设置为安装后脚本）。
由于在这个实验环境中，安全性对我来说不是问题，而且密钥更改频繁，所以在我的.ssh / config文件中有以下内容：
Host lab-* User kenny IdentityFile ~/.ssh/lab_id_rsa StrictHostKeyChecking no UserKnownHostsFile=/dev/null
这确保连接到我的实验室机器将永远不会再造成这个错误，我的SSH客户端将只连接，而不检查主机密钥。
如果你根本不关心安全问题，那么你只能这样做，因为这会使你处于一个中间人攻击的弱势地位。
根据openssh 5.6发行说明 ，您不需要使用主机密钥：
基于主机的身份validation现在可以使用证书主机密钥。 必须使用sshd（8）中所述的@ cert-authority标记在known_hosts文件中指定CA密钥。
警告 ：到目前为止，我从来没有听说过任何人在使用这个function。 使用风险自负（但我相信openssh开发人员已经足够偏执，不会在没有大量testing和代码审计的情况下发布这样的杀手级function）。
SSHFP DNS ResourceRecord可能会有所帮助，具体取决于您的ssh客户端利用它多less。 把所有的ssh公钥指纹都保存在主机名上。
预先通过SSL实施DNSSEC或DNS。
http://www.ietf.org/rfc/rfc4255.txt
FreeIPA.org处理主机和用户密钥pipe理以及PKI证书。 它还会在创build新密钥时自动上传SSHFP DNSlogging。
系统安全服务守护程序（SSSD）可以configuration为caching和检索主机SSH密钥，以便应用程序和服务只需要在一个位置查找主机密钥。 由于SSSD可以使用FreeIPA作为其身份信息提供者之一，因此FreeIPA提供了一个通用的集中式密钥库。 pipe理员不需要担心分发，更新或validation主机SSH密钥。
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html