- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- BOB登陆 人才研學中心
- 關於我們
SSH技術白皮書
關鍵詞：SSH、SFTP、RSA、DSA、DES、AES、AAA
摘 要：SSH協議是一種在不安全的網絡環境中，通過加密和認證機製，實現安全的遠程訪問以及文件傳輸等業務的網絡安全協議。本文介紹了SSH的產生背景、安全機製、工作過程及組網應用，並重點描述了Comware實現的技術特色。
縮略語：
縮略語 | 英文全名 | 中文解釋 |
AAA | Authentication, Authorization, Accounting | 認證、授權、計費 |
AES | Advanced Encryption Standard | 高級加密標準 |
DES | Data Encryption Standard | 數據加密標準 |
DSA | Digital Signature Algorithm | 數字簽名算法，非對稱密鑰算法的一種 |
FTP | File Transfer Protocol | 文件傳輸協議 |
MAC | Message Authentication Code | 消息驗證碼 |
RSA | Rivest Shamir and Adleman | 非對稱密鑰算法的一種 |
SFTP | Secure File Transfer Protocol | 安全的文件傳輸協議 |
SSH | Secure Shell | 安全外殼 |
Stelnet | Secure Telnet | 安全的Telnet |
SSH協議出現之前，在網絡設備管理上廣泛應用的一種方式是Telnet。
Telnet協議的優勢在於通過它可以遠程地登錄到網絡設備上，對網絡設備進行配置，為網絡管理員異地管理網絡設備提供了極大的方便。
但是，Telnet協議存在三個致命的弱點：
l 數據傳輸采用明文方式，傳輸的數據沒有任何機密性可言。
l 認證機製脆弱。用戶的認證信息在網絡上以明文方式傳輸，很容易被竊聽；Telnet隻支持傳統的密碼認證方式，很容易被攻擊。
l 客戶端無法真正識別服務器的身份，攻擊者很容易進行“偽服務器欺騙”。
SSH協議正是為了克服Telnet協議存在的問題而誕生的。
網絡中另外一個廣泛應用的協議——FTP，也麵臨著和Telnet相同的問題。為了解決FTP應用中的安全性問題，在SSH協議基礎上擴展了對FTP安全性的支持，即SFTP。
SSH協議是一種在不安全的網絡環境中，通過加密和認證機製，實現安全的遠程訪問以及文件傳輸等業務的網絡安全協議。
SSH協議具有以下一些優點：
l 數據傳輸采用密文的方式，保證信息交互的機密性；
l 用戶的認證信息以密文的方式傳輸，可以有效地防止用戶信息被竊聽；
l 除了傳統的密碼認證，SSH服務器還可以采用多種方式對用戶進行認證（如安全性級別更高的公鑰認證），提高了用戶認證的強度；
l 客戶端和服務器端之間通信使用的加解密密鑰，都是通過密鑰交互過程動態生成的，可以防止對加解密密鑰的暴力猜測，安全性級別比手工配置密鑰的方式高；
l 為客戶端提供了認證服務器的功能，可以防止“偽服務器欺騙”。
圖1 SSH協議框架結構
如圖1所示，SSH協議采用客戶端/服務器架構，分為傳輸層、認證層和連接層。
傳輸層協議主要用來在客戶端和服務器之間建立一條安全的加密通道，為用戶認證、數據交互等對數據傳輸安全性要求較高的階段提供足夠的機密性保護。
傳輸層提供了如下功能：
l 數據真實性檢查
l 數據完整性檢查
l 為客戶端提供了對服務器進行認證的功能
傳輸層協議通常運行在TCP/IP連接之上（服務器端使用的知名端口號為22），也可以運行在其他任何可以信賴的數據連接之上。
認證層協議運行在傳輸層協議之上，完成服務器對登錄用戶的認證。
連接層協議負責在加密通道上劃分出若幹邏輯通道，以運行不同的應用。它運行在認證層協議之上，提供交互會話、遠程命令執行等服務。
SSH協議需要解決Telnet協議明文傳輸的缺陷，它通過以下兩方麵保證數據傳輸的機密性：
l 在通信雙方之間建立加密通道，保證傳輸的數據不被竊聽；
l 使用密鑰交換算法保證密鑰本身的安全。
所謂加密通道，是指發送方在發送數據前，使用加密密鑰對數據進行加密，然後將數據發送給對方；接收方接收到數據後，利用解密密鑰從密文中獲取明文。
加解密算法分為兩類：
l 對稱密鑰算法：數據加密和解密時使用相同的密鑰和相同的算法。
l 非對稱密鑰算法：數據加密和解密時使用不同的密鑰，一個是公開的公鑰，一個是由用戶秘密保存的私鑰。
由於非對稱密鑰算法比較耗時，一般多用於數字簽名以及身份認證。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，從而保證了密鑰的安全性。
密鑰交換算法具有如下優勢：
l 擴展性更好，不需要網絡管理員的多餘配置；
l 交換得到的密鑰是保存在內存中，不易被讀取和篡改；
l 每個連接都會動態生成一次新的密鑰，安全性更高。
& 說明：
素數和素根是離散數學中的術語，詳細定義可以參考相關書籍。
為了防止非法用戶登錄到設備，對設備進行破壞性配置，SSH協議需要支持多種用戶認證方式，提高對用戶認證的強度。常用的用戶認證方式包括密碼認證和公鑰認證，Comware V5平台還定義了一種新的認證方式——password-publickey認證。
SSH協議可以利用AAA提供的認證功能，完成對登錄用戶進行密碼認證。根據AAA采取的認證策略的不同，密碼認證分為本地認證和遠程認證兩種方式。
本地認證是指在SSH服務器本地保存用戶的信息，認證過程在本地完成。如圖2所示，網管人員通過網絡遠程登錄到小區的網關設備上，對設備進行相關配置。網關設備作為SSH服務器根據AAA本地用戶數據庫中的用戶信息對登錄用戶進行身份認證。
遠程認證是指將用戶信息保存在遠端的RADIUS等認證服務器上，認證過程在本地設備和遠程認證服務器之間完成。如圖3所示，網絡管理員通過網絡遠程登錄到小區的網關設備上，對網關設備進行配置。網關設備作為SSH服務器，將登錄用戶的認證信息，傳遞到遠程認證服務器（如RADIUS服務器）上，根據認證服務器返回的對該用戶的認證結果決定是否允許該用戶登錄。
采用遠程認證方式可以將某個區域內所有用戶的配置、管理都集中到遠程認證服務器上，便於對用戶的集中管理。此外，用戶的身份信息等關鍵數據都保存在認證服務器上，在很大程度上提高了用戶信息的安全性。
當然，采用遠程認證方式，需要保證網關設備與遠程認證服務器之間的連接是絕對安全的，這樣才能保證用戶信息的安全。
由於密碼認證方式的認證強度較弱，SSH協議引入了公鑰認證方式。目前，設備上可以利用RSA和DSA兩種非對稱密鑰算法實現公鑰認證。
公鑰認證的過程分為兩個部分：：
(1) 公鑰驗證：客戶端首先將自己本地密鑰對的公鑰部分，按照字符串格式發送到服務器。服務器使用本地保存的客戶端公鑰，與報文中攜帶的客戶端公鑰進行比較，驗證客戶端持有公鑰的正確性。
(2) 數字簽名驗證：如果公鑰驗證成功，客戶端繼續使用自己本地密鑰對的私鑰部分，對特定報文進行摘要運算，將所得的結果（即數字簽名）發送給服務器，向服務器證明自己的身份；服務器使用預先配置的該用戶的公鑰，對客戶端發送過來的數字簽名進行驗證。
公鑰驗證和數字簽名驗證中任何一個驗證失敗，都會導致本次公鑰認證失敗。
公鑰認證具有以下優勢：
l 認證強度高，不易受到“暴力猜測”等攻擊方式的影響。
l 具有較高的易用性。一次配置成功後，後續認證過程自動完成，不需要用戶記憶和輸入密碼。
但是，公鑰認證還存在以下缺點：
l 公鑰認證配置比密碼認證複雜。
l 公鑰認證隻能區分私鑰，如果要實現充分的“粒度”，則必須為每一個用戶創建一個私鑰，相應地需要在服務器上為每一個用戶配置對應的公鑰，對於有多個用戶使用同一個終端登錄的情況，這種方式顯然是不適合的，也是不必要的。
Comware V5平台定義了一種新的認證方式：password-publickey認證，這種認證方式要求用戶同時完成公鑰認證和密碼認證，隻有兩種認證都成功後，才能通過服務器端的認證。
password-publickey認證方式充分利用了密碼認證和公鑰認證的優勢，具有如下優點：
l 同時要求用戶進行兩種認證，安全性更高。在公鑰上綁定密碼，可以防止由於SSH客戶端上的安全性隱患，影響到SSH服務器的安全性。
l 可以在一對公私密鑰對的基礎上，通過設置不同的密碼，配置不同的用戶，為這些用戶設置不同的權限，方便了管理員的配置。
l 既利用了公鑰認證的安全性，又節約了存儲成本和配置成本。公鑰認證實現方案中，要實現對用戶認證的充分“粒度”，就必須為每個用戶都配置一對密鑰對，在password-publickey認證方式，多個用戶可以共用一對密鑰對。
l 在公鑰認證技術上應用密碼認證，結合Comware V5原有實現（結合AAA實現對用戶的認證）可以很方便地同遠程認證服務器配合，從而利用遠程服務器上的諸多功能。
用戶認證機製隻實現了服務器端對客戶端的認證，而客戶端無法認證服務器端，因此存在著“偽服務器欺騙”的安全隱患。
如圖4所示，當客戶端主機需要與服務器建立連接時，第三方攻擊者冒充真正的服務器，與客戶端進行數據交互，竊取客戶端主機的安全信息，並利用這些信息去登錄真正的服務器，獲取服務器資源，或對服務器進行攻擊。
為了防止類似這樣的偽服務器欺騙，SSH協議支持客戶端對服務器端進行認證。服務器端在密鑰交換階段，使用自己的私鑰對一段固定格式的數據進行數字簽名，並將該簽名發往客戶端，客戶端使用本地保存的服務器公鑰，對簽名進行鑒別，從而達到認證服務器的目的。
客戶端對服務器進行認證的基礎是本端存儲的服務器公鑰是真實服務器的公鑰。因此，需要保證客戶端獲取的服務器公鑰是正確的。目前，Comware V5支持兩種獲取服務器公鑰的方式：
l 手工配置：既通過手工命令方式，將服務器公鑰配置在本地，並在本地建立服務器名稱和公鑰之間的關聯；
l 首次認證：SSH協議交互過程中，服務器會將自己的公鑰通過協議報文發送到客戶端，Comware V5借用這個特點，允許SSH客戶端配置首次認證功能，即SSH客戶端第一次登錄SSH服務器時，可以從協議報文中獲該服務器端公鑰並保存到本地，作為後續認證的依據。詳細介紹請參見“5.2 首次認證”。
SSH的報文交互主要有以下幾個階段：
l 連接建立
l 版本協商
l 算法協商
l 密鑰交換
l 用戶認證
l 服務請求
l 數據傳輸和連接關閉
SSH服務器端在22端口偵聽客戶端的連接請求，接收到客戶端的連接建立請求後，與客戶端進行三次握手，建立起一條TCP連接，後續的所有報文交互都在這個TCP連接之上進行。
TCP連接建立之後，服務器和客戶端都會向對端發送自己支持的版本號。服務器端和客戶端收到對端發送過來的版本後，與本端的版本號進行比較，雙方都支持的最高版本號即為協商出的版本號。
& 說明：
SSH1.99為特殊的版本號，這個版本既可以與SSH2.0版本互通，又可以與SSH1.5版本互通。
版本協商成功後，進入下一個階段，即算法協商階段。否則，中斷連接。
SSH協議報文交互需要使用多種算法：
l 用於產生會話密鑰的密鑰交換算法，包括diffie-hellman-group-exchange-sha1、diffie-hellman-group1-sha1和diffie-hellman-group14-sha1算法等。
l 用於數據信息加密的加密算法，包括3des-cbc、aes128-cbc和des-cbc加密算法等。
l 用於進行數字簽名和認證的主機公鑰算法，包括RSA和DSA公鑰算法等。
l 用於數據完整性保護的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 |
加密算法協商成功後，為了保證加解密密鑰的安全性，SSH利用密鑰交換算法在通信雙方安全動態地生成和交互數據的加解密密鑰，並能夠有效防止第三方竊聽加解密密鑰。密鑰交換算法的詳細介紹請參見“3.1.2 使用密鑰交換算法保證密鑰本身的安全”。
密鑰交換完成之後，進入用戶認證階段。
如圖5所示，用戶認證過程為：
(1) 客戶端向服務器端發送認證請求報文，其中攜帶的認證方式為“none”。
(2) 服務器收到none方式認證請求，回複認證挑戰報文，其中攜帶服務器支持、且需要該用戶完成的認證方式列表。
(3) 客戶端從服務器發送給自己的認證方式列表中選擇某種認證方式，向服務器發起認證請求，認證請求中包含用戶名、認證方法、與該認證方法相關的內容：
l 密碼認證方式中，內容為用戶的密碼；
l 公鑰認證方式中，內容為用戶本地密鑰對的公鑰部分（公鑰驗證階段）或者數字簽名（數字簽名驗證階段）。
(4) 服務器接收到客戶端的認證請求，驗證客戶端的認證信息：
l 密碼認證方式：服務器將客戶端發送的用戶名和密碼信息，與設備上或者遠程認證服務器上保存的用戶名和密碼進行比較，從而判斷認證成功或失敗。
l 公鑰認證方式：服務器對公鑰進行合法性檢查，如果不合法，則認證失敗；否則，服務器利用數字簽名對客戶端進行認證，從而判斷認證成功或失敗。
(5) 服務器根據本端上該用戶的配置，以及用戶認證的完成情況，決定是否需要客戶端繼續認證，分為以下幾種情況：
l 如果該種認證方式認證成功，且該用戶不需要繼續完成其他認證，則服務器回複認證成功消息，認證過程順利完成。
l 如果該種認證方式認證成功，但該用戶還需要繼續完成其他認證，則回複認證失敗消息，繼續向客戶端發出認證挑戰，在報文中攜帶服務器需要客戶端繼續完成的認證方式列表；
l 如果該種認證方式認證失敗，用戶的認證次數尚未到達認證次數的最大值，服務器繼續向客戶端發送認證挑戰；
l 如果該種認證方式認證失敗，且用戶的認證次數達到認證次數的最大值，用戶認證失敗，服務器斷開和客戶端之間的連接。
& 說明：
認證挑戰是指SSH服務器將用戶需要完成的認證方式列表發送給用戶，要求用戶從中選擇一種，繼續發起認證請求。用戶未完成認證時，服務器都會通過這種發送認證列表的方式，要求用戶進行認證。
SSH協議支持多種應用服務。用戶成功完成認證後，SSH客戶端向服務器端發起服務請求，請求服務器提供某種應用。
服務請求的過程為：
(1) 客戶端發送SSH_MSG_CHANNEL_OPEN消息，請求與服務器建立會話通道，即session；
(2) 服務器端收到SSH_MSG_CHANNEL_OPEN消息後，如果支持該通道類型，則回複SSH_MSG_CHANNEL_OPEN_CONFIRMATION消息，從而建立會話通道；
(3) 會話通道建立之後，客戶端可以申請在通道上進行shell或subsystem類型的會話，分別對應SSH和SFTP兩種類型的服務。
服務請求成功，建立會話後，服務器和客戶端可以在該會話上進行數據的傳輸。客戶端將要執行的命令加密後傳給服務器，服務器接收到報文，解密後執行該命令，將執行的結果加密發送給客戶端，客戶端將接收到的結果解密後顯示到終端上。
通信結束或用戶空閑時間超時後，關閉會話，斷開連接。
Comware V5目前實現了SSH協議的兩種應用：SSH和SFTP。
SSH在Comware V5上也稱為Stelnet，它使用SSH協議提供的安全通道，實現對網絡設備的遠程訪問，是SSH協議最基礎的一種應用。
目前，Comware V5同時支持SSH Client和SSH Server。其中SSH Client基於SSH2.0版本的實現，而SSH Server實現了兩個版本：SSH1.5和SSH2.0版本。由於SSH1.5和SSH2.0版本是互不兼容的，所以所有基於Comware的SSH Client隻支持登錄2.0版本的服務器，而SSH Server同時兼容1.5和2.0的客戶端登錄。
SFTP利用SSH協議提供的安全通道，實現對網絡設備的遠程文件操作，是SSH協議中規定的一項擴展應用。
目前，Comware V5平台同時支持SFTP Client和SFTP Server。
為了實現客戶端第一次登錄服務器時，對服務器進行身份認證，Comware作為客戶端不僅支持以手工配置方式獲取服務器的公鑰，還支持從協議報文中獲取公鑰並保存到本地，以作為後續認證的依據，這個功能稱為首次認證。
l 如果不支持首次認證，則首次登錄服務器時，客戶端需要認證服務器的身份，這樣就要求提前在客戶端上配置登錄服務器的公鑰，否則客戶端將拒絕訪問該服務器。
l 如果支持首次認證，則當SSH客戶端首次訪問服務器，而客戶端沒有配置服務器端的主機公鑰時，用戶可以選擇繼續訪問該服務器，並選擇在客戶端保存該主機公鑰；當用戶下次訪問該服務器時，就以保存的主機公鑰來認證該服務器。
Comware上定義了新的認證方式：password-publickey認證方式。詳細介紹請參見“3.2.3 password-publickey認證”。
SSH在不安全的網絡環境中，通過協議的加密和認證機製，實現了安全的遠程訪問管理、文件操作等應用。如圖6、圖7所示，SSH客戶端既可以通過本地連接，也可以通過廣域網連接與SSH服務器建立SSH通道，實現對SSH服務器的訪問和控製。
l RFC 4251：The Secure Shell (SSH) Protocol Architecture
l RFC 4252：The Secure Shell (SSH) Authentication Protocol
l RFC 4253：The Secure Shell (SSH) Transport Layer Protocol
l RFC 4254：The Secure Shell (SSH) Connection Protocol
Copyright ©2008 杭州華三通信技術有限公司 版權所有，保留一切權利。
非經本公司書麵許可，任何單位和個人不得擅自摘抄、複製本文檔內容的部分或全部，並不得以任何形式傳播。
本文檔中的信息可能變動，恕不另行通知。
售前谘詢
售後谘詢
人工在線谘詢
