SSH 用於隧道時有多安全？
場景：我想使用 SSH/SFTP 從客戶端 A 連接到客戶端 B。我無法在任一客戶端上打開埠。為了解決這個問題，我得到了一個便宜的 VPS 用作中繼伺服器。
在客戶端 BI 上，使用遠端埠轉發連接到 VPS，如下所示：
ssh -4 -N -f -R 18822:localhost:22 <user>@<vps-ip>在 VPS 上，我使用
-g（全域）設置了本地埠轉發，如下所示：ssh -g -f -N -L 0.0.0.0:18888:localhost:18822 <user>@localhost這樣我就可以從客戶端 A 直接連接到客戶端
<vps-ip>:18888B。效果很好。現在我的問題是，這有多安全？據我所知，SSH/SFTP 連接是完全加密的，但是否有可能通過在中間使用 VPS 來降低安全性？
讓我們假設這兩種情況：
案例A：VPS本身沒有改動，但流量和文件被完全監控。
案例 B：VPS 完全受損，文件系統內容可以更改。
如果我現在通過 SFTP 從客戶端 A 向客戶端 B 發送文件，託管 VPS 的公司是否可以“攔截”它並讀取文件的（未加密）內容？
你做了什麼
您使用了三個ssh 命令：
- 在B控制台中，您執行了以下操作：
ssh -4 -N -f -R 18822:localhost:22 <user>@<vps>命令 sshd（伺服器）打開 port
18822，一個連接到 localhost (B) 埠 22的遠端埠。vps:188222. 在vps控制台中，您執行了以下操作：ssh -g -f -N -L 0.0.0.0:18888:localhost:18822 <user>@localhost命令 ssh（客戶端）打開
18888可用作外部(0.0.0.0) 埠的() 埠，vps該埠連接到內部埠 18822。這將打開一個 Internet 可見埠
vps:18888，該埠將流量重定向到18822該埠，進而重定向到B:22. 3. 在A控制台上（也是A 參與的唯一連接）：在.從客戶端A直接連接到客戶端B。
vps:18888重要的是最後的連接。整個 SSH 安全性
取決於A到B的****身份驗證。
這是什麼意思
SSH協議
SSH 通過不安全的網路提供安全通道
通過使用端到端加密
端到端加密 (E2EE) 是一種通信系統，只有通信使用者才能讀取消息。原則上，它可以防止潛在的竊聽者——包括電信提供商、網際網路提供商，甚至通信服務提供商——能夠訪問解密對話所需的加密密鑰。
端到端加密是一個概念。SSH 是一種協議。SSH 實現端到端加密。https 或任何其他數量的加密協議也可以。
如果協議很強大，並且實現是正確的，那麼知道加密密鑰的唯一方是兩個經過身份驗證的（結束）方。
不知道密鑰並且不能破壞協議的安全性，任何其他方都被排除在通信內容之外。
如果，如您所描述的：從客戶端 A 直接到客戶端 B，您直接向系統 B 進行身份驗證，那麼只有客戶端 A 和客戶端 B 擁有密鑰。沒有其他。
第一季度
案例A：VPS本身沒有改動，但流量和文件被完全監控。
只有通信（日期、時間、最終 IP 等）正在發生並且可以監控一定數量的流量（kbytes、MBytes）這一事實，但不能監控所通信內容的實際內容。
第二季度
案例 B：VPS 完全受損，文件系統內容可以更改。
沒關係，即使通信通過其他一些站點/地點重新路由，知道密鑰的只有兩方是 A 和 B。也就是說：如果通信開始時的身份驗證是在 A 和B.
或者，檢查 A 連接的 IP 的有效性，然後： 使用公鑰認證（僅使用一次只有 A 和 B 知道的私鑰-公鑰對），完成。
了解您必須確保使用的公鑰安全地傳送到系統 B。您不能信任相同的通道來攜帶密鑰然後進行加密。存在可能破壞協議的中間人攻擊。
第三季度
如果我現在通過 SFTP 從客戶端 A 向客戶端 B 發送文件，託管 VPS 的公司是否可以“攔截”它並讀取文件的（未加密）內容？
不，如果公鑰被安全地放置在兩端，那麼發生這種情況的可能性微乎其微。
帶著帶公鑰的盤到對方去安裝，再也不用擔心了。
評論
從您的評論中：
第一季度
所以，基本上我的設置中的 VPS 除了轉發埠之外什麼都不做，並且不參與從客戶端 A 到 B 發生的實際 SSH 連接或身份驗證，對嗎？
有點兒。是的，VPS不應該參與身份驗證。但它是“In-The-Middle”，即它從一側接收數據包並將它們（如果工作正常）傳遞到另一側。但是還有另一種選擇，VPS（或任何中間人）可以選擇撒謊並執行“中間人攻擊”。它可能對假裝客戶 B 的客戶 A 說謊，對假裝客戶 A 的客戶 B 說謊。這將揭示與“中間人”通信中的所有內容。這就是為什麼我在上面強調應該這個詞。
我還應該說：
…沒有針對使用公鑰方法進行身份驗證的 SSH 連接實現 MITM 的工具…
基於密碼的身份驗證不是公鑰方法。
如果您使用密碼進行身份驗證，您可能會受到中間人攻擊。還有其他幾種選擇，但不在本文的範圍內。
基本上，使用 ssh-keygen 生成一對密鑰（假設在 A 面），並且（為了正確的安全性）將磁碟內的公共部分帶到 B 面並將其安裝在 Authorized-keys 文件中。不要使用網路安裝公鑰，即：不要在網路上使用 ssh-copy-id，除非你確實知道自己在做什麼，並且能夠驗證 B 方的身份。您需要成為專家才能安全地執行此操作。
第二季度
不過，關於公鑰，不是嗎，是公開的嗎？
- 是的，它是公開的。
嗯，是的，生成公私對的實體可以將公共部分發布給任何人（每個人），並且不會失去任何秘密。如果任何人只用它的公鑰加密，它就可以用匹配的（和秘密的）私鑰解密任何消息。
- SSH 加密。
順便說一下，SSH 加密是對稱的而不是非對稱的（公共的）。身份驗證是非對稱的（DH（Diffie-Hellman）（用於密碼）或RSA、DSA、Ed25519 密鑰強度或其他（用於公鑰）），然後從該身份驗證生成對稱密鑰並用作通信加密密鑰。
- 用於身份驗證。
但是對於 SSH，公鑰（使用 ssh-keygen 生成）帶有一個額外的秘密：它驗證公鑰的所有者。
如果您從 Internet 收到公鑰：您如何知道它屬於誰？你相信那個公鑰聲稱它是什麼嗎？你不應該 ！！
這就是為什麼您應該將公鑰文件攜帶到遠端伺服器（以安全的方式）並將其安裝在那裡。之後，您可以信任該（已驗證的）公鑰作為驗證您登錄該伺服器的方法。
第三季度
我以前也從 VPS 連接到客戶端 B，主要用於測試，這不是已經交換了公鑰嗎？
它交換一組用於加密的公鑰（一組 DH 生成的公鑰）。不是使用 ssh-keygen 生成的身份驗證公鑰。一旦通信關閉，用於該通信的密鑰將被刪除和遺忘。
好吧，您還接受（並使用）了一個密鑰來驗證遠程伺服器的 IP。確保 IP 的安全性比簡單的 ( ?? ) 公鑰身份驗證更加複雜。
我的印像是公鑰可以共享，但私鑰或密碼必須保持安全。
而且您的（一般）印像是正確的，但魔鬼在細節中…
生成密鑰對的人可以發布他的公鑰，而不會降低他的安全性。
接收公鑰的人必須 獨立確認公鑰屬於他認為屬於誰的人。
否則，公鑰的接收者可能正在與邪惡的伙伴進行通信。