ssl與ssh

ssl只是個認證（數字簽名 ）和握手

ssh有加密              

ssh不是ssl加其它協議（如http,telnet等等)，能夠說，ssh作的比ssl更多 

詳見 http://imxie.net/2008/03/ssl-and-ssh.htm    

（吐槽：外國人的文章真的比較深入？起碼我這個對比我是隻在連接的這篇文章中找到一個合理的說法）

 

 

後來看阮一峯的文章後認知更清楚一點:ssl也有加密，是對稱加密

 

ssh是用於遠程加密登錄或遠程操做，採用公鑰加密（但無CA,即無數字證書，此時就有中間人攻擊的危害，ssh是經過服務端將公鑰md5值公佈，在客戶端首次遠程時自行計算對比，首次接受公鑰後會將此公鑰保存在本地，之後就直接用此加密遠程密碼，或使用公鑰登錄，詳見 http://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html

）,遠程加密操做即造成隧道，可用來傳送命令、數據（開端口互相傳輸數據，而開端口造成的隧道是經過公鑰加密創建的）,然後續的會話及會話中的數據傳輸的安全性是如何保障的還不知。

在H3C看到以下文檔： http://www.h3c.com.cn/Products___Technology/Technology/Security_Encrypt/Other_technology/Technology_recommend/200812/624143_30003_0.htm

SSH工做過程

在整個通信過程當中，爲實現SSH的安全鏈接，服務器端與客戶端要經歷以下五個階段：

表1 SSH服務器端與客戶端創建鏈接的五個階段

過程	說明	詳細內容
版本號協商階段	SSH目前包括SSH1和SSH2兩個版本，雙方經過版本協商肯定使用的版本	1.
密鑰和算法協商階段	SSH支持多種加密算法，雙方根據本端和對端支持的算法，協商出最終使用的算法	2.
認證階段	SSH客戶端向服務器端發起認證請求，服務器端對客戶端進行認證	3.
會話請求階段	認證經過後，客戶端向服務器端發送會話請求	4.
交互會話階段	會話請求經過後，服務器端和客戶端進行信息的交互	5.

 

1. 版本號協商階段

具體步驟以下：

l              服務器打開端口22，等待客戶端鏈接。

l              客戶端向服務器端發起TCP初始鏈接請求，TCP鏈接創建後，服務器向客戶端發送第一個報文，包括版本標誌字符串，格式爲「SSH－<主協議版本號>.<次協議版本號>－<軟件版本號>」，協議版本號由主版本號和次版本號組成，軟件版本號主要是爲調試使用。

l              客戶端收到報文後，解析該數據包，若是服務器端的協議版本號比本身的低，且客戶端能支持服務器端的低版本，就使用服務器端的低版本協議號，不然使用本身的協議版本號。

l              客戶端迴應服務器一個報文，包含了客戶端決定使用的協議版本號。服務器比較客戶端發來的版本號，決定是否能同客戶端一塊兒工做。

l              若是協商成功，則進入密鑰和算法協商階段，不然服務器端斷開TCP鏈接。

&  說明：

上述報文都是採用明文方式傳輸的。

 

2. 密鑰和算法協商階段

具體步驟以下：

l              服務器端和客戶端分別發送算法協商報文給對端，報文中包含本身支持的公鑰算法列表、加密算法列表、MAC（Message Authentication Code，消息驗證碼）算法列表、壓縮算法列表等。

l              服務器端和客戶端根據對端和本端支持的算法列表得出最終使用的算法。

l              服務器端和客戶端利用DH交換（Diffie-Hellman Exchange）算法、主機密鑰對等參數，生成會話密鑰和會話ID。

經過以上步驟，服務器端和客戶端就取得了相同的會話密鑰和會話ID。對於後續傳輸的數據，兩端都會使用會話密鑰進行加密和解密，保證了數據傳送的安全。在認證階段，兩端會使用會話ID用於認證過程。

  注意：

在協商階段以前，服務器端已經生成RSA或DSA密鑰對，他們主要用於參與會話密鑰的生成。

 

3. 認證階段

具體步驟以下：

l              客戶端向服務器端發送認證請求，認證請求中包含用戶名、認證方法、與該認證方法相關的內容（如：password認證時，內容爲密碼）。

l              服務器端對客戶端進行認證，若是認證失敗，則向客戶端發送認證失敗消息，其中包含能夠再次認證的方法列表。

l              客戶端從認證方法列表中選取一種認證方法再次進行認證。

l              該過程反覆進行，直到認證成功或者認證次數達到上限，服務器關閉鏈接爲止。

SSH提供兩種認證方法：

l              password認證：客戶端向服務器發出password認證請求，將用戶名和密碼加密後發送給服務器；服務器將該信息解密後獲得用戶名和密碼的明文，與設備上保存的用戶名和密碼進行比較，並返回認證成功或失敗的消息。

l              publickey認證：採用數字簽名的方法來認證客戶端。目前，設備上能夠利用RSA和DSA兩種公共密鑰算法實現數字簽名。客戶端發送包含用戶名、公共密鑰和公共密鑰算法的publickey認證請求給服務器端。服務器對公鑰進行合法性檢查，若是不合法，則直接發送失敗消息；不然，服務器利用數字簽名對客戶端進行認證，並返回認證成功或失敗的消息。

&  說明：

除了password認證和publickey認證，SSH2.0還提供了password-publickey認證和any認證。

l      password-publickey認證：指定該用戶的認證方式爲password和publickey認證同時知足。客戶端版本爲SSH1的用戶只要經過其中一種認證便可登陸；客戶端版本爲SSH2的用戶必須兩種認證都經過才能登陸。

l      any認證：指定該用戶的認證方式能夠是password，也能夠是publickey。

 

4. 會話請求階段

認證經過後，客戶端向服務器發送會話請求。服務器等待並處理客戶端的請求。在這個階段，請求被成功處理後，服務器會向客戶端迴應SSH_SMSG_SUCCESS包，SSH進入交互會話階段；不然迴應SSH_SMSG_FAILURE包，表示服務器處理請求失敗或者不能識別請求。

5. 交互會話階段

會話請求成功後，鏈接進入交互會話階段。在這個模式下，數據被雙向傳送。客戶端將要執行的命令加密後傳給服務器，服務器接收到報文，解密後執行該命令，將執行的結果加密發還給客戶端，客戶端將接收到的結果解密後顯示到終端上。

&  說明：

l      在交互會話階段，客戶端能夠經過粘貼文本會話的方式發送要執行的命令，但文本會話不能超過2000字節，且粘貼的命令最好是同一視圖下的命令，不然服務器可能沒法正確執行該命令。

l      若是粘貼的文本會話超過2000字節，能夠採用將配置文件上傳到服務器，利用新的配置文件從新啓動的方式執行這些命令。

 

 

 

ssl使用了公鑰加密（有ca）及對稱加密，創建對話（握手過程是透明的）時客戶端會獲取到服務端的公鑰，而且握手後就肯定了一個會話密鑰（而這個會話密鑰是經過剛纔得到的公鑰及握手時產生的三個隨機數來計算肯定的，這三個隨機數有兩個由客戶端產生，一個由服務端產生），這個密鑰是用來在會話時加密數據的，加密形式爲對稱加密，也就是說ssl對數據是用對稱加密，而數據的傳輸依然是普通的http(內容加密，會話不加密)。

ps:有個問題，握手時是明文通訊，那就會被截獲到公鑰、三個隨機數，這樣對話密鑰不久能夠知道了？那後面的對話加密不就會被解密？

 

參考文章：http://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html