大數據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之類的攻擊。

雖然是小技術點，但以小見大，不少細節性的問題仍是得多注意，稍微不注意，線上操做需謹慎，切勿衝動！