相信運維的對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之類的攻擊。
雖然是小技術點，但以小見大，很多細節性的問題還是得多注意，稍微不注意，線上操作需謹慎，切勿衝動！
