SSH 協議原理、組成、認證方式和過程[轉]

https://www.jianshu.com/p/8e5b7aea52b5

概述

SSH是（Secure SHell protocol） 的簡寫，安全外殼協議（SSH）是一種在不安全網絡上提供安全遠程登陸及其它安全網絡服務的協議。　　
　　OpenSSH 是SSH （Secure SHell）協議的免費開源實現。SSH協議族能夠用來進行遠程控制，或在計算機之間傳送文件。而實現此功能的傳統方式，如telnet(終端仿真協議)、 rcp ftp、 rlogin、rsh都是極爲不安全的，而且會使用明文傳送密碼。OpenSSH提供了服務端後臺程序和客戶端工具，用來加密遠程控件和文件傳輸過程的中的數據，並由此來代替原來的相似服務。
　　在過去咱們使用的rsh和telnet，由於包括登陸時的ID和密碼數據沒有加密就傳到網絡上，存在安全上的問題。即便在內部網上，也有在因特網上的竊取和篡改等危險性。SSH將包括密碼在內的全部數據都已進行了加密處理，能夠進行更安全的遠程操做。在SSH中，因爲協議標準的不一樣而存在SSH1和SSH2兩個不一樣的版本。SSH2是爲了迴避SSH1所使用的加密算法的許可證問題而開發的（如今這一許可證問題已經不存在了）。TLES 8中做爲安裝SSH協議的應用程序採用了開放源碼的OpenSSH。OpenSSH與SSH1和SSH2的任何一個協議都能對應，但默認使用SSH2。

更詳細的說明以及安裝使用，請參考官網：http://www.openssh.com/

主要功能

• 相似 telnet 的遠程聯機使用 shell 的服務器，即 ssh。
• 相似 FTP 服務的 sftp-server ，提供更安全的 FTP 服務。

SSH 功能

工做原理

ssh 工做原理

1. 服務器創建公鑰： 每一次啓動 sshd 服務時，該服務會主動去找 /etc/ssh/ssh_host* 的文件，若系統剛剛安裝完成時，因爲沒有這些公鑰，所以 sshd 會主動去計算出這些須要的公鑰，同時也會計算出服務器本身須要的私鑰。

• 客戶端主動聯機請求： 若客戶端想要聯機到 ssh 服務器，則須要使用適當的客戶端程序來聯機，包括 ssh, putty 等客戶端程序鏈接。
• 服務器傳送公鑰給客戶端： 接收到客戶端的要求後，服務器便將第一個步驟取得的公鑰傳送給客戶端使用 (此時應是明碼傳送，反正公鑰原本就是給你們使用的)。
• 客戶端記錄並比對服務器的公鑰數據及隨機計算本身的公私鑰： 若客戶端第一次鏈接到此服務器，則會將服務器的公鑰記錄到客戶端的用戶家目錄內的 ~/.ssh/known_hosts 。如果已經記錄過該服務器的公鑰，則客戶端會去比對這次接收到的與以前的記錄是否有差別。若接受此公鑰， 則開始計算客戶端本身的公私鑰。
• 回傳客戶端的公鑰到服務器端： 用戶將本身的公鑰傳送給服務器。此時服務器：具備服務器的私鑰與客戶端的公鑰，而客戶端則是： 具備服務器的公鑰以及客戶端本身的私鑰，你會看到，在這次聯機的服務器與客戶端的密鑰系統 (公鑰+私鑰) 並不同，因此才稱爲非對稱加密系統。
• 開始雙向加解密： (1)服務器到客戶端：服務器傳送數據時，拿用戶的公鑰加密後送出。客戶端接收後，用本身的私鑰解密 (2)客戶端到服務器：客戶端傳送數據時，拿服務器的公鑰加密後送出。服務器接收後，用服務器的私鑰解密，這樣就能保證通訊安全。

組成

SSH 主要有三部分組成：

1. 傳輸層協議 [SSH-TRANS] 提供了服務器認證，保密性及完整性。此外它有時還提供壓縮功能。 SSH-TRANS 一般運行在 TCP/IP鏈接上，也可能用於其它可靠數據流上。 SSH-TRANS 提供了強力的加密技術、密碼主機認證及完整性保護。該協議中的認證基於主機，而且該協議不執行用戶認證。更高層的用戶認證協議能夠設計爲在此協議之上。

• 用戶認證協議 [SSH-USERAUTH] 用於向服務器提供客戶端用戶鑑別功能。它運行在傳輸層協議 SSH-TRANS 上面。當 SSH-USERAUTH 開始後，它從低層協議那裏接收會話標識符（從第一次密鑰交換中的交換哈希 H ）。會話標識符惟一標識此會話而且適用於標記以證實私鑰的全部權。 SSH-USERAUTH 也須要知道低層協議是否提供保密性保護。
• 鏈接協議 [SSH-CONNECT] 將多個加密隧道分紅邏輯通道。它運行在用戶認證協議上。它提供了交互式登陸話路、遠程命令執行、轉發 TCP/IP 鏈接和轉發 X11 鏈接。
  　　一旦創建一個安全傳輸層鏈接，客戶機就發送一個服務請求。當用戶認證完成以後，會發送第二個服務請求。這樣就容許新定義的協議能夠與上述協議共存。鏈接協議提供了用途普遍的各類通道，有標準的方法用於創建安全交互式會話外殼和轉發（「隧道技術」）專有 TCP/IP 端口和 X11 鏈接。
  　　經過使用SSH，你能夠把全部傳輸的數據進行加密，這樣"中間人"這種攻擊方式就不可能實現了，並且也可以防止DNS欺騙和IP欺騙。使用SSH，還有一個額外的好處就是傳輸的數據是通過壓縮的，因此能夠加快傳輸的速度。SSH有不少功能，它既能夠代替Telnet，又能夠爲FTP、PoP、甚至爲PPP提供一個安全的"通道"。

• 傳輸層協議（The Transport Layer Protocol）提供服務器認證，數據機密性，信息完整性 等的支持；

• 用戶認證協議（The User Authentication Protocol） 則爲服務器提供客戶端的身份鑑別；
• 鏈接協議（The Connection Protocol） 將加密的信息隧道複用成若干個邏輯通道，提供給更高層的應用協議使用； 各類高層應用協議能夠相對地獨立於SSH基本體系以外，並依靠這個基本框架，經過鏈接協議使用SSH的安全機制。

同時SSH協議框架中還爲許多高層的網絡安全應用協議提供擴展的支持。它們之間的層次關係能夠用以下圖來表示：

SSH協議框架

認證方式

• 基於口令的認證：這個就不用說了，就是輸入用戶名和密碼
• 基於密鑰的認證，具體步驟以下:
  　　(1).客戶端創建兩把鑰匙(公鑰與私鑰)
  　　(2).將公鑰數據上傳到服務器上
  　　(3).將公鑰放置服務器端的正確目錄與文件名（scp 或 ssh-copy-id）

對於SSH這樣以提供安全通信爲目標的協議，其中必不可少的就是一套完備的密鑰機制。因爲SSH協議是面向互聯網網絡中主機之間的互訪與信息交換，因此主機密鑰成爲基本的密鑰機制。也就是說，SSH協議要求每個使用本協議的主機都必須至少有一個本身的主機密鑰對，服務方經過對客戶方主機密鑰的認證以後，才能容許其鏈接請求。一個主機可使用多個密鑰，針對不一樣的密鑰算法而擁有不一樣的密鑰，可是至少有一種是必備的，即經過 DSS算法產生的密鑰。關於DSS算法，請參考FIPS-186 文檔.SSH協議關於主機密鑰認證的管理方案有兩種，以下圖所示:

SSH主機密鑰認證

　　每個主機都必須有本身的主機密鑰，密鑰能夠有多對，每一對主機密鑰對包括公開密鑰和私有密鑰。在實際應用過程當中怎樣使用這些密鑰，並依賴它們來實現安全特性呢？如上圖所示，SSH協議框架中提出了兩種方案。
　　在第一種方案中，主機將本身的公用密鑰分發給相關的客戶機，客戶機在訪問主機時則使用該主機的公開密鑰來加密數據，主機則使用本身的私有密鑰來解密數據，從而實現主機密鑰認證，肯定客戶機的可靠身份。在圖2（a）中能夠看到，用戶從主機A上發起操做，去訪問，主機B和主機C，此時，A成爲客戶機，它必須事先配置主機B和主機C的公開密鑰，在訪問的時候根據主機名來查找相應的公開密鑰。對於被訪問主機（也就是服務器端）來講則只要保證安全地存儲本身的私有密鑰就能夠了。　
　　在第二種方案中，存在一個密鑰認證中心，全部系統中提供服務的主機都將本身的公開密鑰提交給認證中心，而任何做爲客戶機的主機則只要保存一份認證中心的公開密鑰就能夠了。在這種模式下，客戶機在訪問服務器主機以前，還必須向密鑰認證中心請求認證，認證以後纔可以正確地鏈接到目的主機上。
　　很顯然，第一種方式比較容易實現，可是客戶機關於密鑰的維護倒是個麻煩事，由於每次變動都必須在客戶機上有所體現；第二種方式比較完美地解決管理維護問題，然而這樣的模式對認證中心的要求很高，在互聯網絡上要實現這樣的集中認證，單單是權威機構的肯定就是個大麻煩，有誰可以什麼都能說了算呢？可是從長遠的發展來看，在企業應用和商業應用領域，採用中心認證的方案是必要的。
　　另外，SSH協議框架中還容許對主機密鑰的一個折中處理，那就是首次訪問免認證。首次訪問免認證是指，在某客戶機第一次訪問主機時，主機不檢查主機密鑰，而向該客戶都發放一個公開密鑰的拷貝，這樣在之後的訪問中則必須使用該密鑰，不然會被認爲非法而拒絕其訪問。

工做過程

在整個通信過程當中，爲實現 SSH的安全鏈接，服務器端與客戶端要經歷以下五個階段：
* 版本號協商階段，SSH目前包括 SSH1和SSH2兩個版本， 雙方經過版本協商肯定使用的版本
* 密鑰和算法協商階段，SSH支持多種加密算法， 雙方根據本端和對端支持的算法，協商出最終使用的算法
* 認證階段，SSH客戶端向服務器端發起認證請求， 服務器端對客戶端進行認證
* 會話請求階段， 認證經過後，客戶端向服務器端發送會話請求
* 交互會話階段 ，會話請求經過後，服務器端和客戶端進行信息的交互

1. 版本號協商階段
   　　1. 服務器打開端口 22，等待客戶端鏈接。
   　　2. 客戶端向服務器端發起 TCP初始鏈接請求，TCP鏈接創建後，服務器向客戶端發送第一個報文，包括版本標誌字符串，格式爲「SSH－<主協議版本號>.<次協議版本號>－<軟件版本號>」，協議版本號由主版本號和次版本號組成，軟件版本號主要是爲調試使用。
   　　3. 客戶端收到報文後，解析該數據包，若是服務器端的協議版本號比本身的低，且客戶端能支持服務器端的低版本，就使用服務器端的低版本協議號，不然使用本身的協議版本號。
   　　4. 客戶端迴應服務器一個報文，包含了客戶端決定使用的協議版本號。服務器比較客戶端發來的版本號，決定是否能同客戶端一塊兒工做。
   　　5. 若是協商成功，則進入密鑰和算法協商階段，不然服務器端斷開 TCP鏈接。

Note： 版本號協商階段報文都是採用明文方式傳輸的。

• 密鑰和算法協商階段
  　　1. 服務器端和客戶端分別發送算法協商報文給對端，報文中包含本身支持的公鑰算法列表、加密算法列表、MAC（Message Authentication Code，消息驗證碼）算法列表、壓縮算法列表等;
  　　2. 服務器端和客戶端根據對端和本端支持的算法列表得出最終使用的算法。
  　　3. 服務器端和客戶端利用 DH交換（Diffie-Hellman Exchange）算法、主機密鑰對等參數，生成會話密鑰和會話 ID。

  經過以上步驟，服務器端和客戶端就取得了相同的會話密鑰和會話ID。
      * 對於後續傳輸的數據，兩端都會使用會話密鑰進行加密和解密，保證了數據傳送的安全
      * 在認證階段，兩端會使用會話 ID用於認證過程。

Note：
　　在協商階段以前，服務器端已經生成 RSA或 DSA密鑰對，他們主要用於參與會話密鑰的生成。

• 認證階段
  　　1. 客戶端向服務器端發送認證請求，認證請求中包含用戶名、認證方法、與該認證方法相關的內容（如：password認證時，內容爲密碼）。
  　　2. 服務器端對客戶端進行認證，若是認證失敗，則向客戶端發送認證失敗消息，其中包含能夠再次認證的方法列表。
  　　3. 客戶端從認證方法列表中選取一種認證方法再次進行認證。
  　　4. 該過程反覆進行， 直到認證成功或者認證次數達到上限， 服務器關閉鏈接爲止。

SSH提供兩種認證方式：
　　1. password認證：客戶端向服務器發出 password認證請求，將用戶名和密碼加密後發送給服務器；服務器將該信息解密後獲得用戶名和密碼的明文，與設備上保存的用戶名和密碼進行比較，並返回認證成功或失敗的消息。
　　2. publickey 認證：採用數字簽名的方法來認證客戶端。目前，設備上能夠利用RSA和 DSA兩種公共密鑰算法實現數字簽名。客戶端發送包含用戶名、公共密鑰和公共密鑰算法的 publickey 認證請求給服務器端。服務器對公鑰進行合法性檢查，若是不合法，則直接發送失敗消息；不然，服務器利用數字簽名對客戶端進行認證，並返回認證成功或失敗的消息
SSH2.0還提供了 password-publickey 認證和 any 認證:
　　1. password-publickey 認證：指定該用戶的認證方式爲 password 和 publickey認證同時知足。客戶端版本爲 SSH1的用戶只要經過其中一種認證便可登陸；客戶端版本爲 SSH2的用戶必須兩種認證都經過才能登陸。
　　2. any認證：指定該用戶的認證方式能夠是 password，也能夠是 publickey。

• 會話請求階段

  1. 服務器等待客戶端的請求；
  2. 認證經過後，客戶端向服務器發送會話請求；
  3. 服務器處理客戶端的請求。請求被成功處理後， 服務器會向客戶端迴應 SSH_SMSG_SUCCESS包，SSH進入交互會話階段；不然迴應 SSH_SMSG_FAILURE包，表示服務器處理請求失敗或者不能識別請求。

• 交互會話階段
  在這個模式下，數據被雙向傳送：
  　　1. 客戶端將要執行的命令加密後傳給服務器;
  　　2. 服務器接收到報文，解密後執行該命令,將執行的結果加密發還給客戶端;
  　　3. 客戶端將接收到的結果解密後顯示到終端上.

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。
* 進入認證階段。今後之後全部通訊均加密。
* 認證成功後，進入交互階段。

做者：技術學習 連接：https://www.jianshu.com/p/8e5b7aea52b5 來源：簡書 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。