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