1、概念
SSH的英文全稱為Secure Shell，是IETF（Internet Engineering Task Force）的Network Working Group所制定的一族協議，其目的是要在非安全網絡上提供安全的遠程登錄和其他安全網絡服務。如需要SSH的詳細信息請參考www.ssh.com（SSH Communications Security Corporation的網站）和www.openssh.org（開放源碼的OpenSSH組織的網站）。
2、基本框架
SSH協議框架中最主要的部分是三個協議：傳輸層協議、用戶認證協議和連接協議。同時SSH協議框架中還為許多高層的網絡安全應用協議提供擴展的支持。它們之間的層次關系可以用如下圖1來表示：
　
圖1 SSH協議的層次結構示意圖
在SSH的協議框架中，傳輸層協議（The Transport Layer Protocol）提供服務器認證，數據機密性，信息完整性 等的支持；用戶認證協議（The User Authentication Protocol） 則為服務器提供客戶端的身份鑒別；連接協議（The Connection Protocol） 將加密的信息隧道復用成若干個邏輯通道，提供給更高層的應用協議使用；各種高層應用協議可以相對地獨立于SSH基本體系之外，并依靠這個基本框架，通過連接協議使用SSH的安全機制。
3、主機密鑰機制
對于SSH這樣以提供安全通訊為目標的協議，其中必不可少的就是一套完備的密鑰機制。由于SSH協議是面向互聯網網絡中主機之間的互訪與信息交換，所以主機密鑰成為基本的密鑰機制。也就是說，SSH協議要求每一個使用本協議的主機都必須至少有一個自己的主機密鑰對，服務方通過對客戶方主機密鑰的認證之后，才能允許其連接請求。一個主機可以使用多個密鑰，針對不同的密鑰算法而擁有不同的密鑰，但是至少有一種是必備的，即通過DSS算法產生的密鑰。關于DSS算法，請參考[FIPS-186]。
SSH協議關于主機密鑰認證的管理方案有兩種，如下圖2所示：
　
圖2 SSH主機密鑰管理認證方案示意圖
每一個主機都必須有自己的主機密鑰，密鑰可以有多對，每一對主機密鑰對包括公開密鑰和私有密鑰。在實際應用過程中怎樣使用這些密鑰，并依賴它們來實現安全特性呢？如上圖所示，SSH協議框架中提出了兩種方案。
在第一種方案中，主機將自己的公用密鑰分發給相關的客戶機，客戶機在訪問主機時則使用該主機的公開密鑰來加密數據，主機則使用自己的私有密鑰來解密數據，從而實現主機密鑰認證，確定客戶機的可靠身份。在圖2（a）中可以看到，用戶從主機A上發起操作，去訪問，主機B和主機C，此時，A成為客戶機，它必須事先配置主機B和主機C的公開密鑰，在訪問的時候根據主機名來查找相應的公開密鑰。對于被訪問主機（也就是服務器端）來說則只要保證安全地存儲自己的私有密鑰就可以了。
在第二種方案中，存在一個密鑰認證中心，所有系統中提供服務的主機都將自己的公開密鑰提交給認證中心，而任何作為客戶機的主機則只要保存一份認證中心的公開密鑰就可以了。在這種模式下，客戶機在訪問服務器主機之前，還必須向密鑰認證中心請求認證，認證之后才能夠正確地連接到目的主機上。
很顯然，第一種方式比較容易實現，但是客戶機關于密鑰的維護卻是個麻煩事，因為每次變更都必須在客戶機上有所體現；第二種方式比較完美地解決管理維護問題，然而這樣的模式對認證中心的要求很高，在互聯網絡上要實現這樣的集中認證，單單是權威機構的確定就是個大麻煩，有誰能夠什么都能說了算呢？但是從長遠的發展來看，在企業應用和商業應用領域，采用中心認證的方案是必要的。
另外，SSH協議框架中還允許對主機密鑰的一個折中處理，那就是首次訪問免認證。首次訪問免認證是指，在某客戶機第一次訪問主機時，主機不檢查主機密鑰，而向該客戶都發放一個公開密鑰的拷貝，這樣在以后的訪問中則必須使用該密鑰，否則會被認為非法而拒絕其訪問。
4、字符集和數據類型
SSH協議為了很好地支持全世界范圍的擴展應用，在字符集和信息本地化方面作了靈活的處理。首先，SSH協議規定，其內部算法標識、協議名字等必須采用US-ASCII字符集，因為這些信息將被協議本身直接處理，而且不會用來作為用戶的顯示信息。其次，SSH協議指定了通常情況下的統一字符集為ISO 10646標準下的UTF-8格式，詳細請參考RFC-2279。另外，對于信息本地化的應用，協議規定了必須使用一個專門的域來記錄語言標記（Language Tag）。對于大多數用來顯示給用戶的信息，使用什么樣的字符集主要取決于用戶的終端系統，也就是終端程序及其操作系統環境，因而對此SSH協議框架中沒有作硬性規定，而由具體實現協議的程序來自由掌握。
除了在字符、編碼方面的靈活操作外，SSH協議框架中還對數據類型作了規定，提供了七種方便實用的種類，包括字節類型、布爾類型、無符號的32位整數類型、無符號的64位整數類型、字符串類型、多精度整數類型以及名字表類型。下面分別解釋說明之：
（1）字節類型（byte）
一個字節（byte）代表一個任意的8字位值（octet）[RFC-1700]。有時候固定長度的數據就用一個字節數組來表示，寫成byte[n]的形式，其中n是數組中的字節數量。
（2）布爾類型（boolean）
一個布爾值（boolean）占用一個字節的存儲空間。數值0表示“假”（FALSE），數值1表示“真”（TRUE）。所有非零的數值必須被解釋成“真”，但在實際應用程序中是不能給布爾值存儲0和1意外的數值。
（3）無符號的32位整數類型（unit32）
一個32字位的無符號整型數值，由按照降序存儲的四個字節構成（降序即網絡字節序，高位在前，低位在后）。例如，有一個數值為63828921，它的十六進制表示為0x03CDF3B9，在實際存儲時就是03 CD F3 B9，具體存儲結構的地址分配如圖3。
　
圖3 無符號32位整數類型的典型存儲格式
（4）無符號的64位整數類型（unit64）
一個64字位的無符號整型數值，由按照降序存儲的八個字節構成，其具體存儲結構與32位整數類似，可以比照圖3。
（5）字符串類型（string）
字符串類型就是任意長度的二進制序列。字符串中可以包含任意的二進制數據，包括空字符（null）和8位字符。字符串的前四個字節是一個unit32數值，表示該字符串的長度（也就是隨后有多少個字節），unit32之后的零個或者多個字節的數據就是字符串的值。字符串類型不需要用空字符來表示結束。
字符串也被用來存儲文本數據。這種情況下，內部名字使用US-ASCII字符，可能對用戶顯示的文本信息則使用ISO-10646 UTF-8編碼。一般情況字符串中不應當存儲表示結束的空字符（null）。
在圖4中舉例說明字符串“My ABC”的存儲結構：
　
圖4 字符串類型的典型存儲格式
從圖4中可以很明顯地看出，字符串類型所占用的長度為4個字節加上實際的字符個數（字節數），即使沒有任何字符的字符串也要占用四個字節。這種結構與Pascal語言中的字符串存儲方式類似。
（6）多精度整數類型（mpint）
多精度的整數類型實際上是一個字符串，其數據部分采用二進制補碼格式的整數，數據部分每個字節8位，高位在前，低位在后。如果是負數，其數據部分的第一字節最高位為1。如果恰巧一個正數的最高位是1時，它的數據部分必須加一個字節0x00作為前導。需要注意的是，額外的前導字節如果數值為0或者255時就不能被包括在整數數值內。數值0則必須被存儲成一個長度為零的字符串（string）。多精度整數在具體運算時還是要遵循正常的整數運算法則的。其存儲格式通過圖5的若干示例來說明：
　
圖5 多精度整數類型的典型存儲格式
（7）名字表類型（name-list）
名字表（name-list）是一個由一系列以逗號分隔的名字組成的字符串（string）。在存儲方式上與字符串一樣，名字表前四個字節是一個unit32型整數以表示其長度（隨后的字節數目，類似于字符串類型），其后跟隨著由逗號分隔開的一系列名字，可以是0個或者多個。一個名字則必須具有非零長度，而且不能包含逗號，因為逗號是名字之間的分隔符。在使用時，上下文關系可以對名字表中的名字產生額外的限制，比如，一個名字表中的名字都必須是有效的算法標識，或者都是語言標記等。名字表中名字是否與順序相關，也要取決于該名字表所在的上下文關系。與字符串類型一樣，無論是單個的名字，還是整個名字表，都不需要使用空字符作為結束。如下圖6：
　
圖6 名字表的典型存儲格式
SSH協議框架中擁有對這些數據類型的支持，將對協議、算法的處理帶來極大的便利。
5、命名規則及消息編碼
SSH協議在使用到特定的哈希算法，加密算法，完整性算法，壓縮算法，以及密鑰交換算法和其他協議時都利用名字來區分，所以SSH協議框架中很重要的一個部分就是命名規則的限定。無論是SSH協議框架中所必備的算法或者協議，還是今后具體應用實現SSH協議時增加的算法或者協議，都必須遵循一個統一的命名規則。
SSH協議框架對命名規則有一個基本原則：所有算法標識符必須是不超過64個字符的非空、可打印US-ASCII字符串；名字必須是大小寫敏感的。
具體的算法命名有兩種格式：
（1）不包含@符號的名字都是為IETF標準（RFC文檔）保留的。比如，“3des-cbc”，“sha-1”，“hmac-sha1”，“zlib”（注意：引號不是名字的一部分)。在沒有事先注冊之前，這種格式的名字是不能使用的。當然IETF的所有注冊的名字中也不能包含@符號或者逗號。
（2）任何人都可以使用“name@domainname”的格式命名自定義的算法，比如“mycipher-cbc@ssh.com”。在@符號之前部分的具體格式沒有限定，不過這部分中必須使用除@符號和逗號之外的US-ASCII字符。在@符號之后的部分則必須是一個完全合法的Internet域名（參考[RFC-1034]），個人域名和組織域名均可。至于局部名字空間的管理則是由各個域自行負責的。
SSH協議框架中另一個主要的標準化規則就是消息編碼，基本規定在表1中詳述：

表1 SSH協議框架中的編碼范圍原則
6、SSH協議的可擴展能力
SSH協議框架中設計了大量可擴展的冗余能力，比如用戶自定義算法、客戶自定義密鑰規則、高層擴展功能性應用協議等，在本文中將不一一贅述。值得一提的是，這些擴展大多遵循IANA（Internet Assigned Numbers Authority）的有關規定，特別是在重要的部分，象命名規則和消息編碼方面。關于IANA的標準及組織情況請訪問該組織的官方網站：http://www.iana.org。