SSH(Secure Shell)協議簡介

概念

SSH是指Secure Shell，SSH協議族由IETF（Internet Engineering Task Force）的Network Working Group制定，SSH協議的內容SSH協議是建立在應用程式層和傳輸層基礎上的安全性通訊協定。
傳統的網路服務程式，如FTP、Pop和Telnet其本質上都是不安全的；因為它們在網路上用明文傳送資料、使用者帳號和使用者口令，很容易受到中間人（man-in-the-middle）攻擊方式的攻擊。就是存在另一個人或者一台機器冒充真正的伺服器接收使用者傳給伺服器的資料，然後再冒充使用者把資料傳給真正的伺服器。
SSH(Secure Shell)是目前比較可靠的為遠程登入工作階段和其他網路服務提供安全性的協議。利用SSH協議可以有效防止遠端管理過程中的資訊泄露問題。通過SSH，可以把所有傳輸的資料進行加密，也能夠防止DNS欺騙和IP欺騙。
SSH，還有一個額外的好處就是傳輸的資料是經過壓縮的，所以可以加快傳輸的速度。SSH有很多功能，它既可以代替Telnet，又可以為FTP、Pop、甚至為PPP提供一個安全的"通道"。

協議曆史

最初的SSH協議是由芬蘭的一家公司開發的。但是因為受著作權和密碼編譯演算法等等的限制，現在很多人都轉而使用OpenSSH。OpenSSH是SSH的替代軟體包，而且是免費的。

基本架構

SSH協議架構中最主要的部分是三個協議：

1.傳輸層協議
傳輸層協議（The Transport Layer Protocol）提供伺服器認證，資料機密性，資訊完整性 等的支援
2.使用者認證協議
使用者認證協議（The User Authentication Protocol） 則為伺服器提供用戶端的身份鑒別；
3.連線協定
連線協定（The Connection Protocol）將加密的資訊隧道複用成若干個邏輯通道，提供給更高層的應用協議使用；
4.同時還有為許多高層的網路安全應用協議提供擴充的支援。
各種高層應用協議可以相對地獨立於SSH基本體系之外，並依靠這個基本架構，通過連線協定使用SSH的安全機制。

SSH的安全驗證

在用戶端來看，SSH提供兩種層級的安全驗證。

第一種層級（基於口令的安全驗證），知道帳號和口令，就可以登入到遠程主機，並且所有傳輸的資料都會被加密。但是，可能會有別的伺服器在冒充真正的伺服器，無法避免被‘中間人’攻擊。
第二種層級（基於密匙的安全驗證），需要依靠密匙，也就是你必須為自己建立一對密匙，並把公有密匙放在需要訪問的伺服器上。用戶端軟體會向伺服器發出請求，請求用你的密匙進行安全驗證。伺服器收到請求之後，先在你在該伺服器的使用者根目錄下尋找你的公有密匙，然後把它和你發送過來的公有密匙進行比較。如果兩個密匙一致，伺服器就用公有密匙加密"質詢"（challenge）並把它發送給用戶端軟體。從而避免被‘中間人’攻擊。
在伺服器端，SSH也提供安全驗證。
在第一種方案中，主機將自己的公用密鑰分發給相關的客戶機，客戶機在訪問主機時則使用該主機的公開密鑰來加密資料，主機則使用自己的私人密鑰來解密資料，從而實現主機密鑰認證，確定客戶機的可靠身份。
在第二種方案中，存在一個密鑰認證中心，所有提供服務的主機都將自己的公開密鑰提交給認證中心，而任何作為客戶機的主機則只要儲存一份認證中心的公開密鑰就可以了。在這種模式下，客戶機必須訪問認證中心然後才能訪問伺服器主機。

 

SSH 的工作過程
在整個通訊過程中，為實現 SSH的安全連線，伺服器端與用戶端要經曆如下五個階段：

1、版本號碼協商階段，SSH目前包括 SSH1和SSH2兩個版本， 雙方通過版本協商確定使用的版本
2、密鑰和演算法協商階段，SSH支援多種密碼編譯演算法， 雙方根據本端和對端支援的演算法，協商出最終使用的演算法
3、認證階段，SSH用戶端向伺服器端發起認證請求， 伺服器端對用戶端進行認證
4、會話要求階段， 認證通過後，用戶端向伺服器端發送會話請求
5、互動會話階段 ，會話請求通過後，伺服器端和用戶端進行資訊的互動 
1 . 版本號碼協商階段
1、伺服器開啟連接埠 22，等待用戶端串連。
2、用戶端向伺服器端發起 TCP初始串連請求，TCP串連建立後，伺服器向用戶端發送第一個報文，包括版本標誌字串，格式為“SSH－<主協議版本號碼>.<次協議版本號碼>－<軟體版本號碼>”，協議版本號碼由主要版本號和次版本號碼組成，軟體版本號碼主要是為調試使用。
3、用戶端收到報文後，解析該資料包，如果伺服器端的協議版本號碼比自己的低，且用戶端能支援伺服器端的低版本，就使用伺服器端的低版本協議號，否則使用自己的協議版本號碼。
4、用戶端回應伺服器一個報文，包含了用戶端決定使用的協議版本號碼。伺服器比較用戶端發來的版本號碼，決定是否能同用戶端一起工作。
5、如果協商成功，則進入密鑰和演算法協商階段，否則伺服器端斷開 TCP串連。
Note： 版本號碼協商階段報文都是採用明文方式傳輸的。

2. 密鑰和演算法協商階段
1、伺服器端和用戶端分別發送演算法協商報文給對端，報文中包含自己支援的公開金鑰演算法列表、密碼編譯演算法列表、MAC（Message Authentication Code，訊息驗證碼）演算法列表、壓縮演算法列表等;
2、伺服器端和用戶端根據對端和本端支援的演算法列表得出最終使用的演算法。
3、伺服器端和用戶端利用 DH交換（Diffie-Hellman Exchange）演算法、主機金鑰組等參數，產生工作階段金鑰和會話 ID。

通過以上步驟，伺服器端和用戶端就取得了相同的工作階段金鑰和會話ID。
對於後續傳輸的資料，兩端都會使用工作階段金鑰進行加密和解密，保證了資料傳送的安全
在認證階段，兩端會使用會話 ID用於認證過程。 
      Note：

             在協商階段之前，伺服器端已經產生 RSA或 DSA金鑰組，他們主要用於參與工作階段金鑰的產生。

3. 認證階段
1、用戶端向伺服器端發送認證請求，認證請求中包含使用者名稱、認證方法、與該認證方法相關的內容（如：password認證時，內容為密碼）。
2、伺服器端對用戶端進行認證，如果認證失敗，則向用戶端發送認證失敗訊息，其中包含可以再次認證的方法列表。
用戶端從認證方法列表中選取一種認證方法再次進行認證。
該過程反覆進行， 直到認證成功或者認證次數達到上限， 伺服器關閉串連為止。
SSH提供兩種認證方式：
password認證：用戶端向伺服器發出 password認證請求，將使用者名稱和密碼加密後發送給伺服器；伺服器將該資訊解密後得到使用者名稱和密碼的明文，與裝置上儲存的使用者名稱和密碼進行比較，並返回認證成功或失敗的訊息。
publickey 認證：採用數位簽章的方法來認證用戶端。目前，裝置上可以利用RSA和 DSA兩種公用密鑰演算法實現數位簽章。用戶端發送包含使用者名稱、公用密鑰和公用密鑰演算法的 publickey 認證請求給伺服器端。伺服器對公開金鑰進行合法性檢查，如果不合法，則直接發送失敗訊息；否則，伺服器利用數位簽章對用戶端進行認證，並返回認證成功或失敗的訊息
SSH2.0還提供了 password-publickey 認證和 any 認證:
password-publickey 認證：指定該使用者的認證方式為 password 和 publickey認證同時滿足。用戶端版本為 SSH1的使用者只要通過其中一種認證即可登入；用戶端版本為 SSH2的使用者必須兩種認證都通過才能登入。
any認證：指定該使用者的認證方式可以是 password，也可以是 publickey。
4.會話要求階段
1、伺服器等待用戶端的請求；
2、認證通過後，用戶端向伺服器發送會話請求；
3、伺服器處理用戶端的請求。請求被成功處理後， 伺服器會向用戶端回應 SSH_SMSG_SUCCESS包，SSH進入互動會話階段；否則回應 SSH_SMSG_FAILURE包，表示伺服器處理請求失敗或者不能識別請求。

 
5.互動會話階段
在這個模式下，資料被雙向傳送： 用戶端將要執行的命令加密後傳給伺服器; 伺服器接收到報文，解密後執行該命令,將執行的結果加密發還給用戶端; 用戶端將接收到的結果解密後顯示到終端上.

SSH協議的可擴充能力

SSH協議架構中設計了大量可擴充的冗餘能力，比如使用者自訂演算法、客戶自訂密鑰規則、高層擴充功能性應用協議。這些擴充大多遵循IANA（Internet Assigned Numbers Authority）的有關規定，特別是在重要的部分，象命名規則和訊息編碼方面。