大数据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免密成功~

【小结】

一台主机上有多个Linux系统，会常常切换，那么这些系统使用同一ip，登陆过一次后就会把ssh信息记录在本地的~/.ssh/known_hsots文件中，切换该系统后再用ssh访问这台主机就会出现冲突警告，须要手动删除修改known_hsots里面的内容

ssh会把你每一个你访问过计算机的公钥(public key)都记录在~/.ssh/known_hosts。当下次访问相同计算机时，OpenSSH会核对公钥。若是公钥不一样，OpenSSH会发出警告， 避免你受到DNS Hijack之类的攻击。

虽然是小技术点，但以小见大，不少细节性的问题仍是得多注意，稍微不注意，线上操做需谨慎，切勿冲动！