圖解SSH原理及兩種登陸方法

SSH（Secure Shell）是一套協議標準，能夠用來實現兩臺機器之間的安全登陸以及安全的數據傳送，其保證數據安全的原理是非對稱加密。

傳統的對稱加密使用的是一套祕鑰，數據的加密以及解密用的都是這一套祕鑰，可想而知全部的客戶端以及服務端都須要保存這套祕鑰，泄露的風險很高，而一旦祕鑰便泄露便保證不了數據安全。

非對稱加密解決的就是這個問題，它包含兩套祕鑰 - 公鑰以及私鑰，其中公鑰用來加密，私鑰用來解密，而且經過公鑰計算不出私鑰，所以私鑰謹慎保存在服務端，而公鑰能夠隨便傳遞，即便泄露也無風險。

保證SSH安全性的方法，簡單來講就是客戶端和服務端各自生成一套私鑰和公鑰，而且互相交換公鑰，這樣每一條發出的數據均可以用對方的公鑰來加密，對方收到後再用本身的私鑰來解密。

連接建立

由上一張圖能夠看出來，兩臺機器除了各自的一套公、私鑰以外，還保存了對方的公鑰，所以必然存在一個交換各自公鑰的步驟。實際上並非簡單的各自發送公鑰，而是存在一些專門的算法。這一步在首次連接時、數據傳送以前發生。

1. 客戶端發起連接請求
2. 服務端返回本身的公鑰，以及一個會話ID（這一步客戶端獲得服務端公鑰）
3. 客戶端生成密鑰對
4. 客戶端用本身的公鑰異或會話ID，計算出一個值，並用服務端的公鑰加密
5. 客戶端發送加密後的值到服務端，服務端用私鑰解密
6. 服務端用解密後的值異或會話ID，計算出客戶端的公鑰（這一步服務端獲得客戶端公鑰）
7. 至此，雙方各自持有三個祕鑰，分別爲本身的一對公、私鑰，以及對方的公鑰，以後的全部通信都會被加密

這裏有一個有趣的地方，兩臺機器第一次使用SSH連接時，當服務端返回本身的公鑰（第2步）的時候，客戶端會有一條信息提示，大意是沒法驗證對方是否可信，並給出對方公鑰的MD5編碼值，問是否肯定要創建連接。

這是由於SSH雖然傳輸過程當中很安全，可是在首次創建連接時並無辦法知道發來的公鑰是否真的來自本身請求的服務器，若是有人在客戶端請求服務器後攔截了請求，並返回本身的公鑰冒充服務器，這時候若是連接創建，那麼全部的數據就都能被攻擊者用本身的私鑰解密了。這也就是所謂的中間人攻擊。

利用密碼登陸

SSH還經常使用來遠程登陸到別的機器，有兩種經常使用的方法，第一種即是帳號密碼登陸。

1. 服務端收到登陸請求後，首先互換公鑰，詳細步驟如上一節所述。
2. 客戶端用服務端的公鑰加密帳號密碼併發送
3. 服務端用本身的祕鑰解密後獲得帳號密碼，而後進行驗證
4. 服務端用客戶端的公鑰加密驗證結果並返回
5. 客戶端用本身的祕鑰解密後獲得驗證結果

利用公鑰登陸

有些時候並非開發者手動去鏈接服務器，而是客戶端的程序須要鏈接到服務器，這時候用密碼登陸就比較不方便，一是須要處理輸入密碼的問題，二是須要想辦法安全的儲存密碼到程序裏，這種狀況下即可以利用公鑰來進行無密碼登陸。

1. 客戶端用戶必須手動地將本身的公鑰添加到服務器一個名叫authorized_keys的文件裏，顧名思義，這個文件保存了全部能夠遠程登陸的機器的公鑰。
2. 客戶端發起登陸請求，而且發送一個本身公鑰的指紋（具備惟一性，但不是公鑰）
3. 服務端根據指紋檢測此公鑰是否保存在authorized_keys中
4. 若存在，服務端便生成一段隨機字符串，而後利用客戶端公鑰加密並返回
5. 客戶端收到後用本身的私鑰解密，再利用服務端公鑰加密後發回
6. 服務端收到後用本身的私鑰解密，若是爲同一字符串，則驗證經過

利用公鑰登陸的關鍵是必須手動將客戶端的公鑰添加到服務端，好比GitHub便有這一步驟，添加了以後即可無密碼登陸。

---

參考文獻：

• SSH登陸認證詳解
• Intro to SSH and SSH Keys
• 圖解SSH
• SSH原理與運用