zoukankan      html  css  js  c++  java
  • 大数据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之类的攻击。

    虽然是小技术点,但以小见大,很多细节性的问题还是得多注意,稍微不注意,线上操作需谨慎,切勿冲动!

  • 相关阅读:
    1052. 爱生气的书店老板
    766. 托普利茨矩阵
    643.子数组的最大平均数I
    450. 删除二叉搜索树中的节点
    1489.找到最小生成树里的关键边和伪关键边
    839相似字符串
    1631.最小体力消耗路径
    SnowFlake雪花算法源码分析&灵活改造,常见分布式ID生成解决方案
    【目标检测】三、Faster R-CNN与R-FCN
    【目标检测】二、Fast R-CNN与SVD
  • 原文地址:https://www.cnblogs.com/bixiaoyu/p/10574887.html
Copyright © 2011-2022 走看看