ssh加密

1. ssh密鑰對登錄安全嗎原理篇

在 《使用wireshark分析ssh口令登錄細節》 和 《ssh工具，開發者必須有所了解》 這兩篇文章中，我們知道了SSH登錄有兩種登錄驗證方式，其中口令登錄方式使用簡單，但會遇到安全問題，比如遇到中間人攻擊，就會泄漏伺服器的root口令。所以從安全的角度來看，建議使用另外一種登錄驗證方式，這就是密鑰對登錄方式。

密鑰對驗證方式對於初學者來說並不是很友好，所以我分兩篇文章把這個事情說清楚，本文主要從原理的角度講解，讓你了解這種方式運作的流程，下一篇從實戰的角度手把手教你登錄ssh伺服器。

對於開發者來說，也請務必學會使用密鑰對方式登錄伺服器，因為現在很多應用和服務推薦這種方式，比如Github就可以使用密鑰對方式連接，AWS默認就禁止口令登錄。

網上有很多文章介紹ssh口令登錄，但客觀的說，很多文章講錯了。

很多人大概是這樣理解的，客戶端生成一個公開密碼學演算法的密鑰對（注意不是ssh伺服器端的密鑰對），然後將公鑰放到ssh伺服器上的 authorized_keys 文件中（潛台詞就是你有ssh許可權才能操作）。

然後ssh如何登錄呢?在連接過程中，會將客戶端密鑰對的公鑰發送給ssh伺服器，伺服器在 authorized_keys 文件中匹配到這個公鑰，就認為登錄成功了，其實這個理解是有問題的。

核心的兩個問題：

知道了這個結論後，我們看看詳細的登錄驗證過程，在 《使用wireshark分析ssh口令登錄細節》 中說過，ssh登錄分為兩個階段，不管是哪一種登錄驗證，第一階段的過程都是相同的，區別在於第二階段。

有的同學說，這次你為啥不用wireshark分析了？因為第二階段的消息傳遞都是加密保護的，並不能解密出具體的消息格式，這一點和TLS協議非常不同，TLS協議有多種方式可以解密出明文，而SSH協議是不支持的，所以wireshark只能顯示密文。

基於這一點，本文就不用wireshark分析了，簡單談一談ssh密鑰對登錄的流程，要經過多個消息交互。

第二階段具體的流程如下：

1：ssh客戶端生成一個 key ID（這個ID是基於密鑰對的公鑰算出來的，具體格式未知），再一次說明，這個密鑰對不是伺服器的，使用會話密鑰加密後發送給伺服器端。

2：伺服器端從 authorized_keys 文件中匹配 key ID，如果匹配，此時還不能證明這個ssh客戶端是真正的客戶端密鑰對的主人。

3：伺服器端生成一個隨機數，然後用客戶端的公鑰加密後發送給客戶端。

4：客戶端使用自己的私鑰解密出伺服器端的隨機數，注意，如果某個攻擊者僅僅有客戶端的公鑰，它是無法解密出的，因為攻擊者沒有對應的私鑰。

5：為了向伺服器端證明它能解密出這個隨機數，客戶端將解密出的隨機數用會話密鑰加密，將得到的值進行MD5運算。然後將這個值發送給伺服器，以便響應（4）階段的消息。

6：伺服器端對原始隨機數也使用會話密鑰加密，再進行MD5計算，如果得出的值和（5）階段客戶端發送的一致，代表雙方的登錄校驗通過。

伺服器端使用伺服器密鑰對公鑰指紋像客戶端證明它就是真正的伺服器端；而客戶端使用它自己的密鑰對向伺服器證明它就是真實的客戶端。

由於在驗證過程中，客戶端密鑰對的公鑰不會傳輸，所以即使遇到中間人攻擊，攻擊者也不會獲取到公鑰（不考慮客戶端機器本身遇到攻擊了）。

如果客戶端的公鑰曾經泄漏過，攻擊者也不能成功登錄ssh伺服器，原因是攻擊者沒有私鑰，無法解密出隨機數，從而不能完成驗證。

當然如果客戶端密鑰對公鑰和私鑰全部泄漏了，那就當我什麼也沒說，所以定期更換密鑰對還是有好處的。

基於以上兩點，我認為ssh密鑰對登錄是安全的，也是推薦的。

2. SSH 密碼與秘鑰登錄方式

密碼登錄顧名思義極其簡單，登錄之前需要在ssh伺服器上有相應的用戶名與登錄密碼。

密碼登錄命令行：ssh username@hostname -p port
username:登錄用戶名
hostname:ssh伺服器，既可以是ip也可以是域名
port:這個為可選項，即ssh伺服器的埠，如果為空則默認埠為22

秘鑰登錄使用加密的

終端下生成秘鑰命令：ssh-keygen -t rsa（如果不輸入密碼，則不需要密碼）
生成過程中會提示輸入秘鑰文件的名稱，如果輸入為 Key，則會生成 Key 與 Key.pub 兩個文件， Key為私鑰，Key.pub為公鑰。將Key放入本機用戶目錄的 .ssh目錄下，將.ssh目錄許可權改為700

將生成的公鑰 Key.pub 上傳至目標伺服器，並將Key.pub放置於用戶目錄的.ssh目錄，同樣.ssh目錄許可權也為700
然後執行 cat Key.pub >> authorized_keys 將公鑰導入，並確定authorized_keys許可權為 600

秘鑰配置好後，可以執行 ssh -i Key username@hostname -p port
ssh 默認秘鑰為 id_rsa, 需要加上參數-i 指明秘鑰

3. 如何禁用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支持加密演算法分組類型

4. 女生說ssh是什麼意思

一種網路協議。
女生說ssh是一種網路協議，用於計算機之間的加密登錄。
ssh是一種遠程加密傳輸協議，並不是所謂的免密登錄這一作用，那隻是它的一小部分，你可以理解它跟https一樣，是一種加密協議，有助於提高安全性。

5. SSH詳解-3.密鑰登陸

SSH詳解-1.ssh基礎知識
SSH詳解-2.ssh基本用法
SSH詳解-3.密鑰登陸
SSH詳解-4.多個ssh公鑰

在上一篇中我們了解到了ssh基本用法，ssh通過密碼進行登錄。密碼登錄存在很多問題。密碼太簡單，又不安全。密碼太復雜，不容易記，而且每次登錄都要輸入很麻煩。於是就有了密鑰登陸。

什麼是密鑰(key)？

ssh密鑰登錄採用的是 非對稱加密 。

非對稱密鑰加密系統，又稱公鑰密鑰加密。它需要使用不同的密鑰來分別完成加密和解密操作，一個公開發布，即公開密鑰（public key）和，另一個由用戶自己秘密保存，即私用密鑰（private key）。
如果數據使用公鑰加密，那麼只有使用對應的私鑰才能解密，其他密鑰都不行；反過來，如果使用私鑰加密（這個過程一般稱為「簽名」），也只有使用對應的公鑰解密。

了解完密鑰後，接下來看看密鑰登錄的過程，SSH 密鑰登錄分為以下的步驟。

第零步，准備步驟客戶端通過 ssh-keygen 生成自己的公鑰和私鑰，並將公鑰放入遠程伺服器的指定位置。

第一步，用戶客戶端向伺服器發起SSH登錄的請求。

第二步，伺服器收到用戶SSH登錄的請求，伺服器生成一些隨機數據發送給客戶端。

第三步，客戶端接收到伺服器發過來的數據，客戶端使用私鑰對數據進行簽名後再返回給伺服器。

第四步，伺服器收到客戶端加密後的數據，使用對應公鑰進行解密。然後判斷解密後的數據是否與原始數據一致，如果一致就允許用戶登錄。

ssh-keygen 是OpenSSH提供的一個命令行工具，用於生成密鑰登錄所需的公鑰和私鑰。

在上面的例子中，我使用了-t參數來指定加密演算法，一遍會選擇rsa或者dsa。
第一個問題，問我要保存在哪？（直接Enter默認會保存在~/.ssh/id_rsa中）因為我之前已經生成過密鑰了，我就保存在tenxun裡面。

第二個問題，詢問是否要為私鑰文件設定密碼保護（passphrase）。這樣的話，即使入侵者拿到私鑰，還是需要破解密碼。如果為了方便，不想設定密碼保護，可以直接按回車鍵，密碼就會為空。

最後，就會生成私鑰和公鑰，屏幕上還會給出公鑰的指紋，以及當前的用戶名和主機名作為注釋，用來識別密鑰的來源。

從上面的公鑰中我們可以看到末尾的公鑰注釋 23696@DESKTOP-GKRBCVI
公鑰注釋可以用來識別不同的公鑰，表示這是哪台主機（DESKTOP-GKRBCVI）的哪個用戶（username）的公鑰。

注意 ，公鑰只有一行。因為它太長了，顯示的時候可能自動換行了。

OpenSSH 規定，用戶公鑰保存在伺服器的 ~/.ssh/authorized_keys 文件。你要以哪個用戶的身份登錄到伺服器，密鑰就必須保存在該用戶主目錄的~/.ssh/authorized_keys文件。只要把公鑰添加到這個文件之中，就相當於公鑰上傳到伺服器了。每個公鑰占據一行。如果該文件不存在，可以手動創建。

-i 指定要上傳公鑰（公鑰文件可以不指定路徑和 .pub 後綴名），user是所要登錄的用戶名，hostname是主機名，這兩個參數與ssh 登錄命令是一致。

特別注意 ，不是把公鑰上傳上去就行了，還需要把 authorized_keys 文件的許可權要設為644，即只有文件所有者才能寫。如果許可權設置不對，SSH伺服器可能會拒絕讀取該文件，導緻密鑰登錄失效，登錄的時候還需要輸入密碼。

提到輸入密碼，如果再生成公鑰和私鑰的時候設置了密碼，使用密鑰登錄的時候也需要輸入私鑰的密碼，這樣可以防止他人非法竊取了私鑰。

私鑰設置了密碼以後，每次使用都必須輸入私鑰密碼，這個問題可以使用 ssh-agent 命令解決。

網路-密鑰
Git - 生成 SSH 公鑰 (git-scm.com)
ssh(1) - OpenBSD manual pages

6. 對SSH包,在包加密過程中假如沒有包括MAC,會有什麼好處嗎

沒有好處的。
加密連接建立後，每一條發送的信息都會包含一個MAC，這樣接收方就能夠用這個MAC來驗證信息完整性。MAC的計算過程使用了共享密鑰、信息包的順序代號、以及信息自身的內容。在內容發送過程中，MAC是在每一個信息包的最後發送的，位於對稱加密區之外。這是因為根據科研人員的建議，最好按照先加密、後計算MAC的順序進行數據的處理。

7. 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。

8. ssh和telnet區別

telnet是明文傳輸，而ssh是加密傳輸，相對來說比較安全。 1.ssh機制第一種是路由器公鑰加密，私鑰解密。ssh路由器會產生一個公鑰public,一個私鑰pri.當客戶端通過ssh登錄到設備的時候，路由器會將自己的公鑰發送給客戶端，客戶端接受並保存這個公鑰，接下來的過程就是加密，客戶端輸入用戶名和密碼的過程是通過路由器的公鑰來加密的，客戶端輸入完成將這個在發送給路由器，路由器通過自己的私鑰來解密這個公鑰。再將這個用戶名和密碼發送到本地進行認證。認證成功，整個登錄即ok。 2.ssh機制第二種是路由器產生一個公鑰秘鑰，客戶端也產生一個公鑰秘鑰。當客戶端試圖登錄路由器，客戶端輸入正確的用戶名admin後，路由器發現admin用戶被綁定到名稱為AR1的rsa秘鑰。所以路由器會將此公鑰發送給客戶端進行驗證，因為客戶端有對應的私鑰可以解密公鑰，故認證成功。難點：客戶端的公鑰如何產生，客戶端的公鑰如何導入路由器。路由器的公鑰如何產生，路由器的公鑰如何導入客戶端。

9. SSH隧道協議（AES密鑰對加密法則）

SSH是每一台Linux電腦的標准配置

隨著Linux設備從電腦逐漸擴展到手機、外設和家用電器，SSH的適用范圍也越來越廣。不僅程序員離不開它，很多普通用戶也每天使用；SSH具備多種功能，可以用於很多場合。有些事情，沒有它就是辦不成

簡單說，SSH是一種網路協議，用於計算機之間的加密登錄。
如果一個用戶從本地計算機，使用SSH協議登錄另一台遠程計算機，我們就可以認為，這種登錄是安全的，即使被中途截獲，密碼也不會泄露。
最早的時候，互聯網通信都是明文通信，一旦被截獲，內容就暴露無疑。1995年，芬蘭學者Tatu Ylonen設計了SSH協議，將登錄信息全部加密，成為互聯網安全的一個基本解決方案，迅速在全世界獲得推廣，目前已經成為Linux系統的標准配置。
需要指出的是，SSH只是一種協議，存在多種實現，既有商業實現，也有開源實現。

SSH主要用於遠程登錄。假定你要以用戶名user，登錄遠程主機host，只要一條簡單命令就可以了。

如果本地用戶名與遠程用戶名一致，登錄時可以省略用戶名。

SSH的默認埠是22，也就是說，你的登錄請求會送進遠程主機的22埠。使用p參數，可以修改這個埠。

上面這條命令表示，ssh直接連接遠程主機的2222埠。

SSH之所以能夠保證安全，原因在於它採用了公鑰加密。
整個過程是這樣的：（1）遠程主機收到用戶的登錄請求，把自己的公鑰發給用戶。（2）用戶使用這個公鑰，將登錄密碼加密後，發送回來。（3）遠程主機用自己的私鑰，解密登錄密碼，如果密碼正確，就同意用戶登錄。

這個過程本身是安全的，但是實施的時候存在一個風險：如果有人截獲了登錄請求，然後冒充遠程主機，將偽造的公鑰發給用戶，那麼用戶很難辨別真偽。因為不像https協議，SSH協議的公鑰是沒有證書中心（CA）公證的，也就是說，都是自己簽發的。

可以設想，如果攻擊者插在用戶與遠程主機之間（比如在公共的wifi區域），用偽造的公鑰，獲取用戶的登錄密碼。再用這個密碼登錄遠程主機，那麼SSH的安全機制就盪然無存了。這種風險就是著名的「中間人攻擊」（Man-in-the-middle attack）。

SSH協議是如何應對的呢？

如果你是第一次登錄對方主機，系統會出現下面的提示：

這段話的意思是，無法確認host主機的真實性，只知道它的公鑰指紋，問你還想繼續連接嗎？

所謂」公鑰指紋」，是指公鑰長度較長（這里採用RSA演算法，長達1024位），很難比對，所以對其進行MD5計算，將它變成一個128位的指紋。上例中是98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d，再進行比較，就容易多了。

很自然的一個問題就是，用戶怎麼知道遠程主機的公鑰指紋應該是多少？回答是沒有好辦法，遠程主機必須在自己的網站上貼出公鑰指紋，以便用戶自行核對。

假定經過風險衡量以後，用戶決定接受這個遠程主機的公鑰。

系統會出現一句提示，表示host主機已經得到認可。

然後，會要求輸入密碼。

如果密碼正確，就可以登錄了。

當遠程主機的公鑰被接受以後，它就會被保存在文件 $HOME/.ssh/known_hosts 之中。下次再連接這台主機，系統就會認出它的公鑰已經保存在本地了，從而跳過警告部分，直接提示輸入密碼。

每個SSH用戶都有自己的 known_hosts 文件，此外系統也有一個這樣的文件，通常是 /etc/ssh/ssh_known_hosts ，保存一些對所有用戶都可信賴的遠程主機的公鑰。

使用密碼登錄，每次都必須輸入密碼，非常麻煩。好在SSH還提供了公鑰登錄，可以省去輸入密碼的步驟。

所謂」公鑰登錄」，原理很簡單，就是用戶將自己的公鑰儲存在遠程主機上。登錄的時候，遠程主機會向用戶發送一段隨機字元串，用戶用自己的私鑰加密後，再發回來。遠程主機用事先儲存的公鑰進行解密，如果成功，就證明用戶是可信的，直接允許登錄shell，不再要求密碼。

這種方法要求用戶必須提供自己的公鑰。如果沒有現成的，可以直接用 ssh-keygen 生成一個：

運行上面的命令以後，系統會出現一系列提示，可以一路回車。其中有一個問題是，要不要對私鑰設置口令（passphrase），如果擔心私鑰的安全，這里可以設置一個。

運行結束以後，在$HOME/.ssh/目錄下，會新生成兩個文件： id_rsa.pub 和 id_rsa 。前者是你的公鑰，後者是你的私鑰。

這時再輸入下面的命令，將公鑰傳送到遠程主機host上面：

好了，從此你再登錄，就不需要輸入密碼了。

如果還是不行，就打開遠程主機的 /etc/ssh/sshd_config 這個文件，檢查下面幾行前面」#」注釋是否取掉。

然後，重啟遠程主機的ssh服務。

遠程主機將用戶的公鑰，保存在登錄後的用戶主目錄的 $HOME/.ssh/authorized_keys 文件中。公鑰就是一段字元串，只要把它追加在 authorized_keys 文件的末尾就行了。

這里不使用上面的ssh--id命令，改用下面的命令，解釋公鑰的保存過程：

這條命令由多個語句組成，依次分解開來看：

（1） 」$ ssh user@host」 ，表示登錄遠程主機；

（2）單引號中的 mkdir .ssh && cat >> .ssh/authorized_keys ，表示登錄後在遠程shell上執行的命令：

（3） 」$ mkdir -p .ssh」 的作用是，如果用戶主目錄中的.ssh目錄不存在，就創建一個；

（4） 』cat >> .ssh/authorized_keys』 < ~/.ssh/id_rsa.pub 的作用是，將本地的公鑰文件 ~/.ssh/id_rsa.pub ，重定向追加到遠程文件 authorized_keys 的末尾。

寫入 authorized_keys 文件後，公鑰登錄的設置就完成了。

10. SSH和SSL是什麼意思

ssl是通訊鏈路的附加層。可以包含很多協議。https, ftps, …..

ssh只是加密的shell，最初是用來替代telnet的。通過port forward，也可以讓其他協議通過ssh的隧道而起到加密的效果。

解釋原因：

• SSL，即安全套接層(Secure Sockets Layer)，它是一種安全協議，是Netscape公司在推出Web瀏覽器首版時一起提出的。

• SSH，也就是Security Shell，由 IETF 的網路小組(Network Working Group)所制定，是目前較可靠，專為遠程登錄會話和其他網路服務提供安全性的協議。

• SSL有證書中心(CA)公正，可以確定發送者的身份。而SSH沒有，可能會被「中間人攻擊」，它相當於現代版的竊聽。如果攻擊者插在用戶與遠程主機之間(比如在公共wifi區域)，用偽造的公鑰，獲取用戶的登錄密碼。再用這個密碼登錄遠程主機，那麼SSH的安全機制就盪然無存了。不過確保禁用了不安全的SSL/TLS協議，且所訪問的網址前面有HTTPS作為開頭，可以避免大多數的中間人攻擊。SSL終止代理可以處理傳入的SSL連接，解密SSL並將未加密的請求傳遞給其他伺服器。SSL允許您通過簽名證書使用PKI(公鑰基礎設施)。而使用SSH，您必須通過ftp等其他協議手動交換密鑰指紋。

• SSH有一個用戶身份驗證層，這是SSL所缺乏的(不過是因為它並不需要驗證功能)。在使用utf – 8編碼時，SSH協議使用了更多的協議。考慮到有更多的潛在攻擊，SSH的攻擊面似乎更大。但這只是因為SSH內建了一個完整的應用程序。安全性和SSL其實相差無幾。

• 從概念上講，我們可以使用SSH並將隧道部分替換為SSL中的隧道部分，甚至還可以使用HTTPS並使用SSH-with-data-transport替換SSL事務，並使用鉤子從其證書中提取伺服器公鑰。沒有科學上的不可能性，如果做得恰當，它們的安全性將保持不變。