相信运维的对ssh免密登陆应该是对这个再清楚不过的吧，由于我们大数据对于安全这方便管控的很严格，单独找一台物理机作为跳板机，其他的机器都必须要从这个跳板机免密登陆，由于机器比较的多，其中dn30这个域名ssh无法登陆，但是对应的IP地址是可以正常ssh免密登陆的，如图1所示：
【图1】
我检查了一下目标端dn30的authorized_keys内容，cm跳板的hadoop的公钥已经给了dn30,这一点没毛病呀，再检查ssh目录以及下面的文件权限也没问题呀（如图2所示），究竟什么情况能导致这个问题呢？
【图2】
最后查看了dn30的known_hosts的内容，发现里面记录的竟然是search03的ssh连接秘钥对，而search03的known_hosts记录的却是dn30的ssh连接秘钥对；两台机器与本地的域名不一致，为什么会这样呢？这才记起来，原来这两台机器装完之后，已经做了ssh域名免密登陆，现在的这个dn30机器应该是search03，而search03应该是dn30，因为dn30硬盘故障，是后面恢复的，所以域名解析互换了，但是秘钥对还保存在know_hosts里面，知道了原因，这就好办了，我们直接登陆到两台机器上直接rm -rf /home/hadoop/.ssh/known_hosts或者>/home/hadoop/.ssh/known_hosts清空。
随后我们在尝试ssh dn30，还是不行，难道这不是根本原因吗？目标端的不是已经清空了knows_hosts对应的ssh连接信息吗？
其实细心的同学们会发现，源端还是有个knows_hosts,这里面才是真正记录ssh免密远端主机的秘钥认证信息（如图3所示），我们只有清理源端的knows_hosts的信息才能真正的解决问题
注意，这里千万别不要rm -rf knows_host或者>knows_hosts，这样的话里面记录所有的机器都需要重新认证，虽然问题不是很大，但是这样线上某些严格依赖ssh域名免密的程序就会收到影响（我就这样背一次锅，血的教训，不但要重新认证，还要被训一下，哎！如图4所示）
【图3】
【图4】
最后我们在尝试ssh dn30免密成功~
【小结】
一台主机上有多个Linux系统，会经常切换，那么这些系统使用同一ip，登录过一次后就会把ssh信息记录在本地的~/.ssh/known_hsots文件中，切换该系统后再用ssh访问这台主机就会出现冲突警告，需要手动删除修改known_hsots里面的内容
ssh会把你每个你访问过计算机的公钥(public key)都记录在~/.ssh/known_hosts。当下次访问相同计算机时，OpenSSH会核对公钥。如果公钥不同，OpenSSH会发出警告， 避免你受到DNS Hijack之类的攻击。
虽然是小技术点，但以小见大，很多细节性的问题还是得多注意，稍微不注意，线上操作需谨慎，切勿冲动！
