SSH
目錄
1 SSH簡介 1
1.1 什么是SSH 1
1.2 SSH的產生背景 1
1.3 SSH的技術特點 1
2 SSH總體框架 2
2.1 傳輸層協議 2
2.2 認證層協議 3
2.3 連接層協議 3
3 SSH安全性 3
3.1 數據傳輸安全性 3
3.2 用戶認證安全性 3
4 SSH協議過程 3
4.1 連接建立 3
4.2 協商版本 4
4.3 算法協商 4
4.4 密鑰交換 5
4.5 用戶認證 5
4.6 服務請求 6
4.7 數據傳輸和連接關閉 7
1 SSH簡介
1.1 什么是SSH
SSH的英文全稱為Secure Shell，是IETF（Internet Engineering Task Force）的Network Working Group所制定的一族協議，其目的是要在非安全網絡上提供安全的遠程登錄和其他安全網絡服務。
1.2 SSH的產生背景
SSH協議出現之前，在網絡設備管理上廣泛應用的一種方式是Telnet。
Telnet協議的優勢在于通過它可以遠程地登錄到網絡設備上，對網絡設備進行配置，為網絡管理員異地管理網絡設備提供了極大的方便。
但是，Telnet協議存在三個致命的弱點：
?????????????? 數據傳輸采用明文方式，傳輸的數據沒有任何機密性可言。
?????????????? 認證機制脆弱。用戶的認證信息在網絡上以明文方式傳輸，很容易被切聽；Telnet只支持傳統的密碼認證方式，很容易被攻擊。
?????????????? 客戶端無法真正識別服務器的身份，攻擊者很容易進行“偽服務器欺騙”。
SSH協議正是為了克服Telnet協議存在的問題而誕生的。
網絡中另外一個廣泛應用的協議——FTP，也面臨著和Telnet相同的問題。為了解決FTP應用中的安全性問題，在SSH協議基礎上擴展了對FTP安全性的支持，即SFTP。
1.3 SSH的技術特點
SSH協議是一種在不安全的網絡環境中，通過加密和認證機制，實現安全的遠程訪問以及文件傳輸等業務的網絡安全協議。
SSH協議具有以下一些優點：
?????????????? 數據傳輸采用密文的方式，保證信息交互的機密性；
?????????????? 用戶的認證信息以密文的方式傳輸，可以有效地防止用戶信息被切聽；
?????????????? 除了傳統的密碼認證，SSH服務器還可以采用多種方式對用戶進行認證（如安全性級別更高的公鑰認證），提高了用戶認證的強度；
?????????????? 客戶端和服務器端之間通信使用的加解密密鑰，都是通過密鑰交互過程動態生成的，可以防止對加解密密鑰的暴力猜測，安全性級別比手工配置密鑰的方式高；
?????????????? 為客戶端提供了認證服務器的功能，可以防止“偽服務器欺騙”。
2 SSH總體框架
SSH協議采用客戶端/服務器架構，分為傳輸層、認證層和連接層。
2.1 傳輸層協議
傳輸層協議主要用來在客戶端和服務器之間建立一條安全的加密通道，為用戶認證、數據交互等對數據傳輸安全性要求較高的階段提供足夠的機密性保護。
傳輸層提供了如下功能：
?????????????? 數據真實性檢查
?????????????? 數據完整性檢查
?????????????? 為客戶端提供了對服務器進行認證的功能
傳輸層協議通常運行在TCP/IP連接之上（服務器端使用的知名端口號為22），也可以運行在其他任何可以信賴的數據連接之上。
2.2 認證層協議
認證層協議運行在傳輸層協議之上，完成服務器對登錄用戶的認證。
2.3 連接層協議
連接層協議負責在加密通道上劃分出若干邏輯通道，以運行不同的應用。它運行在認證層協議之上，提供交互會話、遠程命令執行等服務。
3 SSH安全性
3.1 數據傳輸安全性
SSH協議需要解決Telnet協議明文傳輸的缺陷，它通過以下兩方面保證數據傳輸的機密性：
?????????????? 在通信雙方之間建立加密通道，保證傳輸的數據不被切聽；
?????????????? 使用密鑰交換算法保證密鑰本身的安全。
所謂加密通道，是指發送方在發送數據前，使用加密密鑰對數據進行加密，然后將數據發送給對方；接收方接收到數據后，利用解密密鑰從密文中獲取明文。
加解密算法分為兩類：
?????????????? 對稱密鑰算法：數據加密和解密時使用相同的密鑰和相同的算法。
?????????????? 非對稱密鑰算法：數據加密和解密時使用不同的密鑰，一個是公開的公鑰，一個是由用戶秘密保存的私鑰。
由于非對稱密鑰算法比較耗時，一般多用于數字簽名以及身份認證。SSH加密通道上的數據加解密使用對稱密鑰算法，目前主要支持的算法有DES、3DES、AES等，這些算法都可以有效地防止交互數據被切聽，而且由于采用了初始化向量保護，可以防止類似于密碼流復用等密碼分析工具的攻擊。
對稱密鑰算法要求解密密鑰和加密密鑰完全一 致，才能順利從密文中解密得到明文。因此，要建立加密通道，必須先在通信雙方部署一致的加解密密鑰。部署加解密密鑰的方式有多種：手工配置和第三方機構分 配等。手工配置的方式擴展性差，只適合一些小型的本地網絡；使用第三方機構分配密鑰的方式，需要額外的第三方服務器，而且密鑰在網絡中傳輸容易被切聽。
SSH協議使用一種安全的方式在通信雙方部署密鑰：密鑰交換算法。利用密鑰交換算法可以在通信雙方動態地產生密鑰，這個密鑰只能被通信的雙方獲得，任何第三者都無法切聽，這就在源頭上保證了加解密使用密鑰的安全性，很好地解決了密鑰分發問題。
密鑰交換算法的基本原理是：
(1)??????? 客戶端隨機選擇一個私鑰Xc，1<Xc<p-1，計算出Yc=g^Xc mod p，將計算出的Yc發送給服務器端。其中，p是一個很大的素數，g是p的素根。p和g是雙方共有的一對參數，協議允許雙方通過協商獲得相同的p和g參數。
(2)??????? 服務器也隨機生成一個私鑰Xs，1<Xs<p-1，計算出Ys＝g^Xs mod p，也將計算出的Ys發送給客戶端。
(3)??????? 服務器接收到客戶端發送過來的Yc，按照下面的公式計算出密鑰：
K ＝ （Yc）^Xs mod p
(4)??????? 客戶端收到服務器端發送過來的Ys，同樣按照下面的公式計算出密鑰：
K ＝ （Ys）^Xc mod p
通過上面的方法，客戶端和服務器端就可以獲得相同的密鑰。
由上面的分析可以看出，密鑰交換算法的安全性建立在計算離散對數的難度之上。算式Y=g^x mod p中，由X計算Y是很容易的，但是要由Y計算X是非常困難的。在密鑰交換算法中對外公開的只有p、g、Yc和Ys，私鑰Xc和Xs是保密的，其他用戶即便獲取了p、g、Yc和Ys也很難推斷出私鑰Xc和Xs，從而保證了密鑰的安全性。
密鑰交換算法具有如下優勢：
?????????????? 擴展性更好，不需要網絡管理員的多余配置；
?????????????? 交換得到的密鑰是保存在內存中，不易被讀取和篡改；
?????????????? 每個連接都會動態生成一次新的密鑰，安全性更高。
3.2 用戶認證安全性
為了防止非法用戶登錄到設備，對設備進行破壞性配置，SSH協議需要支持多種用戶認證方式，提高對用戶認證的強度。常用的用戶認證方式包括密碼認證和公鑰認證，Comware V5平臺還定義了一種新的認證方式——password-publickey認證。
3.2.1 密碼認證
SSH協議可以利用AAA提供的認證功能，完成對登錄用戶進行密碼認證。根據AAA采取的認證策略的不同，密碼認證分為本地認證和遠程認證兩種方式。
本地認證
本地認證是指在SSH服務器本地保存用戶的信息，認證過程在本地完成。如圖所示，網管人員通過網絡遠程登錄到小區的網關設備上，對設備進行相關配置。網關設備作為SSH服務器根據AAA本地用戶數據庫中的用戶信息對登錄用戶進行身份認證。
遠程認證
遠程認證是指將用戶信息保存在遠端的RADIUS等認證服務器上，認證過程在本地設備和遠程認證服務器之間完成。如圖所示，網絡管理員通過網絡遠程登錄到小區的網關設備上，對網關設備進行配置。網關設備作為SSH服務器，將登錄用戶的認證信息，傳遞到遠程認證服務器（如RADIUS服務器）上，根據認證服務器返回的對該用戶的認證結果決定是否允許該用戶登錄。
采用遠程認證方式可以將某個區域內所有用戶的配置、管理都集中到遠程認證服務器上，便于對用戶的集中管理。此外，用戶的身份信息等關鍵數據都保存在認證服務器上，在很大程度上提高了用戶信息的安全性。
當然，采用遠程認證方式，需要保證網關設備與遠程認證服務器之間的連接是絕對安全的，這樣才能保證用戶信息的安全。
3.2.2 公鑰認證
由于密碼認證方式的認證強度較弱，SSH協議引入了公鑰認證方式。目前，設備上可以利用RSA和DSA兩種非對稱密鑰算法實現公鑰認證。
公鑰認證的過程分為兩個部分：：
(1)??????? 公鑰驗證：客戶端首先將自己本地密鑰對的公鑰部分，按照字符串格式發送到服務器。服務器使用本地保存的客戶端公鑰，與報文中攜帶的客戶端公鑰進行比較，驗證客戶端持有公鑰的正確性。
(2)??????? 數字簽名驗證：如果公鑰驗證成功，客戶端繼續使用自己本地密鑰對的私鑰部分，對特定報文進行摘要運算，將所得的結果（即數字簽名）發送給服務器，向服務器證明自己的身份；服務器使用預先配置的該用戶的公鑰，對客戶端發送過來的數字簽名進行驗證。
公鑰驗證和數字簽名驗證中任何一個驗證失敗，都會導致本次公鑰認證失敗。
公鑰認證具有以下優勢：
?????????????? 認證強度高，不易受到“暴力猜測”等攻擊方式的影響。
?????????????? 具有較高的易用性。一次配置成功后，后續認證過程自動完成，不需要用戶記憶和輸入密碼。
但是，公鑰認證還存在以下缺點：
?????????????? 公鑰認證配置比密碼認證復雜。
?????????????? 公鑰認證只能區分私鑰，如果要實現充分的“粒度”，則必須為每一個用戶創建一個私鑰，相應地需要在服務器上為每一個用戶配置對應的公鑰，對于有多個用戶使用同一個終端登錄的情況，這種方式顯然是不適合的，也是不必要的。
3.2.3 password-publickey認證
Comware V5平臺定義了一種新的認證方式：password-publickey認證，這種認證方式要求用戶同時完成公鑰認證和密碼認證，只有兩種認證都成功后，才能通過服務器端的認證。
password-publickey認證方式充分利用了密碼認證和公鑰認證的優勢，具有如下優點：
?????????????? 同時要求用戶進行兩種認證，安全性更高。在公鑰上綁定密碼，可以防止由于SSH客戶端上的安全性隱患，影響到SSH服務器的安全性。
?????????????? 可以在一對公私密鑰對的基礎上，通過設置不同的密碼，配置不同的用戶，為這些用戶設置不同的權限，方便了管理員的配置。
?????????????? 既利用了公鑰認證的安全性，又節約了存儲成本和配置成本。公鑰認證實現方案中，要實現對用戶認證的充分“粒度”，就必須為每個用戶都配置一對密鑰對，在password-publickey認證方式，多個用戶可以共用一對密鑰對。
?????????????? 在公鑰認證技術上應用密碼認證，結合Comware V5原有實現（結合AAA實現對用戶的認證）可以很方便地同遠程認證服務器配合，從而利用遠程服務器上的諸多功能。
3.3 對“偽服務器欺騙”的防御
用戶認證機制只實現了服務器端對客戶端的認證，而客戶端無法認證服務器端，因此存在著“偽服務器欺騙”的安全隱患。
如圖所示，當客戶端主機需要與服務器建立連接時，第三方攻擊者冒充真正的服務器，與客戶端進行數據交互，竊取客戶端主機的安全信息，并利用這些信息去登錄真正的服務器，獲取服務器資源，或對服務器進行攻擊。
為了防止類似這樣的偽服務器欺騙，SSH協議支持客戶端對服務器端進行認證。服務器端在密鑰交換階段，使用自己的私鑰對一段固定格式的數據進行數字簽名，并將該簽名發往客戶端，客戶端使用本地保存的服務器公鑰，對簽名進行鑒別，從而達到認證服務器的目的。
客戶端對服務器進行認證的基礎是本端存儲的服務器公鑰是真實服務器的公鑰。因此，需要保證客戶端獲取的服務器公鑰是正確的。目前，Comware V5支持兩種獲取服務器公鑰的方式：
?????????????? 手工配置：既通過手工命令方式，將服務器公鑰配置在本地，并在本地建立服務器名稱和公鑰之間的關聯；
?????????????? 首次認證：SSH協議交互過程中，服務器會將自己的公鑰通過協議報文發送到客戶端，Comware V5借用這個特點，允許SSH客戶端配置首次認證功能，即SSH客戶端第一次登錄SSH服務器時，可以從協議報文中獲該服務器端公鑰并保存到本地，作為后續認證的依據。
4 SSH協議過程
SSH的報文交互主要有以下幾個階段：
?????????????? 連接建立
?????????????? 版本協商
?????????????? 算法協商
?????????????? 密鑰交換
?????????????? 用戶認證
?????????????? 服務請求
?????????????? 數據傳輸和連接關閉
4.1 連接建立
SSH服務器端在22端口偵聽客戶端的連接請求，接收到客戶端的連接建立請求后，與客戶端進行三次握手，建立起一條TCP連接，后續的所有報文交互都在這個TCP連接之上進行。
4.2 協商版本
TCP連接建立之后，服務器和客戶端都會向對端發送自己支持的版本號。服務器端和客戶端收到對端發送過來的版本后，與本端的版本號進行比較，雙方都支持的最高版本號即為協商出的版本號。
本協商成功后，進入下一個階段，即算法協商階段。否則，中斷連接。
?? 說明：
SSH1.99為特殊的版本號，這個版本既可以與SSH2.0版本互通，又可以與SSH1.5版本互通。
4.3 算法協商
SSH協議報文交互需要使用多種算法：
?????????????? 用于產生會話密鑰的密鑰交換算法，包括diffie-hellman-group-exchange-sha1、diffie-hellman-group1-sha1和diffie-hellman-group14-sha1算法等。
?????????????? 用于數據信息加密的加密算法，包括3des-cbc、aes128-cbc和des-cbc加密算法等。
?????????????? 用于進行數字簽名和認證的主機公鑰算法，包括RSA和DSA公鑰算法等。
?????????????? 用于數據完整性保護的MAC算法，包括hmac-md5、hmac-md5-96、hmac-sha1和hmac-sha1-96算法等。
由于各種客戶端和服務器對這些算法的支持情況不一樣，因此需要通過算法協商階段，使客戶端和服務器協商出雙方都支持的算法。
SSH協議的算法協商過程為：
(1)??????? 客戶端和服務器端都將自己支持的算法列表發送給對方；
(2)??????? 雙 方依次協商每一種算法（密鑰交換算法、加密算法等）。每種算法的協商過程均為：從客戶端的算法列表中取出第一個算法，在服務器端的列表中查找相應的算法， 如果匹配上相同的算法，則該算法協商成功；否則繼續從客戶端算法列表中取出下一個算法，在服務器端的算法列表中匹配，直到匹配成功。如果客戶端支持的算法 全部匹配失敗，則該算法協商失敗。
(3)??????? 某一種算法協商成功后，繼續按照上述方法協商其他的算法，直到所有算法都協商成功；如果某一種算法協商失敗，則客戶端和服務器之間的算法協商失敗，服務器斷開與客戶端的連接。
以加密算法為例，算法的協商方式為：
表1 加密算法協商舉例
客戶端的加密算法列表 服務端的加密算法列表 最后協商出的加密算法
3des、3des-cbc、aes128-cbc aes128-cbc、3des-cbc、des-cbc 3des-cbc
4.4 密鑰交換
加密算法協商成功后，為了保證加解密密鑰的安全性，SSH利用密鑰交換算法在通信雙方安全動態地生成和交互數據的加解密密鑰，并能夠有效防止第三方切聽加解密密鑰。密鑰交換算法的詳細介紹請參見“3.1.2? 使用密鑰交換算法保證密鑰本身的安全”。
4.5 用戶認證
密鑰交換完成之后，進入用戶認證階段。
用戶認證過程
如圖5所示，用戶認證過程為：
(1)??????? 客戶端向服務器端發送認證請求報文，其中攜帶的認證方式為“none”。
(2)??????? 服務器收到none方式認證請求，回復認證挑戰報文，其中攜帶服務器支持、且需要該用戶完成的認證方式列表。
(3)??????? 客戶端從服務器發送給自己的認證方式列表中選擇某種認證方式，向服務器發起認證請求，認證請求中包含用戶名、認證方法、與該認證方法相關的內容：
?????????????? 密碼認證方式中，內容為用戶的密碼；
?????????????? 公鑰認證方式中，內容為用戶本地密鑰對的公鑰部分（公鑰驗證階段）或者數字簽名（數字簽名驗證階段）。
(4)??????? 服務器接收到客戶端的認證請求，驗證客戶端的認證信息：
?????????????? 密碼認證方式：服務器將客戶端發送的用戶名和密碼信息，與設備上或者遠程認證服務器上保存的用戶名和密碼進行比較，從而判斷認證成功或失敗。
?????????????? 公鑰認證方式：服務器對公鑰進行合法性檢查，如果不合法，則認證失敗；否則，服務器利用數字簽名對客戶端進行認證，從而判斷認證成功或失敗。
(5)??????? 服務器根據本端上該用戶的配置，以及用戶認證的完成情況，決定是否需要客戶端繼續認證，分為以下幾種情況：
?????????????? 如果該種認證方式認證成功，且該用戶不需要繼續完成其他認證，則服務器回復認證成功消息，認證過程順利完成。
?????????????? 如果該種認證方式認證成功，但該用戶還需要繼續完成其他認證，則回復認證失敗消息，繼續向客戶端發出認證挑戰，在報文中攜帶服務器需要客戶端繼續完成的認證方式列表；
?????????????? 如果該種認證方式認證失敗，用戶的認證次數尚未到達認證次數的最大值，服務器繼續向客戶端發送認證挑戰；
?????????????? 如果該種認證方式認證失敗，且用戶的認證次數達到認證次數的最大值，用戶認證失敗，服務器斷開和客戶端之間的連接。
?? 說明：
認證挑戰是指SSH服務器將用戶需要完成的認證方式列表發送給用戶，要求用戶從中選擇一種，繼續發起認證請求。用戶未完成認證時，服務器都會通過這種發送認證列表的方式，要求用戶進行認證。
4.6 服務請求
SSH協議支持多種應用服務。用戶成功完成認證后，SSH客戶端向服務器端發起服務請求，請求服務器提供某種應用。
服務請求的過程為：
(1)??????? 客戶端發送SSH_MSG_CHANNEL_OPEN消息，請求與服務器建立會話通道，即session；
(2)??????? 服務器端收到SSH_MSG_CHANNEL_OPEN消息后，如果支持該通道類型，則回復SSH_MSG_CHANNEL_OPEN_CONFIRMATION消息，從而建立會話通道；
(3)??????? 會話通道建立之后，客戶端可以申請在通道上進行shell或subsystem類型的會話，分別對應SSH和SFTP兩種類型的服務。
4.7 數據傳輸和連接關閉
服務請求成功，建立會話后，服務器和客戶端可以在該會話上進行數據的傳輸。客戶端將要執行的命令加密后傳給服務器，服務器接收到報文，解密后執行該命令，將執行的結果加密發送給客戶端，客戶端將接收到的結果解密后顯示到終端上。
通信結束或用戶空閑時間超時后，關閉會話，斷開連接。
**************************
未完待續
參考：ssh技術白皮書 ssh協議詳解
????
目錄
1 SSH簡介 1
1.1 什么是SSH 1
1.2 SSH的產生背景 1
1.3 SSH的技術特點 1
2 SSH總體框架 2
2.1 傳輸層協議 2
2.2 認證層協議 3
2.3 連接層協議 3
3 SSH安全性 3
3.1 數據傳輸安全性 3
3.2 用戶認證安全性 3
4 SSH協議過程 3
4.1 連接建立 3
4.2 協商版本 4
4.3 算法協商 4
4.4 密鑰交換 5
4.5 用戶認證 5
4.6 服務請求 6
4.7 數據傳輸和連接關閉 7
1 SSH簡介
1.1 什么是SSH
SSH的英文全稱為Secure Shell，是IETF（Internet Engineering Task Force）的Network Working Group所制定的一族協議，其目的是要在非安全網絡上提供安全的遠程登錄和其他安全網絡服務。
1.2 SSH的產生背景
SSH協議出現之前，在網絡設備管理上廣泛應用的一種方式是Telnet。
Telnet協議的優勢在于通過它可以遠程地登錄到網絡設備上，對網絡設備進行配置，為網絡管理員異地管理網絡設備提供了極大的方便。
但是，Telnet協議存在三個致命的弱點：
?????????????? 數據傳輸采用明文方式，傳輸的數據沒有任何機密性可言。
?????????????? 認證機制脆弱。用戶的認證信息在網絡上以明文方式傳輸，很容易被切聽；Telnet只支持傳統的密碼認證方式，很容易被攻擊。
?????????????? 客戶端無法真正識別服務器的身份，攻擊者很容易進行“偽服務器欺騙”。
SSH協議正是為了克服Telnet協議存在的問題而誕生的。
網絡中另外一個廣泛應用的協議——FTP，也面臨著和Telnet相同的問題。為了解決FTP應用中的安全性問題，在SSH協議基礎上擴展了對FTP安全性的支持，即SFTP。
1.3 SSH的技術特點
SSH協議是一種在不安全的網絡環境中，通過加密和認證機制，實現安全的遠程訪問以及文件傳輸等業務的網絡安全協議。
SSH協議具有以下一些優點：
?????????????? 數據傳輸采用密文的方式，保證信息交互的機密性；
?????????????? 用戶的認證信息以密文的方式傳輸，可以有效地防止用戶信息被切聽；
?????????????? 除了傳統的密碼認證，SSH服務器還可以采用多種方式對用戶進行認證（如安全性級別更高的公鑰認證），提高了用戶認證的強度；
?????????????? 客戶端和服務器端之間通信使用的加解密密鑰，都是通過密鑰交互過程動態生成的，可以防止對加解密密鑰的暴力猜測，安全性級別比手工配置密鑰的方式高；
?????????????? 為客戶端提供了認證服務器的功能，可以防止“偽服務器欺騙”。
2 SSH總體框架
SSH協議采用客戶端/服務器架構，分為傳輸層、認證層和連接層。
2.1 傳輸層協議
傳輸層協議主要用來在客戶端和服務器之間建立一條安全的加密通道，為用戶認證、數據交互等對數據傳輸安全性要求較高的階段提供足夠的機密性保護。
傳輸層提供了如下功能：
?????????????? 數據真實性檢查
?????????????? 數據完整性檢查
?????????????? 為客戶端提供了對服務器進行認證的功能
傳輸層協議通常運行在TCP/IP連接之上（服務器端使用的知名端口號為22），也可以運行在其他任何可以信賴的數據連接之上。
2.2 認證層協議
認證層協議運行在傳輸層協議之上，完成服務器對登錄用戶的認證。
2.3 連接層協議
連接層協議負責在加密通道上劃分出若干邏輯通道，以運行不同的應用。它運行在認證層協議之上，提供交互會話、遠程命令執行等服務。
3 SSH安全性
3.1 數據傳輸安全性
SSH協議需要解決Telnet協議明文傳輸的缺陷，它通過以下兩方面保證數據傳輸的機密性：
?????????????? 在通信雙方之間建立加密通道，保證傳輸的數據不被切聽；
?????????????? 使用密鑰交換算法保證密鑰本身的安全。
所謂加密通道，是指發送方在發送數據前，使用加密密鑰對數據進行加密，然后將數據發送給對方；接收方接收到數據后，利用解密密鑰從密文中獲取明文。
加解密算法分為兩類：
?????????????? 對稱密鑰算法：數據加密和解密時使用相同的密鑰和相同的算法。
?????????????? 非對稱密鑰算法：數據加密和解密時使用不同的密鑰，一個是公開的公鑰，一個是由用戶秘密保存的私鑰。
由于非對稱密鑰算法比較耗時，一般多用于數字簽名以及身份認證。SSH加密通道上的數據加解密使用對稱密鑰算法，目前主要支持的算法有DES、3DES、AES等，這些算法都可以有效地防止交互數據被切聽，而且由于采用了初始化向量保護，可以防止類似于密碼流復用等密碼分析工具的攻擊。
對稱密鑰算法要求解密密鑰和加密密鑰完全一 致，才能順利從密文中解密得到明文。因此，要建立加密通道，必須先在通信雙方部署一致的加解密密鑰。部署加解密密鑰的方式有多種：手工配置和第三方機構分 配等。手工配置的方式擴展性差，只適合一些小型的本地網絡；使用第三方機構分配密鑰的方式，需要額外的第三方服務器，而且密鑰在網絡中傳輸容易被切聽。
SSH協議使用一種安全的方式在通信雙方部署密鑰：密鑰交換算法。利用密鑰交換算法可以在通信雙方動態地產生密鑰，這個密鑰只能被通信的雙方獲得，任何第三者都無法切聽，這就在源頭上保證了加解密使用密鑰的安全性，很好地解決了密鑰分發問題。
密鑰交換算法的基本原理是：
(1)??????? 客戶端隨機選擇一個私鑰Xc，1<Xc<p-1，計算出Yc=g^Xc mod p，將計算出的Yc發送給服務器端。其中，p是一個很大的素數，g是p的素根。p和g是雙方共有的一對參數，協議允許雙方通過協商獲得相同的p和g參數。
(2)??????? 服務器也隨機生成一個私鑰Xs，1<Xs<p-1，計算出Ys＝g^Xs mod p，也將計算出的Ys發送給客戶端。
(3)??????? 服務器接收到客戶端發送過來的Yc，按照下面的公式計算出密鑰：
K ＝ （Yc）^Xs mod p
(4)??????? 客戶端收到服務器端發送過來的Ys，同樣按照下面的公式計算出密鑰：
K ＝ （Ys）^Xc mod p
通過上面的方法，客戶端和服務器端就可以獲得相同的密鑰。
由上面的分析可以看出，密鑰交換算法的安全性建立在計算離散對數的難度之上。算式Y=g^x mod p中，由X計算Y是很容易的，但是要由Y計算X是非常困難的。在密鑰交換算法中對外公開的只有p、g、Yc和Ys，私鑰Xc和Xs是保密的，其他用戶即便獲取了p、g、Yc和Ys也很難推斷出私鑰Xc和Xs，從而保證了密鑰的安全性。
密鑰交換算法具有如下優勢：
?????????????? 擴展性更好，不需要網絡管理員的多余配置；
?????????????? 交換得到的密鑰是保存在內存中，不易被讀取和篡改；
?????????????? 每個連接都會動態生成一次新的密鑰，安全性更高。
3.2 用戶認證安全性
為了防止非法用戶登錄到設備，對設備進行破壞性配置，SSH協議需要支持多種用戶認證方式，提高對用戶認證的強度。常用的用戶認證方式包括密碼認證和公鑰認證，Comware V5平臺還定義了一種新的認證方式——password-publickey認證。
3.2.1 密碼認證
SSH協議可以利用AAA提供的認證功能，完成對登錄用戶進行密碼認證。根據AAA采取的認證策略的不同，密碼認證分為本地認證和遠程認證兩種方式。
本地認證
本地認證是指在SSH服務器本地保存用戶的信息，認證過程在本地完成。如圖所示，網管人員通過網絡遠程登錄到小區的網關設備上，對設備進行相關配置。網關設備作為SSH服務器根據AAA本地用戶數據庫中的用戶信息對登錄用戶進行身份認證。
遠程認證
遠程認證是指將用戶信息保存在遠端的RADIUS等認證服務器上，認證過程在本地設備和遠程認證服務器之間完成。如圖所示，網絡管理員通過網絡遠程登錄到小區的網關設備上，對網關設備進行配置。網關設備作為SSH服務器，將登錄用戶的認證信息，傳遞到遠程認證服務器（如RADIUS服務器）上，根據認證服務器返回的對該用戶的認證結果決定是否允許該用戶登錄。
采用遠程認證方式可以將某個區域內所有用戶的配置、管理都集中到遠程認證服務器上，便于對用戶的集中管理。此外，用戶的身份信息等關鍵數據都保存在認證服務器上，在很大程度上提高了用戶信息的安全性。
當然，采用遠程認證方式，需要保證網關設備與遠程認證服務器之間的連接是絕對安全的，這樣才能保證用戶信息的安全。
3.2.2 公鑰認證
由于密碼認證方式的認證強度較弱，SSH協議引入了公鑰認證方式。目前，設備上可以利用RSA和DSA兩種非對稱密鑰算法實現公鑰認證。
公鑰認證的過程分為兩個部分：：
(1)??????? 公鑰驗證：客戶端首先將自己本地密鑰對的公鑰部分，按照字符串格式發送到服務器。服務器使用本地保存的客戶端公鑰，與報文中攜帶的客戶端公鑰進行比較，驗證客戶端持有公鑰的正確性。
(2)??????? 數字簽名驗證：如果公鑰驗證成功，客戶端繼續使用自己本地密鑰對的私鑰部分，對特定報文進行摘要運算，將所得的結果（即數字簽名）發送給服務器，向服務器證明自己的身份；服務器使用預先配置的該用戶的公鑰，對客戶端發送過來的數字簽名進行驗證。
公鑰驗證和數字簽名驗證中任何一個驗證失敗，都會導致本次公鑰認證失敗。
公鑰認證具有以下優勢：
?????????????? 認證強度高，不易受到“暴力猜測”等攻擊方式的影響。
?????????????? 具有較高的易用性。一次配置成功后，后續認證過程自動完成，不需要用戶記憶和輸入密碼。
但是，公鑰認證還存在以下缺點：
?????????????? 公鑰認證配置比密碼認證復雜。
?????????????? 公鑰認證只能區分私鑰，如果要實現充分的“粒度”，則必須為每一個用戶創建一個私鑰，相應地需要在服務器上為每一個用戶配置對應的公鑰，對于有多個用戶使用同一個終端登錄的情況，這種方式顯然是不適合的，也是不必要的。
3.2.3 password-publickey認證
Comware V5平臺定義了一種新的認證方式：password-publickey認證，這種認證方式要求用戶同時完成公鑰認證和密碼認證，只有兩種認證都成功后，才能通過服務器端的認證。
password-publickey認證方式充分利用了密碼認證和公鑰認證的優勢，具有如下優點：
?????????????? 同時要求用戶進行兩種認證，安全性更高。在公鑰上綁定密碼，可以防止由于SSH客戶端上的安全性隱患，影響到SSH服務器的安全性。
?????????????? 可以在一對公私密鑰對的基礎上，通過設置不同的密碼，配置不同的用戶，為這些用戶設置不同的權限，方便了管理員的配置。
?????????????? 既利用了公鑰認證的安全性，又節約了存儲成本和配置成本。公鑰認證實現方案中，要實現對用戶認證的充分“粒度”，就必須為每個用戶都配置一對密鑰對，在password-publickey認證方式，多個用戶可以共用一對密鑰對。
?????????????? 在公鑰認證技術上應用密碼認證，結合Comware V5原有實現（結合AAA實現對用戶的認證）可以很方便地同遠程認證服務器配合，從而利用遠程服務器上的諸多功能。
3.3 對“偽服務器欺騙”的防御
用戶認證機制只實現了服務器端對客戶端的認證，而客戶端無法認證服務器端，因此存在著“偽服務器欺騙”的安全隱患。
如圖所示，當客戶端主機需要與服務器建立連接時，第三方攻擊者冒充真正的服務器，與客戶端進行數據交互，竊取客戶端主機的安全信息，并利用這些信息去登錄真正的服務器，獲取服務器資源，或對服務器進行攻擊。
為了防止類似這樣的偽服務器欺騙，SSH協議支持客戶端對服務器端進行認證。服務器端在密鑰交換階段，使用自己的私鑰對一段固定格式的數據進行數字簽名，并將該簽名發往客戶端，客戶端使用本地保存的服務器公鑰，對簽名進行鑒別，從而達到認證服務器的目的。
客戶端對服務器進行認證的基礎是本端存儲的服務器公鑰是真實服務器的公鑰。因此，需要保證客戶端獲取的服務器公鑰是正確的。目前，Comware V5支持兩種獲取服務器公鑰的方式：
?????????????? 手工配置：既通過手工命令方式，將服務器公鑰配置在本地，并在本地建立服務器名稱和公鑰之間的關聯；
?????????????? 首次認證：SSH協議交互過程中，服務器會將自己的公鑰通過協議報文發送到客戶端，Comware V5借用這個特點，允許SSH客戶端配置首次認證功能，即SSH客戶端第一次登錄SSH服務器時，可以從協議報文中獲該服務器端公鑰并保存到本地，作為后續認證的依據。
4 SSH協議過程
SSH的報文交互主要有以下幾個階段：
?????????????? 連接建立
?????????????? 版本協商
?????????????? 算法協商
?????????????? 密鑰交換
?????????????? 用戶認證
?????????????? 服務請求
?????????????? 數據傳輸和連接關閉
4.1 連接建立
SSH服務器端在22端口偵聽客戶端的連接請求，接收到客戶端的連接建立請求后，與客戶端進行三次握手，建立起一條TCP連接，后續的所有報文交互都在這個TCP連接之上進行。
4.2 協商版本
TCP連接建立之后，服務器和客戶端都會向對端發送自己支持的版本號。服務器端和客戶端收到對端發送過來的版本后，與本端的版本號進行比較，雙方都支持的最高版本號即為協商出的版本號。
本協商成功后，進入下一個階段，即算法協商階段。否則，中斷連接。
?? 說明：
SSH1.99為特殊的版本號，這個版本既可以與SSH2.0版本互通，又可以與SSH1.5版本互通。
4.3 算法協商
SSH協議報文交互需要使用多種算法：
?????????????? 用于產生會話密鑰的密鑰交換算法，包括diffie-hellman-group-exchange-sha1、diffie-hellman-group1-sha1和diffie-hellman-group14-sha1算法等。
?????????????? 用于數據信息加密的加密算法，包括3des-cbc、aes128-cbc和des-cbc加密算法等。
?????????????? 用于進行數字簽名和認證的主機公鑰算法，包括RSA和DSA公鑰算法等。
?????????????? 用于數據完整性保護的MAC算法，包括hmac-md5、hmac-md5-96、hmac-sha1和hmac-sha1-96算法等。
由于各種客戶端和服務器對這些算法的支持情況不一樣，因此需要通過算法協商階段，使客戶端和服務器協商出雙方都支持的算法。
SSH協議的算法協商過程為：
(1)??????? 客戶端和服務器端都將自己支持的算法列表發送給對方；
(2)??????? 雙 方依次協商每一種算法（密鑰交換算法、加密算法等）。每種算法的協商過程均為：從客戶端的算法列表中取出第一個算法，在服務器端的列表中查找相應的算法， 如果匹配上相同的算法，則該算法協商成功；否則繼續從客戶端算法列表中取出下一個算法，在服務器端的算法列表中匹配，直到匹配成功。如果客戶端支持的算法 全部匹配失敗，則該算法協商失敗。
(3)??????? 某一種算法協商成功后，繼續按照上述方法協商其他的算法，直到所有算法都協商成功；如果某一種算法協商失敗，則客戶端和服務器之間的算法協商失敗，服務器斷開與客戶端的連接。
以加密算法為例，算法的協商方式為：
表1 加密算法協商舉例
客戶端的加密算法列表 服務端的加密算法列表 最后協商出的加密算法
3des、3des-cbc、aes128-cbc aes128-cbc、3des-cbc、des-cbc 3des-cbc
4.4 密鑰交換
加密算法協商成功后，為了保證加解密密鑰的安全性，SSH利用密鑰交換算法在通信雙方安全動態地生成和交互數據的加解密密鑰，并能夠有效防止第三方切聽加解密密鑰。密鑰交換算法的詳細介紹請參見“3.1.2? 使用密鑰交換算法保證密鑰本身的安全”。
4.5 用戶認證
密鑰交換完成之后，進入用戶認證階段。
用戶認證過程
如圖5所示，用戶認證過程為：
(1)??????? 客戶端向服務器端發送認證請求報文，其中攜帶的認證方式為“none”。
(2)??????? 服務器收到none方式認證請求，回復認證挑戰報文，其中攜帶服務器支持、且需要該用戶完成的認證方式列表。
(3)??????? 客戶端從服務器發送給自己的認證方式列表中選擇某種認證方式，向服務器發起認證請求，認證請求中包含用戶名、認證方法、與該認證方法相關的內容：
?????????????? 密碼認證方式中，內容為用戶的密碼；
?????????????? 公鑰認證方式中，內容為用戶本地密鑰對的公鑰部分（公鑰驗證階段）或者數字簽名（數字簽名驗證階段）。
(4)??????? 服務器接收到客戶端的認證請求，驗證客戶端的認證信息：
?????????????? 密碼認證方式：服務器將客戶端發送的用戶名和密碼信息，與設備上或者遠程認證服務器上保存的用戶名和密碼進行比較，從而判斷認證成功或失敗。
?????????????? 公鑰認證方式：服務器對公鑰進行合法性檢查，如果不合法，則認證失敗；否則，服務器利用數字簽名對客戶端進行認證，從而判斷認證成功或失敗。
(5)??????? 服務器根據本端上該用戶的配置，以及用戶認證的完成情況，決定是否需要客戶端繼續認證，分為以下幾種情況：
?????????????? 如果該種認證方式認證成功，且該用戶不需要繼續完成其他認證，則服務器回復認證成功消息，認證過程順利完成。
?????????????? 如果該種認證方式認證成功，但該用戶還需要繼續完成其他認證，則回復認證失敗消息，繼續向客戶端發出認證挑戰，在報文中攜帶服務器需要客戶端繼續完成的認證方式列表；
?????????????? 如果該種認證方式認證失敗，用戶的認證次數尚未到達認證次數的最大值，服務器繼續向客戶端發送認證挑戰；
?????????????? 如果該種認證方式認證失敗，且用戶的認證次數達到認證次數的最大值，用戶認證失敗，服務器斷開和客戶端之間的連接。
?? 說明：
認證挑戰是指SSH服務器將用戶需要完成的認證方式列表發送給用戶，要求用戶從中選擇一種，繼續發起認證請求。用戶未完成認證時，服務器都會通過這種發送認證列表的方式，要求用戶進行認證。
4.6 服務請求
SSH協議支持多種應用服務。用戶成功完成認證后，SSH客戶端向服務器端發起服務請求，請求服務器提供某種應用。
服務請求的過程為：
(1)??????? 客戶端發送SSH_MSG_CHANNEL_OPEN消息，請求與服務器建立會話通道，即session；
(2)??????? 服務器端收到SSH_MSG_CHANNEL_OPEN消息后，如果支持該通道類型，則回復SSH_MSG_CHANNEL_OPEN_CONFIRMATION消息，從而建立會話通道；
(3)??????? 會話通道建立之后，客戶端可以申請在通道上進行shell或subsystem類型的會話，分別對應SSH和SFTP兩種類型的服務。
4.7 數據傳輸和連接關閉
服務請求成功，建立會話后，服務器和客戶端可以在該會話上進行數據的傳輸。客戶端將要執行的命令加密后傳給服務器，服務器接收到報文，解密后執行該命令，將執行的結果加密發送給客戶端，客戶端將接收到的結果解密后顯示到終端上。
通信結束或用戶空閑時間超時后，關閉會話，斷開連接。
**************************
未完待續
參考：ssh技術白皮書 ssh協議詳解
????
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
