概念

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.互動會話階段
在這個模式下，資料被雙向傳送：

1. 客戶端將要執行的命令加密後傳給伺服器;
2. 伺服器接收到報文，解密後執行該命令,將執行的結果加密發還給客戶端;
3. 客戶端將接收到的結果解密後顯示到終端上.

SSH協議的可擴充套件能力

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