快捷導(dǎo)航

SSH原理及兩種登錄方法圖文詳解

更新時間：2018年08月16日 16:31:31 作者：Decouple

SSH（Secure Shell）是一套協(xié)議標(biāo)準(zhǔn)，可以用來實(shí)現(xiàn)兩臺機(jī)器之間的安全登錄以及安全的數(shù)據(jù)傳送，其保證數(shù)據(jù)安全的原理是非對稱加密。本文通過圖文并茂的形式給大家介紹了SSH原理及兩種登錄方法，一起看看吧

SSH（Secure Shell）是一套協(xié)議標(biāo)準(zhǔn)，可以用來實(shí)現(xiàn)兩臺機(jī)器之間的安全登錄以及安全的數(shù)據(jù)傳送，其保證數(shù)據(jù)安全的原理是非對稱加密。

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

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

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

鏈接創(chuàng)建

由上一張圖可以看出來，兩臺機(jī)器除了各自的一套公、私鑰之外，還保存了對方的公鑰，因此必然存在一個交換各自公鑰的步驟。實(shí)際上并不是簡單的各自發(fā)送公鑰，而是存在一些專門的算法。這一步在首次鏈接時、數(shù)據(jù)傳送之前發(fā)生。

客戶端發(fā)起鏈接請求服務(wù)端返回自己的公鑰，以及一個會話ID（這一步客戶端得到服務(wù)端公鑰）客戶端生成密鑰對客戶端用自己的公鑰異或會話ID，計算出一個值，并用服務(wù)端的公鑰加密客戶端發(fā)送加密后的值到服務(wù)端，服務(wù)端用私鑰解密服務(wù)端用解密后的值異或會話ID，計算出客戶端的公鑰（這一步服務(wù)端得到客戶端公鑰）至此，雙方各自持有三個秘鑰，分別為自己的一對公、私鑰，以及對方的公鑰，之后的所有通訊都會被加密

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

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

利用密碼登錄

SSH還常用來遠(yuǎn)程登錄到別的機(jī)器，有兩種常用的方法，第一種便是賬號密碼登錄。

服務(wù)端收到登錄請求后，首先互換秘鑰，詳細(xì)步驟如上一節(jié)所述。
客戶端用服務(wù)端的公鑰加密賬號密碼并發(fā)送
服務(wù)端用自己的秘鑰解密后得到賬號密碼，然后進(jìn)行驗證
服務(wù)端用客戶端的公鑰加密驗證結(jié)果并返回
服務(wù)端用自己的秘鑰解密后得到驗證結(jié)果

利用公鑰登錄

有些時候并不是開發(fā)者手動去連接服務(wù)器，而是客戶端的程序需要連接到服務(wù)器，這時候用密碼登錄就比較不方便，一是需要處理輸入密碼的問題，二是需要想辦法安全的儲存密碼到程序里，這種情況下便可以利用公鑰來進(jìn)行無密碼登錄。

客戶端用戶必須手動地將自己的公鑰添加到服務(wù)器一個名叫authorized_keys的文件里，顧名思義，這個文件保存了所有可以遠(yuǎn)程登錄的機(jī)器的公鑰。客戶端發(fā)起登錄請求，并且發(fā)送一個自己公鑰的指紋（具有唯一性，但不是公鑰）服務(wù)端根據(jù)指紋檢測此公鑰是否保存在authorized_keys中若存在，服務(wù)端便生成一段隨機(jī)字符串，然后利用客戶端公鑰加密并返回客戶端收到后用自己的私鑰解密，再利用服務(wù)端公鑰加密后發(fā)回服務(wù)端收到后用自己的私鑰解密，如果為同一字符串，則驗證通過

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