CentOS下ssh無密碼密鑰方式登入設定

果我們管理的伺服器足夠多，每次都要輸入密碼豈不是很麻煩，這裡我們就有了一種代理的方式ssh-agent，ssh-agent其實就是一個密鑰的管理者，也可以理解為管家，我們將鑰匙交給管家來保管，每次開門只要管家幫我們開輸入進門密碼就OK了，這不是很方便啊。

還記得之前ssh密鑰登入時候的情景嗎：

這裡是要輸入產生密鑰時的密碼的，但是如果我們將密鑰交給管家來管理，給管家一個密碼，那麼我們每次進門的時候讓管家來幫我們開門：

這是腫麼了，不能和管家建立串連，我們要先啟動ssh-agent才能添加，管家都還沒上班，怎麼讓他保管鑰匙，怎麼讓他開門輸密碼呢：

當然這個代理也不是永久的，當我們退出之後重新登入進來，這個代理就消失了，我們必須要重新設定一次代理，經常使用windows的我們知道可以設定開機啟動項，我想足夠聰明的你也知道這裡該怎麼辦吧。

我們也可以用secureCRT來產生密鑰，將公開金鑰傳給伺服器的某個使用者，然後用密鑰登入的方式來進行登入，這個方法在網上可以找到很多的教程不用多解釋。這裡我遇到一個問題，我覺得也可以將伺服器產生一對密鑰中的私密金鑰傳過來，然後用secureCRT來指定這個私密金鑰，進行密鑰登入，不知道這種想法對不對。

密鑰登入是很安全方便，那麼到底密鑰登入是怎樣一個過程呢，這也是我糾結了許久的問題，我們的私密金鑰和伺服器上的公開金鑰是如何?匹配的呢，最初我的想法是這樣的，伺服器用我的公開金鑰加密一條訊息，我通過私密金鑰解密，然後用伺服器的公開金鑰加密發給伺服器，伺服器接收到了用它的私密金鑰解密，如果確實是伺服器發的訊息，則匹配成功。

對於ssh詳細登入過程這段是網上找到的http://blog.csdn.net/gsnumen/article/details/7293266。

ssh的登入過程分為5個階段：

1、版本號碼協商階段

2、密鑰和演算法協商階段

3、認證階段

4、會話要求階段

5、會話互動階段

1、版本號碼協商階段

服務端開啟連接埠22，等待客戶串連。

用戶端向服務端發起TCP串連，串連建立後，服務端向用戶端發送第一個報文，包括版本標誌字串，格式為“協議版本號碼 次協議版本號碼 軟體版本號碼”。

用戶端收到報文後，解析協議版本號碼，如果服務端的協議版本號碼比自己的低，且用戶端能支援服務端的低版本，就使用服務端的協議號，否則使用自己的協議版本號碼。

用戶端回複服務端一個報文，包含了用戶端決定使用的協議版本號碼。

服務端比較用戶端發過來的版本號碼，決定是否能同用戶端互動。

如果協商成功，就進入密鑰和演算法協商階段。否則服務端斷開TCP串連。

2、密鑰和演算法協商階段

服務端和用戶端分別發送演算法協商報文給對方，報文中包含自己支援的公開金鑰演算法列表、密碼編譯演算法列表、訊息驗證碼演算法列表、壓縮演算法列表等。

服務端和用戶端根據對方和自己支援的演算法得出最終使用的演算法。

服務端和用戶端利用DH交換演算法、主機金鑰組等參數，產生工作階段金鑰和會話ID。

c公 用戶端公開金鑰

c密 用戶端密鑰

s公 服務端公開金鑰

s密 服務端密鑰

在版本號碼協商階段完成後：

服務端將 s公 發送給用戶端。

服務端產生會話ID ，設為 id ，發送給用戶端。

用戶端產生工作階段金鑰，設為 key ，並計算 res = id 異或 key。

用戶端將 res 用 s公 進行加密，將結果發送給服務端。

服務端用 s密 進行解密，得到 res。

伺服器計算 res 異或 id，得到 key。

至此服務端和用戶端都知道了工作階段金鑰和會話ID，以後的資料轉送都使用工作階段金鑰進行加密和解密。

3、認證階段

基於帳號和口令的驗證方式：

用戶端使用密鑰和演算法協商階段產生的工作階段金鑰加密帳號、認證方法、口令，將結果發送給伺服器。

服務端使用獲得的工作階段金鑰解密報文，得到帳號和口令。

服務端對這個帳號和口令進行判斷，如果失敗，向用戶端發送認證失敗報文，其中包含了可以再次認證的方法列表。

用戶端從認證方法列表中選擇一種方法進行再次認證。

這個過程反覆進行，直到認證成功或者認證次數達到上限，服務端關閉本次TCP串連。

基於公開金鑰和私密金鑰的驗證方式：

使用ssh-keygen程式產生公開金鑰 id_dsa.pub 和私密金鑰 id_dsa，一般是在用戶端上產生，然後把 id_dsa.pub 通過某種方式發送給服務端。

服務端放在將要遠程登入過來的那個帳號的目錄的.ssh目錄下面。

用戶端使用密鑰和演算法協商階段產生的工作階段金鑰加密帳號、認證方法、id_dsa.pub，將結果發送給服務端。

服務端使用工作階段金鑰解密報文，得到帳號、id_dsa.pub。 服務端在這個帳號的目錄的.ssh目錄下找對應的公開金鑰，如果沒有找到，發送失敗訊息給用戶端，如果找到，比較客戶發送過來的這個公開金鑰和找到的公開金鑰，如果內容相同，服務端產生一個隨機的字串，簡稱“質詢”，然後使用找到的公開金鑰加密這個質詢，然後使用工作階段金鑰再次加密。

服務端把這個雙重加密的資料發送給用戶端。

用戶端使用工作階段金鑰解密報文，然後使用id_dsa再次解密資料，得到質詢。

用戶端使用工作階段金鑰加密質詢，發送給服務端。

服務端使用工作階段金鑰解密報文，得到質詢，判斷是不是自己產生的那個質詢，如果不相同，發送失敗訊息給用戶端，如果相同，認證通過。