一、概念
SSH的英文全稱爲Secure Shell，是IETF（Internet Engineering Task Force）的Network Working Group所制定的一族協議，其目的是要在非安全網絡上提供安全的遠程登陸和其餘安全網絡服務。如須要SSH的詳細信息請參考[url]www.ssh.com[/url]（SSH Communications Security Corporation的網站）和[url]www.openssh.org[/url]（開放源碼的OpenSSH組織的網站）。
二、基本框架
SSH協議框架中最主要的部分是三個協議：傳輸層協議、用戶認證協議和鏈接協議。同時SSH協議框架中還爲許多高層的網絡安全應用協議提供擴展的支持。它們之間的層次關係能夠用以下圖1來表示：
圖1 SSH協議的層次結構示意圖
在SSH的協議框架中，傳輸層協議（The Transport Layer Protocol）提供服務器認證，數據機密性，信息完整性 等的支持；用戶認證協議（The User Authentication Protocol） 則爲服務器提供客戶端的身份鑑別；鏈接協議（The Connection Protocol） 將加密的信息隧道複用成若干個邏輯通道，提供給更高層的應用協議使用；各類高層應用協議能夠相對地獨立於SSH基本體系以外，並依靠這個基本框架，經過鏈接協議使用SSH的安全機制。
三、主機密鑰機制
對於SSH這樣以提供安全通信爲目標的協議，其中必不可少的就是一套完備的密鑰機制。因爲SSH協議是面向互聯網網絡中主機之間的互訪與信息交換，因此主機密鑰成爲基本的密鑰機制。也就是說，SSH協議要求每個使用本協議的主機都必須至少有一個本身的主機密鑰對，服務方經過對客戶方主機密鑰的認證以後，才能容許其鏈接請求。一個主機可使用多個密鑰，針對不一樣的密鑰算法而擁有不一樣的密鑰，可是至少有一種是必備的，即經過DSS算法產生的密鑰。關於DSS算法，請參考[FIPS-186]。
SSH協議關於主機密鑰認證的管理方案有兩種，以下圖2所示：
圖2 SSH主機密鑰管理認證方案示意圖
每個主機都必須有本身的主機密鑰，密鑰能夠有多對，每一對主機密鑰對包括公開密鑰和私有密鑰。在實際應用過程當中怎樣使用這些密鑰，並依賴它們來實現安全特性呢？如上圖所示，SSH協議框架中提出了兩種方案。
在第一種方案中，主機將本身的公用密鑰分發給相關的客戶機，客戶機在訪問主機時則使用該主機的公開密鑰來加密數據，主機則使用本身的私有密鑰來解密數據，從而實現主機密鑰認證，肯定客戶機的可靠身份。在圖2（a）中能夠看到，用戶從主機A上發起操做，去訪問，主機B和主機C，此時，A成爲客戶機，它必須事先配置主機B和主機C的公開密鑰，在訪問的時候根據主機名來查找相應的公開密鑰。對於被訪問主機（也就是服務器端）來講則只要保證安全地存儲本身的私有密鑰就能夠了。
在第二種方案中，存在一個密鑰認證中心，全部系統中提供服務的主機都將本身的公開密鑰提交給認證中心，而任何做爲客戶機的主機則只要保存一份認證中心的公開密鑰就能夠了。在這種模式下，客戶機在訪問服務器主機以前，還必須向密鑰認證中心請求認證，認證以後纔可以正確地鏈接到目的主機上。
很顯然，第一種方式比較容易實現，可是客戶機關於密鑰的維護倒是個麻煩事，由於每次變動都必須在客戶機上有所體現；第二種方式比較完美地解決管理維護問題，然而這樣的模式對認證中心的要求很高，在互聯網絡上要實現這樣的集中認證，單單是權威機構的肯定就是個×××煩，有誰可以什麼都能說了算呢？可是從長遠的發展來看，在企業應用和商業應用領域，採用中心認證的方案是必要的。
另外，SSH協議框架中還容許對主機密鑰的一個折中處理，那就是首次訪問免認證。首次訪問免認證是指，在某客戶機第一次訪問主機時，主機不檢查主機密鑰，而向該客戶都發放一個公開密鑰的拷貝，這樣在之後的訪問中則必須使用該密鑰，不然會被認爲非法而拒絕其訪問。
四、字符集和數據類型
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協議框架中擁有對這些數據類型的支持，將對協議、算法的處理帶來極大的便利。
五、命名規則及消息編碼
SSH 協議在使用到特定的哈希算法，加密算法，完整性算法，壓縮算法，以及密鑰交換算法和其餘協議時都利用名字來區分，因此SSH協議框架中很重要的一個部分就是命名規則的限定。不管是SSH協議框架中所必備的算法或者協議，仍是從此具體應用實現SSH協議時增長的算法或者協議，都必須遵循一個統一的命名規則。
SSH協議框架對命名規則有一個基本原則：全部算法標識符必須是不超過64個字符的非空、可打印US-ASCII字符串；名字必須是大小寫敏感的。
具體的算法命名有兩種格式：
（1）不包含@符號的名字都是爲IETF標準（RFC文檔）保留的。好比，「3des-cbc」，「sha-1」，「hmac-sha1」，「zlib」（注意：引號不是名字的一部分)。在沒有事先註冊以前，這種格式的名字是不能使用的。固然IETF的全部註冊的名字中也不能包含@符號或者逗號。
（2）任何人均可以使用「name@domainname」的格式命名自定義的算法，好比「[email]mycipher-cbc@ssh.com[/email]」。在@符號以前部分的具體格式沒有限定，不過這部分中必須使用除@符號和逗號以外的US-ASCII字符。在@符號以後的部分則必須是一個徹底合法的Internet域名（參考 [RFC-1034]），我的域名和組織域名都可。至於局部名字空間的管理則是由各個域自行負責的。
SSH協議框架中另外一個主要的標準化規則就是消息編碼，基本規定在表1中詳述：
表1 SSH協議框架中的編碼範圍原則
六、SSH協議的可擴展能力
SSH協議框架中設計了大量可擴展的冗餘能力，好比用戶自定義算法、客戶自定義密鑰規則、高層擴展功能性應用協議等，在本文中將不一一贅述。值得一提的是，這些擴展大多遵循 IANA（Internet Assigned Numbers Authority）的有關規定，特別是在重要的部分，象命名規則和消息編碼方面。關於IANA的標準及組織狀況請訪問該組織的官方網站：http: //www.iana.org。
