維基百科中對ssh協議的定義如下
secure shell（縮寫為ssh），由ietf的網路工作小組（network working group）所制定；ssh為一項建立在應用層和傳輸層基礎上的安全協議，為計算機上的shell（殼層）提供安全的傳輸和使用環境。
傳統的網路服務程式，如rsh、ftp、pop和telnet其本質上都是不安全的；因為它們在網路上用明文傳送資料、使用者帳號和使用者口令，很容易受到中間人（man-in-the-middle）攻擊方式的攻擊。就是存在另乙個人或者一台機器冒充真正的伺服器接收使用者傳給伺服器的資料，然後再冒充使用者把資料傳給真正的伺服器。
而ssh是目前較可靠，專為遠端登入會話和其他網路服務提供安全性的協議。利用ssh協議可以有效防止遠端管理過程中的資訊洩露問題。通過ssh可以對所有傳輸的資料進行加密，也能夠防止dns欺騙和ip欺騙。
ssh之另一項優點為其傳輸的資料可以是經過壓縮的，所以可以加快傳輸的速度。ssh有很多功能，它既可以代替telnet，又可以為ftp、pop、甚至為ppp提供乙個安全的「通道」。
用最通俗的方式來解釋一下ssh。有這麼乙個場景：有乙個伺服器在網際網路的另一頭，你需要遠端登入到伺服器來執行一些命令配置這台伺服器。這個時候你和伺服器之間就需要有資料通訊。假設客戶端叫a，伺服器叫b。
要實現通訊，最簡單的想法就是，客戶端伺服器之間建立乙個tcp連線，這樣你的指令就可以通過tcp連線從a傳輸到b。再仔細想想，不對，a與b之間需要通訊的資料中間經過了c、d、e、f等網路路由器裝置，這其中任何乙個路由器被黑客攻破，你們之間的通訊資料就毫無保留的被別人看到。
所以，你需要用乙個金鑰把資料加密吧。這樣a和b之間的資料就算被第三方看到，他們也不知道內容是什麼。可是這裡又存在乙個問題，a如何通知b（或者b如何通知a）它的金鑰是什麼呢？要知道只要資料是在網際網路上傳輸，就有被截獲的可能。金鑰被截獲了，你就沒有秘密可言了。
現在我們需要考慮乙個安全的方式來傳輸金鑰！讓我想想——非對稱加密！
a、b之間建立tcp連線
b生成一對公私金鑰
b把公鑰傳送給a
a生成乙個用於加密資料的金鑰k（既我們想通知給客戶端的金鑰，之後的資料通訊都使用這個金鑰加密，這個金鑰不可讓第三方知道）
a把k用公鑰加密傳送給b，b解密後，從此a、b之間的通訊資料都用k金鑰進行加密和解密。
這樣假如中間的c、d、e截獲了a發給b的k金鑰內容的資料報，可是這個金鑰是用b伺服器生成的公鑰加密過的，只有b伺服器知道如何解密。於是我們的資料很安全了。。。
看起來很簡單不是嗎？一切大功告成。等等...如果黑客h埋伏在了a和b之間的某乙個路由器上，他假冒b生成一對公私金鑰，然後把公鑰傳送給a，這樣a與h之間就建成了乙個加密通道，a把所有資訊傳送給h，h截獲a的資訊，在假冒a與b通訊。如此一來，a、b之間的通訊就完全暴漏給了h，而a、b卻完全不知道，這就是有名的「中間人」攻擊。
為解決這個問題，ssh協議採用由人工判斷公鑰的fingerprint是否可信的方式。當使用ssh命令連線伺服器時，命令行會提示如下資訊:
the authenticity of host '輸入yes之後才會連線到遠端伺服器，同時這個資訊會儲存到使用者的.ssh/known_hosts檔案中，下次再登入的時候，會檢查known_host檔案，如果存在相同的公鑰資訊，就不在提示使用者確認了。168.30.9.213 ()
' can'
t be established.
rsa key fingerprint is 23:42:c1:e4:3f:d2:cc:37:1d:89:cb:e7:5d:be:5d:53.
are you sure you want to
continue connecting (yes/no)?
這種認證方式假設想登陸伺服器的使用者已經知道伺服器公鑰（作為伺服器的使用者他自然有渠道得知伺服器公鑰）。fingerprint其實就代表公鑰，可以看成是公鑰的乙個壓縮版。有了這個步驟，如果有中間人想冒充伺服器b傳送公鑰給a，它不可能生成一對和b生成的一樣的公私金鑰，他傳送給a的公鑰必然與b伺服器的不同，所以使用者就可以根據printfinger判斷所連線的伺服器是否可信，有沒有被中間人冒充。
上面只是粗略講解ssh的安全協議的設計思路，實際上ssh通訊協議在安全通訊過程中分了幾個階段，每個階段又細分了幾個步驟，具體的可參看ssh原理簡介。幾個主要階段如下：
這裡我想單獨談談客戶端認證，因為對於使用linux遠端登入功能的系統管理員來說能有直觀感覺的也就是是這個環節了。一般我們能接觸到的的認證方式有兩種：
密碼認證很好理解，就是我們在登入遠端linux伺服器的時候提供使用者名稱和密碼？這裡面稍微提示一下，在你的使用者名稱和密碼通過網路傳輸給伺服器之前，已經經過了伺服器認證協商階段，這是乙個安全的加密通道已經建立，所以你的使用者名稱和密碼都是加密後傳輸給伺服器的，保證不會被第三方截獲。
每次登入都要輸入密碼很麻煩，且密碼如果簡單的話可能還會被暴力破解。public key認證提供了一種更安全便捷的認證客戶端的方式。這個技術也用到了非對稱加密技術，由客戶端生成公私金鑰對，然後將公鑰儲存在伺服器上。認證的過程大體如下：
客戶端發起乙個public key的認證請求，並傳送rsa key的模數作為識別符號。（如果想深入了解rsa key詳細 -->維基百科）
服務端檢查是否存在請求帳號的公鑰（linux中儲存在~/.ssh/authorized_keys檔案中），以及其擁有的訪問許可權。如果沒有則斷開連線
服務端使用對應的公鑰對乙個隨機的256位的字串進行加密，並傳送給客戶端
客戶端使用私鑰對字串進行解密，並將其結合session id生成乙個md5值傳送給服務端。*結合session id的目的是為了避免攻擊者採用重放攻擊（replay attack）。
服務端採用同樣的方式生成md5值與客戶端返回的md5值進行比較，完成對客戶端的認證。
上面wiki上也有寫，ssh其實是專門為shell設計的一種通訊協議，它垮了兩個網路層（傳輸層和應用層）。通俗點講就是只有ssh客戶端，和ssh伺服器端之間的通訊才能使用這個協議，其他軟體服務無法使用它。但是其實我們非常需要乙個通用的，建立在應用層之下的乙個傳輸層安全協議，它的目標是建立一種對上層應用協議透明的，不管是http、ftp、還是電子郵件協議或其他任何應用層協議都可以依賴的底層的可安全通訊的傳輸層協議。
網景公司於2023年為解決上面的問題，設計了ssl（secure sockets layer）協議的1.0版本，但並未發布，直到2023年發布ssl3.0之後，開始大規模應用於網際網路服務。可能很多人聽所過tls（transport layer security）。它相當於是ssl協議的乙個後續版本，他是ssl經過ietf標準化之後的產物（詳細參考傳輸層安全協議，下文中所說的ssl協議也包括tsl）。
跟ssh相比ssl所面臨的問題要更複雜一些，上面我們提到，ssh協議通過人工鑑別public key的printfinger來判斷與之通訊的伺服器是否可信（不是偽裝的中間人）。可是ssl是為了整個網際網路上的所有客戶端與伺服器之間通訊而設計的，他們彼此之間不可能自己判斷通訊的對方是否可信。那麼如何解決這個問題呢？
在構思解決方案之前我先講乙個概念數字簽名。。。。
想了一下，還是不寫了。。。 阮老師的這篇blog對數字簽名解釋的非常到位，良心推薦，如果有不了解數字簽名概念的讀者，建議先看看阮老師的文章。
回到上面我們所要解決的問題，以瀏覽器和**伺服器之前的安全通訊舉例，首先瀏覽器要求和某web伺服器建立安全的ssl連線通道，這時需要伺服器的公鑰用來加密瀏覽器生成的通訊金鑰，發給web伺服器，以確定通訊金鑰。假如瀏覽器接受到乙個公鑰，它如何知道這個公鑰確實是來自那個web伺服器，而不是中間的某個攻擊者截獲了它的請求，假扮web伺服器給它的假金鑰？瀏覽器總不能記錄所有可信任站點的公鑰吧。
解決問題的思路是這樣的，在ssl協議中引入了一種類似公共機關的概念，就是我們熟知的ca(數字證書認證機構)。它為瀏覽器發行乙個叫數字證書的東西。這個東西大體上如下圖所示，其中比較重要的資訊有：
有了數字證書，瀏覽器在建立ssl連線之前，並不只是簡單獲取伺服器的公鑰，而從伺服器獲取數字證書。數字證書裡有伺服器的公鑰，並且有ca給這個證書簽發的簽名。這個簽名其實是證書內容的摘要經過ca私鑰加密生成的。這樣瀏覽器得證書內容和摘要，並用ca的公鑰（每個瀏覽器都儲存著一些權威ca的公鑰）對數字簽名解密，也得到證書的摘要，比對兩個摘要如果相同，說明證書是真的，且未經過修改。信任問題就這麼解決了，如果上面這段話不好理解的話，再次建議讀一讀阮老師的數字簽名是什麼？。
此圖來自《http權威指南》
其他ssl的握手，金鑰交換，加密的細節這裡就不介紹了，普通開發者這要懂上面我介紹的這些基本概念就可以了。
讀完上面內容，理解https就簡單了，它的全稱是 hypertext transfer protocol secure，也稱為http over tls, http over ssl,其實就客戶端與服務系之間的http通訊基於tls或則ssl協議。對於http協議和ssl/tls協議本身沒有任何特殊定製，因為ssl/stl本身對http協議就是透明的，http在ssl/tls上運作也不需要任何特殊處理。
做為**管理員，可能會遇到申請數字證書的任務，理解了上面的概念，申請數字證書就不那麼一頭霧水了，首先你要為伺服器生成一對公司金鑰，然後把你**的資訊連同你的公鑰一起傳送給某個權威的ca，ca會通過某種方式認證申請人是否真的是**的所有人，比如讓你在**的指定路徑上傳他指定的特殊蚊子序列。驗證通過就會得到證書了。
**
HTTP和HTTPS的區別和聯絡
超文字傳輸協議http協議被用於在web瀏覽器和 伺服器之間傳遞資訊，http協議以明文方式傳送內容，不提供任何方式的資料加密，如果攻擊者擷取了web瀏覽器和 伺服器之間的傳輸報文，就可以直接讀懂其中的資訊，因此，http協議不適合傳輸一些敏感資訊，比如 信用卡號 密碼等支付資訊。為了解決http協...
http與https的區別以及https的好與壞
首先，比較http與https的區別 從概念上講 http是網際網路上應用最為廣泛的一種網路協議，是乙個客戶端和伺服器端請求和應答的標準 tcp 用於從www伺服器傳輸超文字到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網路傳輸減少。https 是以安全為目標的http通道，http ssl。h...
https和http的區別和聯絡的簡析
https 全稱 hyper text transfer protocol over secure socket layer 是以安全為目標的http通道，簡單講是http的安全版。即http下加入ssl層，https的安全基礎是ssl，因此加密的詳細內容就需要ssl。在瀏覽器裡面還要申請ca證書。...