SSH中文文檔

標籤：

SSH中文文檔

SSH 一項建立在應用程式層和傳輸層基礎上的安全性通訊協定,用於替代安全性差的TELNET，加密安全登陸用。

SSH是目前較可靠，專為遠程登入工作階段和其他網路服務提供安全性的協議。利用SSH協議可以有效防止遠端管理過程中的資訊泄露問題。通過SSH可以對所有傳輸的資料進行加密，也能夠防止DNS欺騙和IP欺騙。

SSH之另一項優點為其傳輸的資料可以是經過壓縮的，所以可以加快傳輸的速度。SSH有很多功能，它既可以代替Telnet，又可以為FTP、POP、甚至為PPP提供一個安全的“通道”。…

這個檔案規定了互連網社區的Internet標準跟蹤協議，並請求討論和建議以得到改進。請參考“Internet正式協議標準”（STD1）本協議的標準化程度和狀態的目前的版本。本文檔的發布是不斷更新的。

摘要

安全殼層（SSH）協議是在不安全網路上提供安全的遠程登入和其他網路服務的協議，這個文檔描述了SSH協議的體繫結構, 以及在SSH協議檔案中使用的符號和術語. 它還討論了SSH演算法的命名系統，支援本地擴充（比如使用者自訂演算法、客戶自訂密鑰規則、高層擴充功能性應用協議）. SSH協議包括三個主要組件：傳輸層協議 提供伺服器認證，資料機密性，資訊完整性等的支援。使用者認證協議 為伺服器提供用戶端的身份鑒別。連線協定將加密的資訊隧道複用成若干個邏輯通道，提供給更高層的應用協議使用。 這些協議的細節被描述在單獨的檔案中。

簡介

SSH（Security Shell）是在不安全的網路上進行安全遠程登入和其他安全網路服務的協議。
它由三個主要部分組成：

○ 傳輸層協議[SSH-TRANS]提供伺服器驗證、保密性和完整性。它也可選的提供壓縮。傳輸
層一般運行在一個TCP/IP串連上，但也可能被用在任何其他可靠的資料流上。

○ 驗證協議[SSH-USERAUTH]向伺服器驗證用戶端使用者。它運行在傳輸層協議上。

○ 連線協定[SSH-CONNECT]將加密隧道複用為若干邏輯通道。它運行在驗證協議上。

在一個安全的傳輸層串連被建立後，用戶端發送一個服務要求。在使用者驗證完成後，第二個服務要求被發出。這允許新的協議被定義並與上述協議共存。

連線協定提供的通道可被用於廣泛的目的。提供了標準方法用於建立安全的互動式shell 進程以及轉寄（隧道）任意TCP/IP 連接埠和X11 串連。

本文中的慣用約定

所有與SSH協議相關的文檔都應使用關鍵詞“必須”、“禁止（絕不能）”、“必須的”、“應”、“不應”、“推薦”、“可（能）”、“可選的”來描述要求。這些關鍵詞的含義符合[RFC2119]的描述。

本文中用於描述命名空間分配的關鍵詞”PRIVATE USE”、”HIERARCHICAL ALLOCATION”、
“FIRST COME FIRST SERVED”、 “EXPERT REVIEW”、”SPECIFICATION REQUIRED”、
“IESG APPROVAL”、”IETF CONSENSUS”以及”STANDARDS ACTION”的含義符合[RFC2434]
的描述。

協議文檔中定義了協議域和可能的取值。協議域將在訊息定義中定義。例如，
SSH_MSG_CHANNEL_DATA 的定義如下：

    byte   SSH_MSG_CHANNEL_DATA      uint32   recipient channel      string   data 

在整套協議文檔中，當參考網域時，域的名稱出現在單引號中。當參考網域的值時，它們出現在雙引號中。例如，’data’的可能取值是”foo”和”bar”。

架構主機密鑰

每一個伺服器主機應有一個主機密鑰。主機可有多個使用不同演算法的主機密鑰。多個主機可共用相同的主機密鑰。如果主機具有密鑰，那麼對每一種必須的公開金鑰演算法（DSS）必須有至少一個密鑰。

伺服器主機密鑰在金鑰交換中用於檢驗用戶端真的是在和正確的伺服器對話。為使之可能，用戶端必須事Crowdsourced Security Testing道伺服器主機密鑰的公開金鑰。

兩個不同的信任模型可被使用：

○ 用戶端有一個本地的資料庫，將每個主機名稱（與使用者輸入相同）與對應的主機密鑰公開金鑰關聯起來。這種方法不需要集中管理的基礎架構或第三方的配合。缺點是主機名稱-密鑰關聯資料庫的維護可能成為一個負擔。

○ 主機名稱-密鑰關聯由一個可信的認證機構（CA）證明。用戶端只知道CA 根密鑰，並且能夠檢驗所有由CA 認證的主機密鑰的有效性。第二種方式消除了維護問題，因為理想的只有一個CA 密鑰需要被安全的儲存在用戶端。但另一方面，在進行驗證前，每個主機密鑰必須被一個中心機構以適當的方式認證。同時，中心基礎架構被寄予了極大的信任。

協議提供提供了這種選項：在第一次串連到主機時不檢查伺服器名-主機密鑰的關聯。這允許在事先不知道主機密鑰或認證的情況下進行通訊。串連仍然提供對被動偵聽（passive listening）的保護；但是，它容易受到主動的中間人攻擊（active man-in-the-middle attacks）。系統實現正常情況不應預設的允許這種串連，因其造成潛在的安全問題。但是，
由於在撰寫本文時互連網上沒有一個被廣泛部署的密鑰基礎架構，這一選項使協議在這種基礎架構出現前的過渡時期內的可用性大幅提高，同時仍然提供了比舊的解決方案（如 telnet 和rlogin）高得多的安全性。

系統實現應盡量檢查主機密鑰。一個可能的策略是：只有當第一次串連到一個主機時才不經檢查的接受主機密鑰，把密鑰儲存到本機資料庫，在將來所有的到該主機的串連中都以此為基準進行對比。

系統實現可提供附加的方法來檢驗主機密鑰的正確性，例如，通過SHA-1 雜湊從公開金鑰產生一個十六進位的數位指紋。這種數位指紋能夠很容易的用電話或其他外部通訊通道來檢驗。

所有系統實現應提供一個選項：不接受不能被檢驗的主機密鑰。

本工作群組的成員相信“易用”是終端使用者接受安全解決方案的關鍵，如果新的解決方案沒有並採用，就不會帶來任何安全性的提高。因此，提供不檢查伺服器主機密鑰的選項提高了Internet整體的安全性，儘管在允許該選項的設定中它降低了協議的安全性。

擴充性

我們相信協議將會隨時間演化，一些組織將希望使用它們自己的加密、驗證及/或密鑰互動方法。

對所有擴充進行集中註冊是繁瑣的，特別對於實驗性或保密的特性。另一方面，沒有集中註冊會導致方法標識符衝突，影響互通性。

我們選擇通過特定格式的名稱來標識演算法、方法、格式和擴充協議。DNS 名稱被用於建立本地命名空間，在其中可定義實驗性或保密的擴充而不用擔心與其他系統實現相衝突。

一個設計目標是保持基礎協議儘可能簡單，並且要求儘可能少的演算法。但是，所有系統實現必須支援一個昀小的演算法集合以保證互通性（這不表示所有主機上的本地策略要允許這些演算法）。

強制性的演算法在相關協議文檔中規定。

附加的演算法、方法、格式和擴充協議可在單獨的文檔中定義。參見第6 節，演算法命名。

策略問題

協議允許對加密、完整性、金鑰交換、壓縮以及公開金鑰演算法和格式進行完整的協商。兩個傳輸方向的加密、完整性、公開金鑰和壓縮演算法可以不同。

下列策略問題應在系統實現的配置機制中被解決：

○ 每個傳輸方向的加密、完整性和壓縮演算法。策略必須規定哪一個是優選演算法（例如，在每個類別下列出的第一個演算法）。

○ 主機驗證使用的公開金鑰演算法和金鑰交換方法。已存在的使用不同演算法的受信任的主機密鑰也影響這一選擇。

○ 伺服器對每個使用者要求的驗證方法。伺服器的策略可對一些或所有使用者要求多重認證，要求的演算法可依賴於使用者試圖獲得授權時所在的位置。

○ 使用者被允許使用連線協定進行的操作。一些問題與安全性有關；例如，策略不應允許伺服器在客戶機上啟動進程或運行命令，並且必須不允許串連到驗證代理，除非被要求轉寄這
樣的串連。另一些問題，例如誰能夠轉寄那個 TCP/IP 連接埠，非常明顯是本地策略。很多
這樣的問題可能涉及穿越或繞過防火牆，並且與本地安全性原則互相聯絡。

安全特性

SSH 協議的主要目的是改善Internet 的安全性。它嘗試通過一種容易部署的方式實現該目的，為此，甚至不惜犧牲絕對安全。

○ 所使用的所有加密、完整性，以及公開金鑰演算法都是廣為人知的、成熟的演算法。

○ 所有演算法都使用從密碼學看來合理的密鑰長度，即密鑰長度被認為能在幾十年內提供對昀強的密鑰解析攻擊的保護。

○ 所有演算法都透過協商，在某些演算法失效的情況下，可以容易的切換到其他演算法而不需要修改基礎協議。

為了使大範圍、快速的部署容易實現，協議做了特定的妥協。具體而言，在驗證伺服器主機密鑰確實屬於目標主機方面，協議允許不進行驗證，但這是不推薦的。這被認為在短期內能夠顯著的改善協議的可用性，直到出現普及的Internet 公開金鑰基礎架構。

本地化和字元集支援

在大多數情況下，SSH協議不直接傳遞會顯示給使用者的文本。但是，有些情況下這種資料可能被傳遞。當可應用時，資料的字元集必須被顯式的規定。在絕大多數情況下，使用的是ISO-10646 UTF-8 編碼[RFC3629]。當可應用時，也供了一個欄位用於語言標誌。

一個重要的問題是互動式進程的字元集。這個問題沒有清晰的解決方案，因為不同的應用軟體可能用不同的格式顯示資料。用戶端也可能使用不同類型的終端模擬，所要使用的字元集實際上是由終端模擬決定的。其結果是，沒有為直接規定終端進程資料的字元集或編碼提供位置。但是，終端模擬類型（例如，”vt100”）被傳送到遠端，它隱式的規定了字元集和編碼。應用軟體通常使用終端類型來決定使用什麼字元集，或者字元集由一些外部方法來決定。終端模擬也可能允許設定預設字元集。在任何情況下，終端進程的字元集被認為主要是一個用戶端本地問題。

用於識別演算法或協議的內部名稱一般不會顯示給使用者，而且必須採用US-ASCII。

用戶端和伺服器使用者名稱固有的受到伺服器可接受名稱的約束。它們可能有時出現在日誌、報告等位置。它們必須使用ISO-10646 UTF-8 編碼，但在一些情況下可能要求其他編碼。由伺服器決定如何將使用者名稱稱與已接受的使用者名稱稱對應起來。推薦使用直接的位元式、二進位比較。

為了本地化，協議嘗試盡量減少傳送的簡訊的數量。當出現時，這些訊息通常與錯誤、除錯資訊或一些外部配置資料相關。對一般情況下需顯示出來的資料，應使用一個數字編碼使得用一個本地化的訊息代替被傳送的訊息成為可能。簡訊應可配置。

SSH 協議使用的資料類型標記法

byte
byte 標識任意一個8 位值（8 位位元組）。固定長度的資料有時被表示為一個位元組數組，寫
作byte[n]，其中n 是數組中位元組的數量。

boolean
一個布爾值作為一個位元組儲存。0 表示FALSE，1 表示TRUE。所有非零的值必須被解釋為
TRUE；但是，應用軟體禁止儲存除0和1 以外的值。

uint32
表示一個 32 位不帶正負號的整數。按重要性降序（網路位元組順序）儲存為 4 個位元組。例如，

uint64
表示一個64位不帶正負號的整數。按重要性降序（網路位元組順序）儲存為8 個位元組。

string
任意長度二進位字串。字串用於裝載任意位元據，包括Null 字元和 8 位字元。字元
串被儲存為1個包含其長度（後續位元組數量）的uint32 以及0（=Null 字元串）或作為字元
串的值的更多的位元組。不使用終結符（Null 字元）。

字串也被用來儲存文本。在這種情況下，內部名稱使用 US-ASCII，可能顯示給使用者的
文本使用 ISO-10646 UTF-8。終結符（Null 字元）一般不應被儲存在字串中。例如，
US-ASCII 字串”testing”被表示為00 00 00 07 t e s t i n g。UTF-8 映射不
改變US-ASCII 字元的編碼。

mpint
表示二進位補碼（two’s complement）格式的多精度整數，儲存為一個字串，每位元組
8 位，從高位到低位（MSB first）。負數的資料區的首位元組的昀高位（ the most
significant bit）的值為1。對於正數，如果昀高位將被置為 1，則必須在前面加一個
值為0 的位元組。禁止包含值為0 或255 的非必要的前導位元組（leading bytes）。零必
須被儲存為具有0 個位元組的資料的字串。

例:

value (hex)          representation (hex)  -----------          ------------------- 0                    00 00 00 00  9a378f9b2e332a7      00 00 00 08 09 a3 78 f9 b2 e3 32 a7  80                   00 00 00 02 00 80  -1234                00 00 00 02 ed cc  -deadbeef            00 00 00 05 ff 21 52 41 11 

name-list
一個包含逗號分隔的名稱列表的字串。名稱列表表示為一個含有其長度（後續位元組數量）
的uint32，加上一個包含0 或多個逗號分隔的名稱的列表。名稱的長度禁止為0，並且禁
止包含逗號(“,”)。由於這是一個名稱列表，所有被包含的元素都是名稱並且必須使用
US-ASCII。上下文可能對名稱有附加的限制。例如，名稱列表中的名稱可能必須是一系列
有效演算法標識，或一系列[RFC3066]語言標識。名稱列表中名稱的順序可能有也可能沒
有意義。這取決於使用列表時的上下文。對單個名稱或整個列表都禁止使用終結字元（空
字元）。

例:

value           representation (hex)  -----           ------------------- ()，空名稱列表    00 00 00 00  ("zlib")        00 00 00 04 7a 6c 69 62  ("zlib,none")   00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65  

演算法和方法命名

SSH 協議使用名稱引用特定的雜湊、加密、完整性、壓縮和金鑰交換演算法或方法。有一些標準演算法和方法是所有系統實現都必須支援的。也有一些演算法和方法在協議規定中定義了，但是是可選的。此外，預期有一些組織將希望使用它們自有的演算法或方法。

在本協議中，所有演算法和方法的標識必須是由可列印的 US-ASCII 字元組成的非Null 字元串，長度不大於64字元。名稱必須是大小寫敏感的。

演算法和方法名稱有兩種格式：

○ 不含at 符號(“@”)的名稱為了等待IETF CONSENSUS（網際網路工程任務推動小組指派）而
保留。例如”3des-cbc”、 “sha-1”、”hmac-sha1”和”zlib”（雙引號不是名稱的一部
分）。這種格式的名稱必須在IANA （Internet 號碼分配局）註冊後才有效。註冊的名稱
禁止包含at符號(“@”)、逗號(“,”)、空格、控制字元（ASCII碼32 及以下）或ASCII
碼127（DEL）。名稱是大小寫敏感的，並且長度禁止超過64字元。

○ 任何人都可以使用符合 [email protected] 格式的名稱定義附加的演算法或方法，例如，
“[email protected]”。at 符號前的部分的格式沒有規定，但必須是可列印
的ASCII 字串，而且禁止包含逗號(“,”)、空格、控制字元（ASCII 碼32 及以下）或
ASCII 碼127（DEL） 。它必須僅有一個at 符號。at 符號後的部分必須是一個由定義該名
稱的人或組織控制的有效、完全合格的網域名稱[RFC1034]。名稱是大小寫敏感的，並且長
度禁止超過64 字元。如何管理本地命名空間取決於各個域。應說明的是，這裡的名稱看起
來與 email 地址 STD 11 [RFC0822]一樣。這純屬巧合，並且與 STD 11 [RFC0822]
沒有任何關係。

訊息編號

SSH 資料包的訊息編號從1到255。這些編號的分配如下：

傳輸層協議:

  1 to 19    傳輸層通用（例如，中斷連線、忽略、除錯等）  20 to 29   演算法協商  30 to 49   金鑰交換方法規定（編號可被重用於不同的交換方法）

驗證協議：

  50 to 59   使用者驗證通用   60 to 79   使用者驗證方法規定（編號可被重用於不同的驗證方法）

連線協定：

  80 to 89   連線協定通用  90 to 127  通道相關訊息 

為用戶端協議保留：

  128 to 191 保留

本地擴充：:

  192 to 255 本地擴充

IANA 考慮

對[SSH-ARCH]、[SSH-TRANS]、[SSH-USERAUTH]和[SSH-CONNECT]定義的SSH協議的IANA指引詳見[SSH-NUMBERS]。以下是一個簡單的總結，但注意[SSH-NUMBERS]包含對IANA的實際指引，該指引將來可能被新的內容取代。

在SSH協議中，對下列類型的名稱的分配由IETF CONSENSUS指定：

○ 服務名稱
* 驗證方法
* 連線協定通道名稱
* 連線協定全域請求名稱
* 連線協定通道請求名稱

○ 金鑰交換方法名稱

○ 指定的演算法名稱
* 密碼編譯演算法名稱
* MAC演算法名稱
* 公開金鑰演算法名稱
* 壓縮演算法名稱

這些名稱必須為可列印的US-ASCII字串，而且禁止包含at符號（”@”）、逗號（”,”）、空格、控制字元（ASCII碼32及以下）或ASCII碼127（DEL）。名稱是大小寫敏感的，而且長度禁止超過64字元。

含有at符號（”@”）的名稱是本地定義的擴充，不由IANA控制。

上面列出的每一個名稱類別具有一個獨立的命名空間。但是，應避免在多個類別中使用相同的名稱以盡量避免混淆。

0至191範圍內的訊息編號（見第7節）是通過IETF CONSENSUS分配的，見[RFC2434]。191至255範圍內的訊息編號（本地擴充）為PRIVATE USE預留，同樣見[RFC2434]。

安全性考慮

為了讓全部的安全性考慮更加易懂，在這裡集中了傳輸、驗證和串連文檔的安全性考慮。

傳輸層協議[SSH-TRANS]提供了一個在不安全的網路上的機密的通道。它執行伺服器主機驗證、金鑰交換、加密，以及完整性保護。它也形成一個唯一的會話id，可被更上層協議使用。

認證協議[SSH-USERAUTH]提供了一套可用於向伺服器驗證用戶端使用者的機制。驗證協議規定的各個機制使用傳輸層協議提供的會話id，並/或依賴傳輸層協議的安全性和完整性保障。

連線協定[SSH-CONNECT]規定了一種多工機制，用於在機密的、已驗證的傳輸上實現多個資料流（通道）。它也規定了使用互動式命令解釋程式（shell）的通道、通過連接埠轉寄在安全傳輸上實現各種外部協議（包括任意 TCP/IP 協議）的通道，以及使用伺服器主機上的安全子系統的通道。

偽隨機數產生

本協議在用於產生工作階段金鑰的雜湊值中包含隨機的、對應特定會話的資料，從而將每個工作階段金鑰
與會話綁定。應特別注意保證所有隨機數具有良好的品質。如果這裡的隨機資料（例如，
DiffieHellman 參數）是偽隨機的，那麼偽隨機數發生器應是密碼學上安全的（例如，它的下
一個輸出不能被輕易的猜測出來，即使知道之前所有的輸出），而且，適當的熵需要被加入偽隨機數發生器。[RFC4086]提供了隨機數和熵來源的建議。實現者（Implementers）應注意到對熵的重要性和對正確實現偽隨機數產生公式的困難程度的善意的警告。

能夠提供給用戶端或伺服器的熵可能有時達不到需要的量。在這種情況下，必須在熵不足的情況下繼續使用偽隨機數發生器，或者拒絕運行協議。後者是更值得推薦的做法。

控制字元篩選

當向使用者顯示文本時，例如錯誤或除錯訊息，用戶端軟體應將任何控制字元（除定位字元、斷行符號、換行以外）替換為安全的序列以避免通過發送終端控制字元的攻擊。

傳輸機密性

分析或推薦除已經成熟並被業界接受的加密器之外的特定的加密器，超出了本文和本工作群組的範圍。在撰寫本文時，普遍使用的加密器包括3DES、ARCFOUR、twofish、serpent 和blowfish。

AES 已由聯邦資訊處理標準發布為[FIPS-197]，並且密碼學界也已接受 AES。像通常一樣，實現者和使用者應查閱當前的文獻以保證產品使用的加密器中沒有被發現新的脆弱點。實現者也應檢查哪些加密器被認為相對較強，並應向使用者推薦使用這些較強的加密器。當選擇了一個較弱的加密器時，產品可以禮貌的、不突兀的告知使用者一個更強的演算法是有效並應被使用，這應被視為一種良好的特性。

“無”這種加密器被提供用於除錯並且不應被用於其他用途。它的密碼學特性在[RFC2410]中
得到了充分的描述，顯示出它不符合本協議的目的。

在當前的文獻中也可以找到這些和其他加密器的優缺點。[SCHNEIER]和[KAUFMAN]這兩個參
考文獻可以提供該主題的資訊。這兩個參考文獻都描述了特定加密器的加密塊連結模式
以及該模式的弱點。實質上，由於資料序列的開頭的高可預測性，這種模式理論上對選
擇密文攻擊（chosen cipher-text attack）是脆弱的。但是，這種攻擊被認為是困難和並
非完全可預測的，特別是當使用的資料區塊大小相對較大時。

此外，另一種 CBC 模式攻擊可以使用插入包含 SSH_MSG_IGNORE 的資料包的方法來緩和。不使用這種技巧，一種特定的攻擊可能成功。這種攻擊（通常稱為 Rogaway 攻[ROGAWAY]、 [DAI]、[BELLARE]）要生效，攻擊者需要知道將被加密的下一個資料區塊的初始向量（IV）。在CBC 模式下，它就是對上一個資料區塊加密的輸出。如果攻擊者還沒有任何辦法查看資料包（即，它是在 SSH 系統實現的內部緩衝區甚至核心中），那麼這種攻擊不會生效。如果上一個資料包已經被發送到網路（即，攻擊者可擷取它），那麼他能夠使用這種攻擊。

在理想的情況下，實現者僅當資料包被發送到網路並且沒有其他資料包等待傳送時，才需要添加一個額外的資料包。實現者可能希望檢查還有沒有等待發送的資料包；不幸的是，從核心或緩衝區中擷取該資訊一般並不容易。如果沒有未發送的資料包，那麼一個包含SSH_MSG_IGNORE 的資料包應被發送。如果每次攻擊者知道下一個資料包假定使用的IV時，都向資料流中添加一個新的資料包，那麼攻擊者將不能猜到正確的IV，這樣攻擊永遠不會成功。

作為一個例子，考慮以下情況：

    Client                                     Server      ------                                     ------     TCP(seq=x, len=500)       ---->      contains Record 1                       [500 ms passes, no ACK]      TCP(seq=x, len=1000)      ---->      contains Records 1,2                                                    ACK 

1. 發包最佳化演算法（Nagle algorithm）+TCP 重發意味著兩個記錄被合并為一個TCP 片段。
2. 記錄2 不在TCP 片段的開頭，而且永遠也不會，因為它獲得了應答（ACK）。
3. 然而，攻擊是可能的，因為記錄1 已經被發出了。

這個例子指出，用 TCP 緩衝區中是否存在未清除的資料作為是否需要一個空資料包的條件是不
安全的，因為當第二個write()被執行時，緩衝區將包含沒有獲得應答的記錄1。

另一方面，如下情況是完全安全的：

Client                                          Server  ------                                          ------ TCP(seq=x, len=500)            ----> contains SSH_MSG_IGNORE  TCP(seq=y, len=500)            ----> contains Data 

假定第二個SSH 記錄的IV 在資料包的資料確定下來時就固定了，那麼應執行以下步驟：
讀取使用者輸入（read from user）
加密空資料包（encrypt null packet）
加密資料包（encrypt data packet）

資料完整性

本協議確實允許資料完整性機制被禁用。實現者為除錯之外的目的使用這個特性時應特別謹慎。
當”none”類型的MAC（資料校正碼）被啟用時，應向使用者和管理員顯式的發出警告。

只要”none”類型的MAC沒有被使用，本協議提供資料完整性。

由於MAC 使用一個32 位的序號（sequence number），它在發送了2**32 個資料包後可能
開始泄漏資訊。但是，根據推薦來更新密鑰應可防止這種攻擊。傳輸協議[SSH-TRANS]推薦在1G 位元組的資料後更新密鑰，可能的昀小的資料包是 16 位元組。因此，昀多在 2**28 個資料包後就應更新密鑰。

重放

使用除”none”之外的MAC提供了完整性和驗證。此外，傳輸協議提供一個唯一的會話標識（部分與參與演算法和金鑰交換過程的偽隨機資料繫結），它可被高層協議用於將資料與特定的會話綁定，防止之前會話資料的重放。例如，驗證協議[SSH-USERAUTH]使用它來防止重放之前會話的簽名。由於公開金鑰驗證交換是密碼學上與會話綁定的（即，綁定到初始金鑰交換），它不能在其他會話中被成功的重放。注意，會話id可以被公開而不會損害協議的安全性。

如果兩個會話有同樣的會話 id（金鑰交換的雜湊值），那麼其中一個會話的資料包能被用於對另一個會話的重放攻擊。需要強調，發生這種情況的幾率，毋庸置疑的，在使用現代密碼學方法時是極小的。在規定較大的雜湊函數輸出和DH 參數時，更是如此。

在[RFC2085]、[RFC2246]、[RFC2743]、[RFC1964]、[RFC2025]和[RFC4120]中，對
在一些情況下使用單增的序號作為MAC或HMAC 的輸入來檢測重放進行了描述。[RFC2104]討論了底層的構造。基本上，每個資料包中的一個不同的序號保證了 MAC 函數的輸入中至少該序號是不相同的，從而提供了攻擊者無法預測的不重現的 MAC 輸出。但是，如果會話保持活動的時間足夠長，這個序號將在到達昀大值後從頭開始。這可能給攻擊者提供了重放一個之前記錄的序號相同的資料包的機會，但僅當通訊各方在傳輸使用該序號的上一個資料包後沒有更新密鑰的情況下才成立。如果通訊各方更新了密鑰，那麼重放將由於MAC校正失敗而被檢測出來。為此，必須強調，通訊各方必須在序號從頭開始前更新密鑰。自然的，如果攻擊者確實嘗試在通訊各方更新密鑰之前重放一個捕獲的資料包，那麼這個重複資料包的接收者將不能驗證 MAC 的合法性並丟棄該資料包。MAC 失敗的原因是，接收者將根據資料包的內容、共用秘密（shared secret）和預期的序號計算一個MAC。由於重放的資料包使用的不是預期的序號（重放的資料包的序號在接受者一方已經過去了），計算得到的MAC 將與從資料包接收到的MAC 不符。

中間人

T本協議對分配主機公開金鑰的基礎架構或方法未做假設或規定。預期在某些時候使用本協議時，將不對伺服器主機密鑰和伺服器主機名稱的關聯進行檢驗。這種用法對中間人攻擊是脆弱的。本節對此進行描述，並勸告管理員和使用者理解在初始化任何會話前檢驗這種關聯的重要性。

有三種中間人攻擊的情況要考慮。第一種是攻擊者在會話初始化之前已將一個裝置放置在用戶端和伺服器之間。在這種情況下，攻擊裝置試圖模仿合法的伺服器並會在用戶端初始化會話時向用戶端提供它的公開金鑰。如果它提供的是伺服器的公開金鑰，那麼它將無法對合法的伺服器和用戶端之間的傳輸進行解密或簽名，除非它也擷取了主機的私密金鑰。同時，攻擊裝置也將冒充用戶端初始化一個與合法的伺服器的會話。如果伺服器的公開金鑰在會話初始化之前已被安全的分配給用戶端，攻擊裝置提供給用戶端的密鑰將與用戶端儲存的密鑰不符。在這種情況下，應警告使用者提供的主機密鑰與用戶端暫存的主機密鑰不一致。像 4.1 中描述的一樣，使用者可被允許接受新的密鑰並繼續會話。推薦上述警告包含有關用戶端裝置的足夠的資訊，以使使用者能夠做出有根據的決定。如果使用者選擇使用儲存的伺服器公開金鑰（而不是在會話開始時提供的公開金鑰）來繼續會話，那麼由於上面討論的隨機性，用戶端-攻擊者的會話與攻擊者-伺服器的會話中會話特有資料將不同。從這一點出發，由於攻擊者沒有伺服器私密金鑰，攻擊者將無法對伺服器發出的包含會話特有資料的資料包進行正確的簽名，因此攻擊無法成功。

要考慮的第二種情況與第一種情況相似，也發生在串連時，但這種情況指出需要安全的分配伺服器公開金鑰。如果伺服器公開金鑰沒有被安全的分配，那麼用戶端無法知道自己是否在與目標伺服器對話。攻擊者可能使用社交工程（social engineering）技巧將讓不知情的使用者接受冒充的伺服器密鑰，然後在合法的伺服器和用戶端之間放置中間人攻擊裝置。如果發生這種情況，那麼用戶端將產生用戶端-攻擊者會話，攻擊者將產生攻擊者-伺服器會話，攻擊者將能夠監控和操縱用戶端和合法伺服器之間的所有傳輸。伺服器管理員昀好提供檢查主機密鑰指紋的方法，這種方法的安全性不依賴於實際主機密鑰的完整性。可能的機制除 4.1 中討論的之外，還可能包括安全的網頁、物理的紙張等。實現者應對如何以昀佳的方式在其系統實現中提供這種機制給出建議。由於本協議是可擴充的，將來對本協議的擴充可能提供更好的機制來解決需要在串連前知道伺服器的主機密鑰的問題。例如，可能在安全的 DNS 尋找（DNS lookup）中提供主機密鑰指紋，或在金鑰交換中使用GSS-API（[RFC1964]）上的Kerberos（[RFC4120]）來驗證伺服器。

在第三種中間人攻擊的情況中，攻擊者可能試圖在會話建立之後操縱在通訊各方之間傳輸的資料包。像 9.3.3 描述的那樣，以這種方式成功攻擊是不大可能的。9.3.3 的推理確實假定 MAC是安全的，並且不可能構造MAC 演算法的輸入以獲得已知的特定的輸出。在[RFC2104]的第6 節對此進行了詳細得多的討論。如果 MAC 演算法有脆弱性或足夠弱，那麼攻擊者可能指定特定的輸入以產生已知的MAC。通過這樣，攻擊者可能修改傳輸中的資料包的內容。或者，攻擊者可能檢閱捕獲的資料包的MAC，利用演算法的脆弱性或弱點找到共用秘密。在上面的任何一種情況下，攻擊者能夠構造一個或多個資料包並插入一個 SSH 資料流。為防止這種情況，實現者昀好使用普遍接受的 MAC 演算法，管理員昀好關注當前的密碼學文獻和討論，以保證沒有使用昀近被發現脆弱性或弱點的MAC 演算法。

總而言之，在沒有對主機和主機密鑰建立可靠的綁定的情況下使用本協議在本質上是不安全的，而且是不推薦的。但是，在安全性不是非常關鍵的環境下，本協議的這種使用可能是必要的，並且仍將提供對被動攻擊的保護。本協議和運行在本協議之上的應用程式的實現者應記住這種可能性。

拒絕服務

本協議設計為基於可靠的傳輸。如果發生傳輸錯誤或訊息操縱（message manipulation），串連將被斷開。如果發生這種情況，應重建立立串連。類似斷線器（wire cutter）這種拒絕服務的攻擊幾乎無法避免。
此外，本協議對拒絕服務的攻擊是脆弱的，因為攻擊者能夠在不通過驗證的情況下迫使服務執行消耗大量 CPU 和記憶體的串連建立和金鑰交換任務。實現者應提供使這種攻擊更加困難的特性，例如，只允許有合法使用者的那一部分用戶端子集的串連。

隱蔽通道

本協議未被設計用於消除隱蔽通道。例如，填充（padding）、SSH_MSG_IGNORE 訊息，以及協議中的幾個其他位置能被用於傳遞隱蔽資訊，而且接受方沒有可靠的方法來檢驗是否有這種資訊正被發送。

前向安全性

需要注意的是，Diffie-Hellman 金鑰交換能提供完全前向安全性（PFS）。本質上，PFS 是
一個密鑰建立協議的密碼學屬性，表示工作階段金鑰或長期私密金鑰在一個特定的會話之後泄密，不會造成更早的會話的泄密[ANSI-T1.523-2001]。使用在[SSH-TRANS]中 Diffie-Hellman 密
鑰交換一節描述的 Diffie-Hellman 方法（包括”diffie-hellman-group1-sha1”和”diffie-hellman-group14-sha1”）建立的 SSH 會話，即使在私密金鑰/驗證資料後來被透露的情況下仍然是安全的，但如果工作階段金鑰被透露則不再安全。因此，對於上述PFS 的定義，SSH確實具備PFS。但是，這個屬性不會傳遞給（commuted to）任何使用SSH作為傳輸的應用程式或協議。SSH 的傳輸層提供依賴於秘密資料的密碼驗證和其他方法。

當然，如果用戶端和伺服器的DH 私密參數被透露，那麼工作階段金鑰被透露了，但是這些內容在金鑰交換完成後可被拋棄。值得指出，不應使這些內容昀後處於交換空間，它們應在金鑰交換完成後立即被從記憶體中擦除。

金鑰交換方法的順序

像[SSH-TRANS]中的演算法協商一節中陳述的一樣，每一個裝置將發送一個優先金鑰交換方法的列表。首選的方法是列表中的第一個。推薦按密碼學強度對演算法進行排序，昀強的第一。在[RFC3766]中給出了對此問題的一些額外的指引。

通訊量分析

對任何協議的被動偵聽可能給攻擊者有關會話、使用者或協議指定資訊的一些通過其他途徑無法收集的資訊。例如，已顯示對SSH 會話的通訊量分析能產生有關密碼長度的資訊—[Openwall]和 [USENIX]。實現者應使用 SSH_MSG_IGNORE 資料包和包含隨機長度的填充，以阻止通訊量分析的企圖。其他方法也可能被發現和實現。

驗證協議

本協議的目的是執行用戶端使用者驗證。它假定運行在一個安全的傳輸層協議上，傳輸層協議已經驗證了伺服器、建立了加密的通訊通道，並且為會話計算了一個唯一的會話標識。

允許幾種具有不同安全特徵的驗證方法。對每個使用者，伺服器能接受哪種方法（或方法組合），由伺服器的本地策略決定。驗證強度不會高於所允許的昀弱的組合。

伺服器可在重複多次的不成功的驗證嘗試後進入一個睡眠期，使關鍵字檢索對攻擊者更加困難。應小心使這種機制不會導向自我拒絕服務（selfdenial of service）。

弱串連

如果傳輸層不提供機密性，依賴秘密資料的驗證方法應被禁用。如果傳輸層不提供強完整性保護，修改驗證資料（例如，修改密碼）的請求應被禁用，以防止攻擊者在不被注意的情況下修改密文，或使新的驗證資料不可用（拒絕服務）。

上述假定——驗證協議僅在事先驗證了伺服器的安全的傳輸上運行——非常重要。提醒部署SSH的人員，如果用戶端對於伺服器和伺服器主機密鑰之間沒有一個非常強的先驗（priori）關聯，後果將導致中間人攻擊。特別的，對驗證協議的情況，用戶端可能產生一個到中間人攻擊裝置的會話並泄漏使用者憑證，如使用者名稱和密碼。即使在沒有使用者憑證被泄露的驗證中，攻擊者還可能通過捕獲擊鍵來擷取不應有的資訊，與蜜罐（honeypot）程式工作的方法基本相同。

除錯訊息

在設計除錯訊息時應特別小心。如果設計得不合理，這些訊息可能透露的有關主機的資訊多得驚人。如果需要高安全性，可在使用者驗證階段禁用除錯訊息。主機管理員應嘗試各種方法來劃分所有事件通知訊息並保護它們不受未經授權的查看。開發人員應對一些正常事件和除錯訊息本質上的敏感性保持警惕，也可能希望為管理員提供如何防止未授權人員接觸這些資訊的指引。開發人員應考慮使使用者在驗證階段能獲得的敏感資訊昀小化，與本地策略致。由於這個原因，推薦在部署時禁用除錯訊息，需要管理員主動進行啟用。同時，在管理員啟用除錯資訊時，推薦向其顯示一條有關上述內容的訊息。

本地安全性原則

實現者必須保證提供的憑證驗證使用者有效，而且必須保證伺服器的本地策略允許該使用者的訪問請求。特別的，由於SSH連線協定的靈活性，在驗證時可能無法決定應當應用哪些（如果有的話）本地安全性原則，因為在這個時候使用者所請求的服務還不確定。例如，本地策略可能允許使用者訪問伺服器上的檔案，但不允許啟動互動式命令解釋程式。但是，在驗證協議中，並不知道使用者將要訪問檔案、嘗試使用互動式命令解釋程式，或兩者。在任何事件中，當伺服器主機的本地安全性原則存在時，它必須被正確的應用和強制實施。

實現者昀好提供一個預設的本地策略，並將其參數告知管理員和使用者。實現者可自行決定，預設的策略是順著“什麼都行（anything-goes）”路線，對使用者不加任何限制，還是順著“極端
限制（excessively-restrictive）”路線，讓管理員不得不主動對初始預設參數進行修改
以滿足他們的需要。或者，也可以嘗試為管理員提供實用和立即可用的策略，使他們不必太費力就能讓SSH運轉起來。無論做出哪種選擇，必須按上面的要求應用和強制實施。

公開金鑰驗證

使用公開金鑰驗證假定用戶端主機沒有失密。它也假定伺服器主機的私密金鑰沒有失密。

該風險可以通過在私密金鑰上使用口令句（passphrases）來降低；但是，這不是一個能強制執行的策略。建議使用智慧卡或其他技術使口令句成為一個可強制執行的策略。

伺服器可同時要求密碼和公開金鑰驗證；但是，這要求用戶端向伺服器暴露它的密碼（見下一節的密碼驗證）。

密碼驗證

密碼機制，像驗證協議規定的那樣，假定伺服器沒有失密。如果伺服器失密，使用密碼驗證將會把有效使用者名稱/密碼組合顯示給攻擊者，可能導致進一步的泄密。

該脆弱性可通過使用其他驗證方式來減輕。例如，公開金鑰驗證並不假定伺服器的安全性

基於主機的驗證

基於主機的驗證假定用戶端沒有失密。除了組合使用另一種驗證方法外，沒有降低風險的策略。

連線協定末端安全性

E連線協定假定了末端安全性。如果伺服器失密，在該主機上的任何終端會話、連接埠轉寄或系統訪問都會失密。對此沒有降低風險的因素。

如果用戶端已經失密，而且伺服器在驗證協議中未能阻止攻擊者，所有暴露的服務（無論是子系統還是通過映射）對攻擊都是脆弱的。實現者應提供機制讓管理員可控制暴露哪些服務，以限制其他服務的脆弱性。上述控制可能包括控制哪個機器和連接埠能在連接埠轉寄中作為目標，哪些使用者被允許使用互動式命令解釋程式，或哪些使用者被允許使用暴露的子系統。

代理轉寄

SSH 連線協定允許對其他協議的代理轉寄，如SMTP、POP3 和HTTP。對於希望控制物理上外部的使用者訪問特定應用程式的網路系統管理員來所，這可能是一個需要考慮的問題。本質上，對這些協議的轉寄可能違反屬於特定位置的（site-specific）安全性原則，因為它們可能以探測不到的方式貫通防火牆。實現者應提供一種管理機制來控制代理轉寄功能，使屬於特定位置的安全性原則可能維持。

此外，可以使用反向 Proxy轉寄功能，它也可以被用於繞開防火牆控制。

像上面指出的一樣，在代理轉寄操作中假定了末端安全性。末端安全性失效將使所有經代理轉寄傳遞的資料失密

X11 轉寄

SSH 連線協定提供的另一種形式的代理轉寄是對 X11 協議的轉寄。如果末端安全性失效，X11轉寄可能允許對X11 伺服器的攻擊。使用者和管理員應，理所當然的，使用合理的X11 安全機制來防止未經授權的使用X11 伺服器。希望進一步探索X11 的安全機制的實現者、管理員和使用者，可參閱[SCHEIFLER]和分析CERT之前報告的SSH轉寄與X11之間互動的問題VU#363181 和VU#118892[CERT]。

使用SSH的X11 遠程顯示（display forwarding），就其自身，不足以解決眾所周知的X11
安全性問題[VENEMA]。但是，SSH（或其他安全性通訊協定）的X11 遠程顯示，與只接受由許可或存取控制清單（ACL）授權的通過本地處理序間通訊（IPC）機制串連的實際和虛擬顯（actual and pseudo-display）組合，確實解決了很多X11安全性問題，只要沒有使用”none”這種MAC。 推薦X11 顯示的系統實現預設只允許在本地IPC 上開啟顯示。推薦支援X11 轉寄的SSH 伺服器的系統實現預設只允許在本地 IPC 上開啟顯示。在單使用者系統上，可能預設允許在 TCP/IP上開啟本地顯示是合理的。

X11 轉寄協議的實現者應實現[SSH-CONNECT]中描述的防cookie欺騙機制，作為一種附加機制用於防止在未經授權的情況下使用代理

SSH中文文檔