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之类的攻击。

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

  • 相关阅读:
    hdoj 2803 The MAX【简单规律题】
    hdoj 2579 Dating with girls(2)【三重数组标记去重】
    hdoj 1495 非常可乐【bfs隐式图】
    poj 1149 PIGS【最大流经典建图】
    poj 3281 Dining【拆点网络流】
    hdoj 3572 Task Schedule【建立超级源点超级汇点】
    hdoj 1532 Drainage Ditches【最大流模板题】
    poj 1459 Power Network【建立超级源点,超级汇点】
    hdoj 3861 The King’s Problem【强连通缩点建图&&最小路径覆盖】
    hdoj 1012 u Calculate e
  • 原文地址:https://www.cnblogs.com/bixiaoyu/p/10574887.html
Copyright © 2011-2022 走看看