文章目錄

• 基本原理
• 首次建立連接的時候的公鑰交換
• 通過ssh來進行密碼登錄
• 利用公鑰來登錄

基本原理

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

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

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

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

由上一張圖可以看出來，兩臺機器除了各自的一套公、私鑰之外，還保存了對方的公鑰，因此必然存在一個交換各自公鑰的步驟。

首次建立連接的時候的公鑰交換

建立連接時的公鑰交換，實際上并不是簡單地交換公鑰，而是存在專門的算法，這一步在首次連接時，數據傳送之前發生。

客戶端發起鏈接請求

服務端返回自己的公鑰，以及一個會話ID（這一步客戶端得到服務端公鑰）

客戶端生成密鑰對

客戶端用自己的公鑰異或會話ID，計算出一個值，并用服務端的公鑰加密

客戶端發送加密后的值到服務端，服務端用私鑰解密

服務端用解密后的值異或會話ID，計算出客戶端的公鑰（這一步服務端得到客戶端公鑰）

至此，雙方各自持有三個秘鑰，分別為自己的一對公、私鑰，以及對方的公鑰，之后的所有通訊都會被加密

首次建立連接時的公鑰互換的流程原理圖如下所示：

這里有一個有趣的地方，兩臺機器第一次使用SSH鏈接時，當服務端返回自己的公鑰（第2步）的時候，客戶端會有一條信息提示，大意是無法驗證對方是否可信，并給出對方公鑰的MD5編碼值，問是否確定要建立鏈接。

這是因為SSH雖然傳輸過程中很安全，但是在首次建立鏈接時并沒有辦法知道發來的公鑰是否真的來自自己請求的服務器，如果有人在客戶端請求服務器后攔截了請求，并返回自己的公鑰冒充服務器，這時候如果鏈接建立，那么所有的數據就都能被攻擊者用自己的私鑰解密了。這也就是所謂的中間人攻擊。

通過ssh來進行密碼登錄

ssh常用來遠程登錄到別的機器，有兩種常用的方法，第一種便是用賬號密碼來登錄：

服務端收到登錄請求后，首先互換秘鑰，詳細步驟如上一節所述

客戶端用服務端的公鑰加密賬號密碼并發送

服務端用自己的秘鑰解密后得到賬號密碼，然后進行驗證

服務端用客戶端的公鑰加密驗證結果并返回

客戶端用自己的秘鑰解密后得到驗證結果

密度登錄的驗證流程圖如下所示：

利用公鑰來登錄

這是第二種遠程登錄別的機器的方法，就是利用公鑰來登錄。

有時候并不是開發者手動去連接服務器，而是客戶端的程序需要連接到服務器，這時候用密碼登錄就不方便，一是需要處理輸入密碼的問題，二是需要想辦法安全的儲存密碼到程序里，這種情況下便可以利用公鑰來進行無密碼登錄。或者說你經常要遠程連接到某個服務器，又不想次次都輸入賬號和密碼，也可以采用這種方法：

客戶端用戶必須手動地將自己的公鑰添加到服務器一個名叫authorized_keys的文件里，顧名思義，這個文件保存了所有可以遠程登錄的機器的公鑰。

客戶端發起登錄請求，并且發送一個自己公鑰的指紋（具有唯一性，但不是公鑰）

服務端根據指紋檢測此公鑰是否保存在authorized_keys中

若存在，服務端便生成一段隨機字符串，然后利用客戶端公鑰加密并返回

客戶端收到后用自己的私鑰解密，再利用服務端公鑰加密后發回

服務端收到后用自己的私鑰解密，如果為同一字符串，則驗證通過

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

總結

以上是生活随笔為你收集整理的SSH(Secure Shell) 介绍一的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。