1、什麼是SSH ？
傳統的網絡服務程序，如FTP、Pop和Telnet在傳輸機制和實現原理上是沒有考慮安全機制的，在網絡上用明文傳送數據、用戶帳號和用戶口令，這些網絡服務程序的簡單安全驗證方式也有其弱點，那就是很容易受到"中間人"（man-in-the-middle）這種***方式的***.
SSH是英文Secure Shell的簡寫形式。通過使用SSH，你可以把所有傳輸的數據進行加密，這樣"中間人"這種***方式就不可能實現了，而且也能夠防止DNS欺騙和IP欺騙。使用SSH，還有一個額外的好處就是傳輸的數據是經過壓縮的，所以可以加快傳輸的速度。SSH有很多功能，它既可以代替Telnet，又可以爲FTP、Pop、甚至爲PPP提供一個安全的"通道"。
最初的SSH是由芬蘭的一家公司開發的。但是因爲受版權和加密算法的限制，現在多使用OpenSSH。OpenSSH是SSH的替代軟件包，而且是免費的。
最後，SSH在運行方式上也很有特色。不像其他的TCP/IP應用，SSH被設計爲工作於自己的基礎之上，而不是利用包裝（wrappers）或通過Internet守護進程inetd。但是許多人想通過TCP包裝來運行SSH守護進程。雖然你可以通過tcpd（從inetd上運行啓動）來運行SSH進程，但這完全沒有必要。
2、SSH協議的內容(協議框架)
SSH協議是建立在應用層和傳輸層基礎上的安全協議，它主要由以下三部分組成，共同實現SSH的安全保密機制。
傳輸層協議，它提供諸如認證、信任和完整性檢驗等安全措施，此外它還可以任意地提供數據壓縮功能。通常情況下，這些傳輸層協議都建立在面向連接的TCP數據流之上。
用戶認證協議層，用來實現服務器的跟客戶端用戶之間的身份認證，它運行在傳輸層協議之上。
連接協議層，分配多個加密通道至一些邏輯通道上，它運行在用戶認證層協議之上。
當安全的傳輸層連接建立之後，客戶端將發送一個服務請求。當用戶認證層連接建立之後將發送第二個服務請求。這就允許新定義的協議可以和以前的協議共存。連接協議提供可用作多種目的通道，爲設置安全交互Shell會話和傳輸任意的TCP/IP端口和X11連接提供標準方法。
3、SSH的安全驗證
從客戶端來看，SSH提供兩種級別的安全驗證。
第一種級別（基於口令的安全驗證），只要你知道自己的帳號和口令，就可以登錄到遠程主機，並且所有傳輸的數據都會被加密。但是，這種驗證方式不能保證你正在連接的服務器就是你想連接的服務器。可能會有別的服務器在冒充真正的服務器，也就是受到"中間人"這種***方式的***。
第二種級別（基於密匙的安全驗證），需要依靠密匙，也就是你必須爲自己創建一對密匙，並把公有密匙放在需要訪問的服務器上。如果你要連接到SSH服務器上，客戶端軟件就會向服務器發出請求，請求用你的公有密匙進行安全驗證。服務器收到請求之後，先在你在該服務器的用戶根目錄下尋找你的公有密匙，然後把它和你發送過來的公有密匙進行比較。如果兩個密匙一致，服務器就用公有密匙加密"質詢"（challenge）並把它發送給客戶端。客戶端軟件收到"質詢"之後就可以用你的私人密匙解密再把它發送給服務器。
與第一種級別相比，第二種級別不需要在網絡上傳送用戶口令。
4、SSH的應用
首先，SSH最常見的應用就是，用它來取代傳統的Telnet、FTP等網絡應用程序，通過SSH登錄到遠方機器執行你想進行的工作與命令。在不安全的網路通訊環境中，它提供了很強的驗證（authentication）機制與非常安全的通訊環境。實際上，SSH開發者的原意是設計它來取代原UNIX系統上的rcp、rlogin、rsh等指令程序的；但經過適當包裝後，發現它在功能上完全可以取代傳統的Telnet、FTP等應用程序。
傳統 BSD 風格的 r 系列指令（如 rcp，rsh，rlogin）往往都被視爲不安全的，很容易就被各種網絡***手段所破解，幾乎所有找得到有關UNIX安全的書或文件，都會一而再、再而三地警告系統管理者，留心r系列指令的設定，甚至要求系統管理者將r系列指令通通關閉。
而用來替代r系列指令的SSH，則在安全方面做了極大的強化，不但對通訊內容可以進行極爲安全的加密保護，同時也強化了對身份驗證的安全機制，它應用了在密碼學（Cryptography）中已發展出來的數種安全加密機制，如 Symmetric Key Cryptography，Asymmetric Key Cryptography， One-way Hash Function，Random-number Generation等，來加強對於身份驗證與通訊內容的安全保護。有IDEA，three-key triple DES，DES，RC4-128，TSS，Blowfish 等數種多種安全加密算法可供選擇，加密的key則是通過 RSA 進行交換的。資料的加密可以對抗IP spoofing，RSA這種非對稱性的加密機制則可用來對抗DNS spoofing與IP routing spoofing，同時RSA也可以進行對主機身份的驗證。
其次，通過使用用SSH可以在本地主機和遠程服務器之間設置"加密通道"，並且這樣設置的"加密通道"可以跟常見的Pop應用程序、X應用程序、Linuxconf應用程序相結合，提供安全保障。 SSH的"加密通道"是通過"端口轉發"來實現的。你可以在本地端口（沒有用到的）和在遠程服務器上運行的某個服務的端口之間建立"加密通道"。然後只要連接到本地端口。所有對本地端口的請求都被SSH加密並且轉發到遠程服務器的端口。當然只有遠程服務器上運行SSH服務器軟件的時候"加密通道"才能工作。
5、主機密鑰機制
對於SSH這樣以提供安全通訊爲目標的協議，其中必不可少的就是一套完備的密鑰機制。由於SSH協議是面向互聯網網絡中主機之間的互訪與信息交換，所以主機密鑰成爲基本的密鑰機制。也就是說，SSH協議要求每一個使用本協議的主機都必須至少有一個自己的主機密鑰對，服務方通過對客戶方主機密鑰的認證之後，才能允許其連接請求。一個主機可以使用多個密鑰，針對不同的密鑰算法而擁有不同的密鑰，但是至少有一種是必備的，即通過DSS算法產生的密鑰。SSH協議關於主機密鑰認證的管理方案有兩種，如下圖所示： 
每一個主機都必須有自己的主機密鑰，密鑰可以有多對，每一對主機密鑰對包括公開密鑰和私有密鑰。在實際應用過程中怎樣使用這些密鑰，並依賴它們來實現安全特性呢？如上圖所示，SSH協議框架中提出了兩種方案。
在第一種方案中，主機將自己的公用密鑰分發給相關的客戶機，客戶機在訪問主機時則使用該主機的公開密鑰來加密數據，主機則使用自己的私有密鑰來解密數據，從而實現主機密鑰認證，確定客戶機的可靠身份。在圖（a）中可以看到，用戶從主機A上發起操作，去訪問，主機B和主機C，此時，A成爲客戶機，它必須事先配置主機B和主機C的公開密鑰，在訪問的時候根據主機名來查找相應的公開密鑰。對於被訪問主機（也就是服務器端）來說則只要保證安全地存儲自己的私有密鑰就可以了。
在第二種方案中，存在一個密鑰認證中心，所有系統中提供服務的主機都將自己的公開密鑰提交給認證中心，而任何作爲客戶機的主機則只要保存一份認證中心的公開密鑰就可以了。在這種模式下，客戶機在訪問服務器主機之前，還必須向密鑰認證中心請求認證，認證之後才能夠正確地連接到目的主機上。
很顯然，第一種方式比較容易實現，但是客戶機關於密鑰的維護卻是個麻煩事，因爲每次變更都必須在客戶機上有所體現；第二種方式比較完美地解決管理維護問題，然而這樣的模式對認證中心的要求很高，在互聯網絡上要實現這樣的集中認證，單單是權威機構的確定就是個大麻煩，有誰能夠什麼都能說了算呢？但是從長遠的發展來看，在企業應用和商業應用領域，採用中心認證的方案是必要的。
另外，SSH協議框架中還允許對主機密鑰的一個折中處理，那就是首次訪問免認證。首次訪問免認證是指，在某客戶機第一次訪問主機時，主機不檢查主機密鑰，而向該客戶都發放一個公開密鑰的拷貝，這樣在以後的訪問中則必須使用該密鑰，否則會被認爲非法而拒絕其訪問。
6、字符集和數據類型
SSH協議爲了很好地支持全世界範圍的擴展應用，在字符集和信息本地化方面作了靈活的處理。首先，SSH協議規定，其內部算法標識、協議名字等必須採用US-ASCII字符集，因爲這些信息將被協議本身直接處理，而且不會用來作爲用戶的顯示信息。其次，SSH協議指定了通常情況下的統一字符集爲ISO 10646標準下的UTF-8格式，詳細請參考RFC-2279。另外，對於信息本地化的應用，協議規定了必須使用一個專門的域來記錄語言標記（Language Tag）。對於大多數用來顯示給用戶的信息，使用什麼樣的字符集主要取決於用戶的終端系統，也就是終端程序及其操作系統環境，因而對此SSH協議框架中沒有作硬性規定，而由具體實現協議的程序來自由掌握。
除了在字符、編碼方面的靈活操作外，SSH協議框架中還對數據類型作了規定，提供了七種方便實用的種類，包括字節類型、布爾類型、無符號的32位整數類型、無符號的64位整數類型、字符串類型、多精度整數類型以及名字表類型。
7、命名規則及消息編碼
SSH協議在使用到特定的哈希算法，加密算法，完整性算法，壓縮算法，以及密鑰交換算法和其他協議時都利用名字來區分，所以SSH協議框架中很重要的一個部分就是命名規則的限定。無論是SSH協議框架中所必備的算法或者協議，還是今後具體應用實現SSH協議時增加的算法或者協議，都必須遵循一個統一的命名規則。
SSH協議框架對命名規則有一個基本原則：所有算法標識符必須是不超過64個字符的非空、可打印US-ASCII字符串；名字必須是大小寫敏感的。
具體的算法命名有兩種格式：
（1）不包含@符號的名字都是爲IETF標準（RFC文檔）保留的。比如，“3des-cbc”，“sha-1”，“hmac-sha1”，“zlib”（注意：引號不是名字的一部分)。在沒有事先註冊之前，這種格式的名字是不能使用的。當然IETF的所有註冊的名字中也不能包含@符號或者逗號。
（2）任何人都可以使用“name@domainname”的格式命名自定義的算法，比如“[email protected]”。在@符號之前部分的具體格式沒有限定，不過這部分中必須使用除@符號和逗號之外的US-ASCII字符。在@符號之後的部分則必須是一個完全合法的Internet域名（參考[RFC-1034]），個人域名和組織域名均可。至於局部名字空間的管理則是由各個域自行負責的。
SSH協議框架中另一個主要的標準化規則就是消息編碼，基本規定在表1中詳述： 
8、SSH協議的可擴展能力
SSH協議框架中設計了大量可擴展的冗餘能力，比如用戶自定義算法、客戶自定義密鑰規則、高層擴展功能性應用協議等，在本文中將不一一贅述。值得一提的是，這些擴展大多遵循IANA（Internet Assigned Numbers Authority）的有關規定，特別是在重要的部分，象命名規則和消息編碼方面。關於IANA的標準及組織情況請訪問該組織的官方網站：http://www.iana.org。
9.SSH通信簡述
整個通訊過程中，經過下面幾個階段協商實現認證連接。
第一階段:(協商版本)
由客戶端向服務器發出 TCP 連接請求。TCP 連接建立後，客戶端進入等待，服務器向客戶端發送第一個報文，宣告自己的版本號，包括協議版本號和軟件版本號。協議版本號由主版本號和次版本號兩部分組成。它和軟件版本號一起構成形如："SSH-<主協議版本號>.<次協議版本號>-<軟件版本號>\n"的字符串。其中軟件版本號字符串的最大長度爲40個字節，僅供調試使用。客戶端接到報文後，回送一個報文，內容也是版本號。客戶端響應報文裏的協議版本號這樣來決定：當與客戶端相比服務器的版本號較低時，如果客戶端有特定的代碼來模擬，則它發送較低的版本號；如果它不能，則發送自己的版本號。當與客戶端相比服務器的版本號較高時，客戶端發送自己的較低的版本號。按約定，如果協議改變後與以前的相兼容，主協議版本號不變；如果不相兼容，則主主協議版本號升高。
服務器接到客戶端送來的協議版本號後，把它與自己的進行比較，決定能否與客戶端一起工作。如果不能，則斷開TCP 連接；如果能，則按照二進制數據包協議發送第一個二進制數據包，雙方以較低的協議版本來一起工作。到此爲止，這兩個報文只是簡單的字符串，你我等凡人直接可讀。
第二階段: (協商加密和認證方法,交換會話密鑰)
協商解決版本問題後，雙方就開始採用二進制數據包進行通訊。由服務器向客戶端發送第一個包，內容爲自己的 RSA主機密鑰(host key)的公鑰部分、RSA服務密鑰(server key)的公鑰部分、支持的加密方法、支持的認證方法、次協議版本標誌、以及一個 64 位的隨機數(cookie)。這個包沒有加密，是明文發送的。客戶端接收包後，依據這兩把密鑰和被稱爲cookie的 64 位隨機數計算出會話號(session id)和用於加密的會話密鑰(session key)。隨後客戶端回送一個包給服務器，內容爲選用的加密方法、cookie的拷貝、客戶端次協議版本標誌、以及用服務器的主機密鑰的公鑰部分和服務密鑰的公鑰部分進行加密的用於服務器計算會話密鑰的32 字節隨機字串。除這個用於服務器計算會話密鑰的 32字節隨機字串外，這個包的其他內容都沒有加密。之後，雙方的通訊就是加密的了，服務器向客戶端發第二個包（雙方通訊中的第一個加密的包）證實客戶端的包已收到。
第三階段: (身份認證)
雙方隨後進入認證階段。可以選用的認證的方法有：
(1) ~/.rhosts 或 /etc/hosts.equiv 認證（缺省配置時不容許使用它）;
(2) 用 RSA 改進的 ~/.rhosts 或 /etc/hosts.equiv 認證；
(3) RSA 認證；
(4) 口令認證。
如果是使用 ~/.rhosts 或 /etc/hosts.equiv 進行認證，客戶端使用的端口號必須小於1024。
認證的第一步(確定用戶是否存在)是客戶端向服務器發 SSH_CMSG_USER 包聲明用戶名，服務器檢查該用戶是否存在，確定是否需要進行認證。如果用戶存在，並且不需要認證，服務器回送一個SSH_SMSG_SUCCESS 包，認證完成。否則，服務器會送一個 SSH_SMSG_FAILURE 包，表示或是用戶不存在，或是需要進行認證。注意，如果用戶不存在，服務器仍然保持讀取從客戶端發來的任何包。除了對類型爲 SSH_MSG_DISCONNECT、SSH_MSG_IGNORE 以及 SSH_MSG_DEBUG 的包外，對任何類型的包都以 SSH_SMSG_FAILURE 包。用這種方式，客戶端無法確定用戶究竟是否存在。
如果用戶存在但需要進行認證，進入認證的第二步(確定認證方式)。客戶端接到服務器發來的 SSH_SMSG_FAILURE 包後，不停地向服務器發包申請用各種不同的方法進行認證，直到時限已到服務器關閉連接爲止。時限一般設定爲 5 分鐘。對任何一個申請，如果服務器接受，就以 SSH_SMSG_SUCCESS 包迴應；如果不接受，或者是無法識別，則以 SSH_SMSG_FAILURE 包迴應。
第四階段: 會話請求
認證完成後，客戶端向服務器提交會話請求。服務器則進行等待，處理客戶端的請求。在這個階段，無論什麼請求只要成功處理了，服務器都向客戶端迴應 SSH_SMSG_SUCCESS包；否則迴應 SSH_SMSG_FAILURE 包，這表示或者是服務器處理請求失敗，或者是不能識別請求。會話請求分爲這樣幾類：申請對數據傳送進行壓縮、申請僞終端、啓動 X11、TCP/IP 端口轉發、啓動認證代理、運行 shell、執行命令。到此爲止，前面所有的報文都要求 IP 的服務類型(TOS)使用選項 IPTOS_THROUGHPUT。
第五階段: 交互會話
會話申請成功後，連接進入交互會話模式。在這個模式下，數據在兩個方向上雙向傳送。此時，要求 IP 的服務類型(TOS)使用 IPTOS_LOWDELAY 選項。當服務器告知客戶端自己的退出狀態時，交互會話模式結束。
（注意：進入交互會話模式後，加密被關閉。在客戶端向服務器發送新的會話密鑰後，加密重新開始。用什麼方法加密由客戶端決定。）
10.安裝並測試OpenSSH
可以從網絡上下載並安裝OpenSSH（有關OpenSSH的安裝和配置請參考：http://www.linuxaid.com.cn/engineer/brimmer/html/OpenSSH.htm）。
安裝完OpenSSH之後，用下面命令測試一下：
ssh -l [your accountname on the remote host] [address of the remote host]
如果OpenSSH工作正常，你會看到下面的提示信息：
The authenticity of host [hostname] can't be established.
Key fingerprint is 1024 5f:a0:0b:65:d3:82:df:ab:44:62:6d:98:9c:fe:e9:52.
Are you sure you want to continue connecting (yes/no)?
OpenSSH告訴你它不知道這臺主機，但是你不用擔心這個問題，因爲你是第一次登錄這臺主機。鍵入“yes”。這將把這臺主機的“識別標記”加到“~/.ssh/know_hosts”文件中。第二次訪問這臺主機的時候就不會再顯示這條提示信息了。
然後，SSH提示你輸入遠程主機上你的帳號的口令。輸入完口令之後，就建立了SSH連接，這之後就可以象使用telnet那樣使用SSH了。
SSH的密匙
生成你自己的密匙對
生成並分發你自己的密匙有兩個好處：
1) 可以防止“中間人”這種***方式
2) 可以只用一個口令就登錄到所有你想登錄的服務器上
用下面的命令可以生成密匙：
ssh-keygen
如果遠程主機使用的是SSH 2.x就要用這個命令：
ssh-keygen –d
在同一臺主機上同時有SSH1和SSH2的密匙是沒有問題的，因爲密匙是存成不同的文件的。
ssh-keygen命令運行之後會顯示下面的信息：
Generating RSA keys: ............................ooooooO......ooooooO
Key generation complete.
Enter file in which to save the key (/home/[user]/.ssh/identity):
[按下ENTER就行了]
Created directory '/home/[user]/.ssh'.
Enter passphrase (empty for no passphrase):
[輸入的口令不會顯示在屏幕上]
Enter same passphrase again:
[重新輸入一遍口令，如果忘記了口令就只能重新生成一次密匙了]
Your identification has been saved in /home/[user]/.ssh/identity.
[這是你的私人密匙]
Your public key has been saved in /home/[user]/.ssh/identity.pub.
The key fingerprint is: 2a:dc:71:2f:27:84:a2:e4:a1:1e:a9:63:e2:fa:a5:89 [user]@[local machine]
“ssh-keygen –d”做的是幾乎同樣的事，但是把一對密匙存爲（默認情況下）“/home/[user]/.ssh/id_dsa”（私人密匙）和“/home/[user]/.ssh/id_dsa.pub”（公用密匙）。
現在你有一對密匙了：公用密匙要分發到所有你想用ssh登錄的遠程主機上去；私人密匙要好好地保管防止別人知道你的私人密匙。用“ls –l ~/.ssh/identity”或“ls –l ~/.ssh/id_dsa”所顯示的文件的訪問權限必須是“-rw-------”。
如果你懷疑自己的密匙已經被別人知道了，不要遲疑馬上生成一對新的密匙。當然，你還要重新分發一次公用密匙。
分發公用密匙
在每一個你需要用SSH連接的遠程服務器上，你要在自己的家目錄下創建一個“.ssh”的子目錄，把你的公用密匙“identity.pub” 拷貝到這個目錄下並把它重命名爲“authorized_keys”。然後執行：
chmod 644 .ssh/authorized_keys
這一步是必不可少的。如果除了你之外別人對“authorized_keys”文件也有寫的權限，SSH就不會工作。
如果你想從不同的計算機登錄到遠程主機，“authorized_keys”文件也可以有多個公用密匙。在這種情況下，必須在新的計算機上重新生成一對密匙，然後把生成的“identify.pub”文件拷貝並粘貼到遠程主機的“authorized_keys”文件裏。當然在新的計算機上你必須有一個帳號，而且密匙是用口令保護的。有一點很重要，就是當你取消了這個帳號之後，別忘了把這一對密匙刪掉。
9.配置SSH客戶端
OpenSSH有三種配置方式：命令行參數、用戶配置文件和系統級的配置文件（“/etc/ssh/ssh_config”）。命令行參數優先於配置文件，用戶配置文件優先於系統配置文件。所有的命令行的參數都能在配置文件中設置。因爲在安裝的時候沒有默認的用戶配置文件，所以要把“/etc/ssh/ssh_config”拷貝並重新命名爲“~/.ssh/config”。
標準的配置文件大概是這樣的：
[lots of explanations and possible options listed]
# Be paranoid by default
Host *
ForwardAgent no
ForwardX11 no
FallBackToRsh no
還有很多選項的設置可以用“man ssh”查看“CONFIGURATION FILES”這一章。
配置文件是按順序讀取的。先設置的選項先生效。
假定你在www.foobar.com上有一個名爲“bilbo”的帳號。而且你要把“ssh-agent”和“ssh-add”結合起來使用並且使用數據壓縮來加快傳輸速度。因爲主機名太長了，你懶得輸入這麼長的名字，用“fbc”作爲“www.foobar.com”的簡稱。你的配置文件可以是這樣的：
Host *fbc
HostName www.foobar.com
User bilbo
ForwardAgent yes
Compression yes
# Be paranoid by default
Host *
ForwardAgent no
ForwardX11 no
FallBackToRsh no
你輸入“ssh fbc”之後，SSH會自動地從配置文件中找到主機的全名，用你的用戶名登錄並且用“ssh-agent”管理的密匙進行安全驗證。這樣很方便吧！
用SSH連接到其它遠程計算機用的還是“paranoid（偏執）”默認設置。如果有些選項沒有在配置文件或命令行中設置，那麼還是使用默認的“paranoid”設置。
在我們上面舉的那個例子中，對於到www.foobar.com的SSH連接：“ForwardAgent”和“Compression”被設置爲“Yes”；其它的設置選項（如果沒有用命令行參數）“ForwardX11”和“FallBackToRsh”都被設置成“No”。
其它還有一些需要仔細看一看的設置選項是：
l CheckHostIP yes
這個選項用來進行IP地址的檢查以防止DNS欺騙。
l CompressionLevel
壓縮的級別從“1”（最快）到“9”（壓縮率最高）。默認值爲“6”。
l ForwardX11 yes
爲了在本地運行遠程的X程序必須設置這個選項。
l LogLevel DEBUG
當SSH出現問題的時候，這選項就很有用了。默認值爲“INFO”。