SSH的英文全稱爲Secure Shell，是IETF（Internet Engineering Task Force）的Network Working Group所制定的一族協議，其目的是要在非安全網絡上提供安全的遠程登錄和其他安全網絡服務。 我們可以簡單理解爲：Rlogin和Telnet等的替代方案。SSH的使用場景如下圖所示，具體請參考下文SSH的框架。
SSH 基本框架
SSH協議框架中最主要的部分是三個協議：
- 傳輸層協議
- 用戶認證協議
- 連接協議
同時SSH協議框架中還爲許多高層的網絡安全應用協議提供擴展的支持。它們之間的層次關係可以用如下圖來表示：![]()
- 傳輸層協議（The Transport Layer Protocol）提供服務器認證，數據機密性，信息完整性 等的支持；
- 用戶認證協議（The User Authentication Protocol） 則爲服務器提供客戶端的身份鑑別；
- 連接協議（The Connection Protocol） 將加密的信息隧道複用成若干個邏輯通道，提供給更高層的應用協議使用； 各種高層應用協議可以相對地獨立於SSH基本體系之外，並依靠這個基本框架，通過連接協議使用SSH的安全機制。
SSH安全驗證級別
- 第一種級別(基於口令的安全驗證),只要你知道自己帳號和口令，就可以登錄到遠程主機。所有傳輸的數據都會被加密，但是不能保證你正在連接的服務器就是你想連接的服務器。可能會有別的服務器在冒充真正的服務器，也就是受到“中間人”這種方式的攻擊。
- 第二種級別(基於密匙的安全驗證)需要依靠密匙
- 先爲自己創建一對密匙，並把公匙放在需要訪問的服務器上；
- 客戶端軟件會向服務器發出請求，請求用你的密匙進行安全驗證；
- 服務器收到請求之後，在該服務器目錄下尋找公匙，然後把它和你發送過來的公匙進行比較。若兩密匙一致，服務器就用公匙加密“質詢”(challenge)並把它發送給客戶端軟件；
- 客戶端軟件收到“質詢”之後就可以用 私密 解密再把它發送給服務器。
用這種方式，你必須知道自己密匙的口令。但是，與第一種級別相比，第二種級別不需要在網絡上傳送口令，它不僅加密所有傳送的數據，而且“中間人”這種攻擊方式也是不可能的(因爲他沒有你的私人密匙)。但是整個登錄的過程可能需要10秒。
SSH 的工作過程
在整個通訊過程中，爲實現 SSH的安全連接，服務器端與客戶端要經歷如下五個階段：
- 版本號協商階段，SSH目前包括 SSH1和SSH2兩個版本， 雙方通過版本協商確定使用的版本
- 密鑰和算法協商階段，SSH支持多種加密算法， 雙方根據本端和對端支持的算法，協商出最終使用的算法
- 認證階段，SSH客戶端向服務器端發起認證請求， 服務器端對客戶端進行認證
- 會話請求階段， 認證通過後，客戶端向服務器端發送會話請求
- 交互會話階段 ，會話請求通過後，服務器端和客戶端進行信息的交互
1 . 版本號協商階段
- 服務器打開端口 22，等待客戶端連接。
- 客戶端向服務器端發起 TCP初始連接請求，TCP連接建立後，服務器向客戶端發送第一個報文，包括版本標誌字符串，格式爲“SSH－<主協議版本號>.<次協議版本號>－<軟件版本號>”，協議版本號由主版本號和次版本號組成，軟件版本號主要是爲調試使用。
- 客戶端收到報文後，解析該數據包，如果服務器端的協議版本號比自己的低，且客戶端能支持服務器端的低版本，就使用服務器端的低版本協議號，否則使用自己的協議版本號。
- 客戶端迴應服務器一個報文，包含了客戶端決定使用的協議版本號。服務器比較客戶端發來的版本號，決定是否能同客戶端一起工作。
- 如果協商成功，則進入密鑰和算法協商階段，否則服務器端斷開 TCP連接。
Note： 版本號協商階段報文都是採用明文方式傳輸的。
2. 密鑰和算法協商階段
- 服務器端和客戶端分別發送算法協商報文給對端，報文中包含自己支持的公鑰算法列表、加密算法列表、MAC（Message Authentication Code，消息驗證碼）算法列表、壓縮算法列表等;
- 服務器端和客戶端根據對端和本端支持的算法列表得出最終使用的算法。
- 服務器端和客戶端利用 DH交換（Diffie-Hellman Exchange）算法、主機密鑰對等參數，生成會話密鑰和會話 ID。
通過以上步驟，服務器端和客戶端就取得了相同的會話密鑰和會話ID。- 對於後續傳輸的數據，兩端都會使用會話密鑰進行加密和解密，保證了數據傳送的安全
- 在認證階段，兩端會使用會話 ID用於認證過程。
Note：
在協商階段之前，服務器端已經生成 RSA或 DSA密鑰對，他們主要用於參與會話密鑰的生成。
3. 認證階段
- 客戶端向服務器端發送認證請求，認證請求中包含用戶名、認證方法、與該認證方法相關的內容（如：password認證時，內容爲密碼）。
- 服務器端對客戶端進行認證，如果認證失敗，則向客戶端發送認證失敗消息，其中包含可以再次認證的方法列表。
- 客戶端從認證方法列表中選取一種認證方法再次進行認證。
- 該過程反覆進行， 直到認證成功或者認證次數達到上限， 服務器關閉連接爲止。
SSH提供兩種認證方式：
- password認證：客戶端向服務器發出 password認證請求，將用戶名和密碼加密後發送給服務器；服務器將該信息解密後得到用戶名和密碼的明文，與設備上保存的用戶名和密碼進行比較，並返回認證成功或失敗的消息。
- publickey 認證：採用數字簽名的方法來認證客戶端。目前，設備上可以利用RSA和 DSA兩種公共密鑰算法實現數字簽名。客戶端發送包含用戶名、公共密鑰和公共密鑰算法的 publickey 認證請求給服務器端。服務器對公鑰進行合法性檢查，如果不合法，則直接發送失敗消息；否則，服務器利用數字簽名對客戶端進行認證，並返回認證成功或失敗的消息
SSH2.0還提供了 password-publickey 認證和 any 認證:
- password-publickey 認證：指定該用戶的認證方式爲 password 和 publickey認證同時滿足。客戶端版本爲 SSH1的用戶只要通過其中一種認證即可登錄；客戶端版本爲 SSH2的用戶必須兩種認證都通過才能登錄。
- any認證：指定該用戶的認證方式可以是 password，也可以是 publickey。
4.會話請求階段
- 服務器等待客戶端的請求；
- 認證通過後，客戶端向服務器發送會話請求；
- 服務器處理客戶端的請求。請求被成功處理後， 服務器會向客戶端迴應 SSH_SMSG_SUCCESS包，SSH進入交互會話階段；否則迴應 SSH_SMSG_FAILURE包，表示服務器處理請求失敗或者不能識別請求。
5.交互會話階段
在這個模式下，數據被雙向傳送：
- 客戶端將要執行的命令加密後傳給服務器;
- 服務器接收到報文，解密後執行該命令,將執行的結果加密發還給客戶端;
- 客戶端將接收到的結果解密後顯示到終端上.
6.SSH Q & A
Q1: SSH的版本和區別。
SSH2避免了RSA的專利問題，並修補了CRC的缺陷。SSH2用數字簽名算法（DSA）和Diffie-Hellman（DH）算法代替RSA來完成對稱密鑰的交換，用HMAC來代替CRC。同時SSH2增加了AES和Twofish等對稱加密算法。
A1: SSH(Secure SHell)到目前爲止有兩個不兼容的版本——SSH1和SSH2。SSH1又分爲1.3和1.5兩個版本。SSH1採用DES、3DES、Blowfish和RC4等對稱加密算法保護數據安全傳輸，而對稱加密算法的密鑰是通過非對稱加密算法（RSA）來完成交換的。SSH1使用循環冗餘校驗碼（CRC）來保證數據的完整性，但是後來發現這種方法有缺陷。
更多內容請參考The SSHv1 Protocol & The SSHv2 Protocol
Q2: 什麼是HMAC？
A2: HMAC(Hash Message Authentication Code) ，散列消息鑑別碼，基於密鑰的Hash算法的認證協議。消息鑑別碼實現鑑別的原理是，用公開函數和密鑰產生一個固定長度的值作爲認證標識，用這個標識鑑別消息的完整性。使用一個密鑰生成一個固定大小的小數據塊，即MAC，並將其加入到消息中，然後傳輸。接收方利用與發送方共享的密鑰進行鑑別認證等。
Q3: 什麼是X11 forwarding？
A3: sh的X11 forwarding特性可以使X client和X server安全地通訊。使用X11 forwarding後，從X client到X Server方向的數據先被送至ssh server，ssh server利用和ssh client的安全通道轉發給ssh client，再由ssh client轉發給X server，從X server到X client的數據流同理。這裏ssh server和ssh client充當了X client和X server間數據的轉發器，由於ssh server和X client、ssh client和X server一般在同一臺機器上，它們之間是一種安全的進程間通訊，而ssh server和ssh client間的通訊也是安全的，所以X client和X server間的通訊就是安全的。
Q4: 什麼是TTY？
A4: 終端是一種字符型設備，它有多種類型，通常使用tty來簡稱各種類型的終端設備。tty是 Teletype的縮寫。Teletype是最早出現的一種終端設備，很象電傳打字機，是由Teletype公司生產的。設備名放在特殊文件目錄/dev/下。
Q5: 簡單描述下SSH運行的過程？
A5:簡要過程如下：
- Client端向Server端發起SSH連接請求。
- Server端向Client端發起版本協商。
- 協商結束後Server端發送Host Key公鑰 Server Key公鑰，隨機數等信息。到這裏所有通信是不加密的。
- Client端返回確認信息，同時附帶用公鑰加密過的一個隨機數，用於雙方計算Session Key。
- 進入認證階段。從此以後所有通信均加密。
- 認證成功後，進入交互階段。
