接手大数据集群维护工作，这段时间忙的是焦头烂额，分身乏术，但是作为运维搬砖人员，这是必须的，接到需求，需要提供六台物理机，部署大数据集群，从安装部署到配置更新，还挺顺利，其中就涉及到ssh免密的事情，相信大家做运维的对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免密成功~
