非對稱加密演算法的核心源於數學問題，它存在公鑰和私鑰的概念，要完成加解密操作，需要兩個密鑰同時參與。我們常說的「公鑰加密，私鑰加密」或「私鑰加密， 公鑰解密」都屬於非對稱加密的范疇。公鑰加密的數據必須使用私鑰才可以解密，同樣，私鑰加密的數據也 只能通過公鑰進行解密。
相比對稱加密，非對稱加密的安全性得到了提升，但是也存在明顯的缺點，非對稱加解密的效率要遠遠小於對稱加解密。所以非對稱加密往往被用在一些安全性要求比較高的應用或領域中。
RSA加密演算法是一種典型的非對稱加密演算法，它基於大數的因式分解數學難題，它也是應用最廣泛的非對稱加密演算法，於1978年由美國麻省理工學院（MIT）的三位學者：Ron Rivest、Adi Shamir 和 Leonard Adleman 共同提出。
它的原理較為簡單，我們假設有消息發送方A和消息接收方B，通過下面的幾個步驟，我們就可以完成消息的加密傳遞：
（1）消息發送方A在本地構建密鑰對，公鑰和私鑰；
（2）消息發送方A將產生的公鑰發送給消息接收方B；
（3）B向A發送數據時，通過公鑰進行加密，A接收到數據後通過私鑰進行解密，完成一次通信；
（4）反之，A向B發送數據時，通過私鑰對數據進行加密，B接收到數據後通過公鑰進行解密。
由於公鑰是消息發送方A暴露給消息接收方B的，所以這種方式也存在一定的安全隱患，如果公鑰在數據傳輸過程中泄漏，則A通過私鑰加密的數據就可能被解密。
如果要建立更安全的加密消息傳遞模型，需要消息發送方和消息接收方各構建一套密鑰對，並分別將各自的公鑰暴露給對方，在進行消息傳遞時，A通過B的公鑰對數據加密，B接收到消息通過B的私鑰進行解密，反之，B通過A的公鑰進行加密，A接收到消息後通過A的私鑰進行解密。
當然，這種方式可能存在數據傳遞被模擬的隱患，我們可以通過數字簽名等技術進行安全性的進一步提升。由於存在多次的非對稱加解密，這種方式帶來的效率問題也更加嚴重。可以詳讀這兩篇文章：RSA 演算法原理 （一） （二）
在SSH安全協議的原理中， 是一種非對稱加密與對稱加密演算法的結合，先看下圖：
這里進行一下說明：
（1）首先服務端會通過非對稱加密，產生一個 公鑰 和 私鑰
（2）在客戶端發起請求時，服務端將 公鑰 暴露給客戶端，這個 公鑰 可以被任意暴露；
（3）客戶端在獲取 公鑰 後，會先產生一個由256位隨機數字組成的會話密鑰，這里稱為口令；
（4）客戶端通過 公鑰 將這個口令加密，發送給伺服器端；
（5）伺服器端通過 私鑰 進行解密，獲取到通訊口令；
之後，客戶端和服務端的信息傳遞，都通過這個口令進行對稱的加密。
這樣的設計在一定程度上提高了加解密的效率，不過，與客戶端服務端各構建一套密鑰對的加解密方式相比，在安全性上可能有所下降。在上面所述的通過口令進行加密的過程中，數據也是可以被竊聽的，不過由於密鑰是256個隨機數字，有10的256次方中組合方式，所以破解難度也很大。相對還是比較安全的。服務端和客戶端都提前知道了密鑰，SSH的這種方式，服務端是通過解密獲取到了密鑰。
現在知道了有非對稱加密這東西，那數字簽名是怎麼回事呢？
數字簽名的作用是我對某一份數據打個標記，表示我認可了這份數據（簽了個名），然後我發送給其他人，其他人可以知道這份數據是經過我認證的，數據沒有被篡改過。
有了上述非對稱加密演算法，就可以實現這個需求：
② SSH的工作原理
傳統的網路服務程序，比如 FTP ， POP ， Telnet ，本質上都是不安全的，因為它們在網路上用明文傳送數據、用戶賬號和用戶口令，很容易受到 中間人 攻擊方式的攻擊，攻擊者會冒充真正的伺服器接收用戶傳給伺服器的數據，然後再冒充用戶把數據傳給真正的伺服器。
為了滿足安全性的需求， IETF 的網路工作小組制定了 Secure Shell （縮寫為 SSH ），這是一項創建在 應用層 和 傳輸層 基礎上的安全協議，為計算機上的 Shell 提供安全的傳輸和使用環境。
SSH 是目前較可靠，專為遠程登錄會話和其他網路服務提供安全性的協議。利用 SSH 協議可以有效防止遠程管理過程中的信息泄漏問題。通過 SSH 可以對所有傳輸的數據進行加密，也能夠防止DNS欺騙和IP欺騙。
本文將會重點討論 SSH 中用到的加密演算法和建立安全連接的過程。
為了保證信息傳輸的安全性， SSH 使用了對稱加密、非對稱加密和散列等技術。
對稱密鑰加密又稱為對稱加密、私鑰加密、共享密鑰加密，是密碼學中一類加密演算法。這類演算法在加密和解密時使用相同的密鑰，或是使用兩個可以簡單地相互推算的密鑰。
SSH 使用對稱密鑰加密整個連接過程中傳輸的信息。值得注意的是，用戶自己創建的public/private密鑰對僅僅用於驗證，不會用在加密連接上。對稱加密允許對密碼進行身份驗證，以防止第三方窺探。
共享密鑰通過密鑰交換演算法生成，它可以讓雙方在完全沒有對方任何預先信息的條件下通過不安全信道創建起一個密鑰。客戶端和服務端都參與了這個過程，過程的細節將在後面闡述。
生成的密鑰將用來加密這次會話過程中客戶端和服務端傳輸的數據。這個過程會在驗證客戶身份之前完成。
SSH 支持多種對稱密鑰演算法，包括AES，Blowfish，3DES，CAST128和Arcfour。客戶端和服務端可以配置採用演算法的列表。客戶端列表中第一個能被服務端支持的演算法將被採用。
比如在Ubuntu 14.04上，客戶端和服務端默認的配置如下： aes128-ctr , aes192-ctr , aes256-ctr , arcfour256 , arcfour128 , [email protected] , [email protected] , [email protected] , aes128-cbc , blowfish-cbc , cast128-cbc , aes192-cbc , aes256-cbc , arcfour 。
也就是說，如果兩台Ubuntu 14.04採用默認配置，它們總是會採用 aes128-ctr 演算法來加密連接。
在非對稱加密方法中，需要一對密鑰，一個是私鑰，一個是公鑰。這兩個密鑰數學相關。用公鑰加密後所得的信息，只能用私鑰才能解密。如果知道了其中一個，並不能計算另外一個。因此，如果公開了一對密鑰中的一個，並不會危害到另外一個的秘密性質。
SSH 在一些地方使用了非對稱加密。
在密鑰交換過程中使用到了非對稱加密。在這個階段，客戶端和服務端生成臨時密鑰對，並且交換公鑰來生成共享密鑰。
在身份驗證的過程中也使用了非對稱加密。 SSH 密鑰對用來向服務端驗證客戶端身份。客戶端創建一對密鑰，然後將公鑰上傳到遠程伺服器上，寫入文件 ~/.ssh/authorized_keys 。
在創建共享密鑰後，客戶端必須向服務端證明身份。服務端會使用文件中的公鑰加密一段信息，並將加密後的信息發送給客戶端。如果客戶端可以能夠破解這段信息，那麼就能夠證明自己擁有相關的私鑰。之後服務端會為客戶端設置shell環境。
散列是電腦科學中一種對資料的處理方法，它通過某種特定的演算法將要檢索的項與涌來檢索的索引關聯起來，生成一種便於搜索的數據結構（散列表）。它也常用做一種資訊安全的方法，由一串資料中經過散列演算法計算出來的資料指紋，來識別檔案和資料是否有被篡改。
SSH 主要使用了散列消息認證碼（Keyed-hash message authentication code，縮寫為HMAC)，來確認消息沒有被篡改。
上面提到的對稱加密協商過程中，會使用消息認證碼（MAC）演算法。這個演算法會從客戶端支持的演算法中選出。
在密鑰協商完成後，所有的消息都必須攜帶MAC，用於通信雙方驗證消息的一致性。MAC值由共享密鑰，消息的分組序列和實際消息內容計算得到。
在對稱加密區域之外，MAC本身作為分組的最後部分被發送。研究者通常建議先機密數據，然後計算MAC
SSH 協議採用客戶端-服務端模型對兩方進行身份驗證，並對它們之間的數據進行加密。
服務端在指定埠監聽連接請求。它負責協商安全連接，認證連接方，並為客戶端生成正確的shell環境。
客戶端負責協商安全連接，驗證伺服器的身份是否與以前記錄的信息相匹配，並提供憑證進行身份驗證。
SSH會話分為兩個階段。第一個是同意和建立加密來保護未來的溝通。第二個階段是對用戶進行身份驗證，並發現是否應該授予對伺服器的訪問許可權。
當客戶端發起請求後，服務端返回支持的協議版本。如果客戶端可以匹配其中一個協議版本，則連接繼續。服務端會提供它的公共主機密鑰，客戶端可以用這個密鑰來驗證服務端是否合法。
此時，通信雙方採用迪菲-赫爾曼演算法來協商會話密鑰。
該演算法的大致過程如下：
用於其餘連接的共享密鑰加密被稱為二進制數據包協議。上述過程允許雙方平等地參與生成共享密鑰。
生成的密鑰是對稱密鑰，這意味著用於加密消息的密鑰也可以用於解密。其目的是將後面的通信包裝在不能被外部人員解密的加密隧道中。
在生成會話密鑰後，就開始進行用戶身份驗證。
根據伺服器接受的方式，有幾種不同的方法可用於身份驗證。
最簡單的方法是密碼驗證，其中伺服器要求客戶端輸入嘗試登陸賬號的密碼。密碼是通過協商加密發送的。
雖然密碼被加密，但由於密碼的復雜性受到限制，因此通常不建議使用此方法。與其他身份驗證的方法相比，自動腳本相對容易攻破正常長度的密碼。
最為推薦的選擇是使用SSH密鑰對。SSH密鑰對是非對稱密鑰。
公鑰用於加密只能用私鑰解密的數據。公鑰可以自由共享，因為沒有從公鑰中導出私鑰的方法。
驗證流程如下：
可以看到，密鑰的不對稱性允許服務端使用公鑰加密消息給客戶端。然後，客戶端可以通過正確解密消息來證明它擁有私鑰。
筆者本科專業是信息安全，不過畢業後並沒有從事安全行業，工作4年課堂上學習的知識基本忘的差不多了。
而SSH算是工作中最常用到的東西之一，其工作原理涉及不少密碼學的東西。
寫這篇博文，一是希望能幫助讀者了解SSH，二也是希望自己能撿起一些專業知識。在互聯網／軟體相關行業里，不論是否從事安全工作，了解這些東西都是很有必要的。
③ 【linux】SSH 使用密碼/公鑰遠程登錄總結
本文是筆者查閱網上資料做的總結，關於SSH原理，什麼是對稱加密和非對稱加密，本文不過多介紹。這里介紹一下SHH的工作過程、配製方法，可能出現的問題及解決方法。
說明：本文中涉及的例子，SSH客戶端為：本地主機A，SSH伺服器為：伺服器B
SSH協議採用C-S（客戶端-伺服器端）架構進行雙方的身份驗證以及數據的加密。
伺服器端組件監聽指定的埠，負責安全連接的建立、對連接方的身份認證、以及為通過身份認證的用戶建立正確的環境。
客戶端負責發起最初的TCP握手、安全連接的建立、驗證伺服器的身份與之前記錄中的一致、並將自己的驗證信息提供給伺服器。
一個SSH會話的建立過程分為兩個階段。第一階段，雙方溝通並同意建立一個加密連接通道以供後續信息傳輸用。第二階段，對請求接入的用戶進行身份驗證以確定伺服器端是否要給該用戶開放訪問許可權。
當客戶端發起TCP連接時，伺服器端返回信息說明自己支持的協議版本，如果客戶端上支持的協議與之匹配，則連接繼續。伺服器會提供自己的公共主機密鑰（public host key）以讓客戶端確認自己訪問的是正確的機器。
然後，雙方採用一種Diffie-Hellman演算法共同為該會話建立密鑰。每一方的一部分私有數據，加上來自對方的一部分公共數據，通過這種演算法計算，能夠得出完全相同的密鑰用於本次會話。
整個會話的通訊內容都使用該密鑰進行加密。這個階段使用的公鑰/私鑰對與用戶驗證身份用的SSH密鑰是完全無關的。
經典Diffie-Hellman演算法的計算步驟如下：
這個共享密鑰的加密方式被稱為二進制數據包協議（binary packet protocol）。該過程能夠讓雙方平等的參與密鑰生成的過程，而不是由單方掌握。這種共享密鑰生成的過程是安全的，雙方沒有交換過任何未經加密的信息。
生成的密鑰是對稱式密鑰，一方用於加密信息的密鑰等同於另一方用於解密信息的密鑰，而任何第三方由於不持有該密鑰，是無法解密雙方傳遞的內容的。
會話加密通道建立後，SSH開始進入用戶認證階段。
下一步，伺服器驗證用戶身份以決定是否准許其訪問。驗證有不同的方式，選擇的驗證方式取決於伺服器的支持。
最簡單的驗證是密碼驗證：伺服器要求客戶端輸入密碼，客戶端輸入的密碼經過上述的通道加密傳輸給伺服器。
雖然密碼是加密過的，然而該方法仍然不被推薦，因為用戶經常為了省事而使用過於簡單的密碼，而這類密碼很容易就能夠被自動化腳本破解。
最流行的驗證方式是SSH密鑰對，這也是當前最推薦的方式。SSH密鑰對是非對稱密鑰，私鑰和公鑰分別用於不同的功能。
公鑰用於加密，而私鑰用於解密。公鑰可以隨意上傳、共享，因為公鑰的流通並不會危及到私鑰的保密性。
SSH密鑰對的驗證過程起始於上一部分加密通道建立之後，其具體執行步驟如下：
簡單來說，伺服器端用公鑰加密信息，客戶端用私鑰解密信息以證明自己持有私鑰。該過程同時使用了對稱加密和非對稱加密，兩種方式各有自己的功用。
命令如下：
用戶名：為要登錄的伺服器B中已存在的用戶賬戶名
IP地址：為伺服器B的IP地址
-p 埠號：用來指定埠號，默認為22
第一次登錄時，會提示如下提示：
大概意思是說，你正在訪問的主機不能驗證它的真實性，它的RSA key（當前訪問主機的公鑰）指紋是怎樣的，你確定要繼續連接嗎？
輸入yes繼續，會提示，已永久把當前訪問主機的RSA key添加到了已知主機文件（用戶目錄下，.ssh 文件夾中的knwon_hosts文件）中。之後再次 SSH 登錄就不再有該提示了。
接著，輸入登錄賬戶的密碼即可。
SSH 密碼登錄，需要伺服器開啟密碼驗證許可權，編輯伺服器SSH配置命令如下：
在 sshd_config 文件中，Protocol 2 下面 #PasswordAuthentication yes，將前面的#號去掉，保存退出。
公鑰登錄，即免密碼登錄。避免的每次登錄都要輸入的麻煩，也防止了中間人攻擊。是SSH遠程登錄最常用的登錄方式。
提示輸入密鑰對名稱，直接回車，使用默認名稱即可；
提示輸入密碼（使用私鑰時，要輸入密碼），直接回車，不使用密碼即可。
首先，登錄伺服器B，在進行下面的操作。
找到 #PubkeyAuthentication yes，刪除 #號，保存退出。
重啟 ssh 服務
也可指定驗證私鑰：
本地主機A，生成密鑰對後：
sudo vim /etc/selinux/config
④ ssh原理及應用
簡單說，SSH是一種網路協議，用於計算機之間的遠程加密登錄。
SSH 為 Secure Shell的縮寫，由 IETF 的網路小組（Network Working Group）所制定，SSH 為建立在應用層基礎上的安全協議。SSH 是目前較可靠，專為遠程登錄會話和其他網路服務提供安全性的協議。利用 SSH 協議可以有效防止遠程管理過程中的信息泄露問題。SSH最初是UNIX系統上的一個程序，後來又迅速擴展到其他操作平台。SSH安裝容易、使用簡單，而且比較常見，一般的Unix系統、Linux系統、FreeBSD系統都附帶有支持SSH的應用程序包。Windows如果需要使用SSH，可以安裝PuTTY或者Cygwin。
SSH 服務基於非對稱加密（public-key cryptography，也稱公開密鑰加密）技術實現數據加密傳輸。該技術會生成一對數學相關的密鑰， 其中一個用於對數據進行加密，而且只能用於加密，而另一個只能用於解密 。使用加密密鑰加密後的數據，只能用對應的解密密鑰才能解密。而且，只知道其中一個密鑰，無法計算出另一個。因此，如果公開了一對密鑰中的一個，並不會危害到另一個的秘密性質。通常把公開的密鑰稱為公鑰（public key），而不公開的密鑰稱為私鑰（private key）。
一般來說，非對稱加密的應用場景有兩個：
與對稱密鑰加密相比，非對稱加密的優點在於不存在共享的通用密鑰。由於解密用的私鑰無需發送給任何用戶，所以可以避免密鑰被劫持或篡改。而加密用的公鑰即便被劫持或篡改，如果沒有與其匹配的私鑰，也無法解密數據。所以，截獲的公鑰是沒有任何用處的。
當前，SSH主要採用 RSA 演算法（協議 V2 默認演算法）和 DSA 演算法（協議 V1 僅支持該演算法）來實現非對稱加密技術。
SSH連接時，整個交互過程如上圖。，主要可以分為三個階段
服務端在每次啟動 SSH 服務時，都會自動檢查 /etc/ssh/ 目錄下相關密鑰文件的有效性。如果相關文件檢查發現異常，則會導致服務啟動失敗，並拋出相應錯誤信息。 如果文件相關不存在，則會自動重新創建。
默認創建的相關文件及用途說明如下：
當伺服器SSH服務啟動，客戶端也安裝了SSH後，就可以進行連接了。
後續登錄校驗及正常的數據傳輸，都會通過雙向加密方式進行。相關交互說明如下：
從這個連接過程中，可以看出，主要使用到兩個文件夾下的內容：
在連接中的兩個過程：
之所以有多組密鑰，是因為使用了不同的加密演算法。
客戶端接收到之後，會存儲在 ~/.ssh/known_hosts 文件里，查看這個文件，可以看到有一行與伺服器 ssh_host_ecdsa_key.pub 內容一致。
所以， ~/.ssh/authorized_keys 里表示本機可以被哪些機器訪問
~/.ssh/known_hosts 里表示本機訪問過哪些機器
SSH配置文件有兩個，一個是 ssh_config ,一個是 sshd_config 。前者是客戶端配置，後者是伺服器配置。也就是說，如果本機是作為客戶端，那麼就修改第一個配置，如果本機是作為伺服器，那麼就修改第二個配置，
一般來說，和密鑰登錄的配置有關的有以下幾個，如果密鑰配置好後無法登錄，嘗試配置以下三項。
其他
傳統的網路服務程序，如FTP、Pop和Telnet在傳輸機制和實現原理上是沒有考慮安全機制的，其本質上都是不安全的。因為它們在網路上用明文傳送數據、用戶帳號和用戶口令，別有用心的人通過竊聽等網路攻擊手段非常容易地就可以截獲這些數據、用戶帳號和用戶口令。而且，這些網路服務程序的簡單安全驗證方式也有其弱點，那就是很容易受到"中間人"（man-in-the-middle）這種攻擊方式的攻擊。
所謂"中間人"的攻擊方式，就是"中間人"冒充真正的伺服器接收你的傳給伺服器的數據，然後再冒充你把數據傳給真正的伺服器。伺服器和你之間的數據傳送被"中間人"一轉手做了手腳之後，就會出現很嚴重的問題。中間人能夠攻擊，主要原因在於他能認識截取的信息，也能發出讓接受者認識的信息。
使用SSH，你可以把所有傳輸的數據進行加密，這樣"中間人"這種攻擊方式就不可能實現了，而且也能夠防止DNS欺騙和IP欺騙。使用SSH，還有一個額外的好處就是傳輸的數據是經過壓縮的，所以可以加快傳輸的速度。SSH有很多功能，它既可以代替Telnet，又可以為FTP、Pop、甚至為PPP提供一個安全的"通道"。
最初的SSH是由芬蘭的一家公司開發的。但是因為受版權和加密演算法的限制，現在很多人都轉而使用OpenSSH。OpenSSH是SSH的替代軟體包，而且是免費的，可以預計將來會有越來越多的人使用它而不是SSH。
⑤ 如何禁用OpenSSH（CBC）加密模式防止信息泄露
OpenSSH是一種開放源碼的SSH協議的實現，初始版本用於OpenBSD平台，現在已經被移植到多種Unix/Linux類操作系統下。如果配置為CBC模式的話，OpenSSH沒有正確地處理分組密碼演算法加密的SSH會話中所出現的錯誤，導致可能泄露密文中任意塊最多32位純文本。在以標准配置使用OpenSSH時，攻擊者恢復32位純文本的成功概率為2^{-18}， 此外另一種攻擊變種恢復14位純文本的成功概率為2^{-14}。
編輯ssh配置文件
在 # Ciphers and keying 下或者 文件的末尾 添加下文
重啟SSH服務使配置生效
使用SSH針對CBC分組類型的加密演算法進行檢查
屏幕列印的日誌的最後一行：
出現 no matching cipher found: client aes128-cbc,3des-cbc … 說明配置生效。（此時的SSH登錄並未成功）
查看默認SSH支持加密演算法分組類型