con*_*tti 6 networking security ssh encryption ssh-tunneling
场景：我想使用 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 直接连接到客户端 B <vps-ip>:18888。效果很好。
现在我的问题是，这有多安全？据我所知，SSH/SFTP 连接是完全加密的，但是在中间使用 VPS 是否有可能使其安全性降低？
让我们假设这两种情况：
案例A：VPS本身没有改变，但流量和文件被完全监控。
情况 B：VPS 被完全破坏，文件系统内容可以被更改。
如果我现在通过 SFTP 将文件从客户端 A 发送到客户端 B，托管 VPS 的公司是否有可能“拦截”它并读取文件的（未加密）内容？
您使用了三个ssh 命令：
在B控制台中，您执行了以下操作：
ssh -4 -N -f -R 18822:localhost:22 <user>@<vps>
命令 sshd（服务器）打开端口18822，远程端口vps:18822连接到本地主机（B）端口 22。
在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.
在A控制台（也是A 参与的唯一连接）时：
从客户端连接一个直接向客户端乙在vps:18888。
重要的是这最后的联系。
整个SSH的安全依赖于身份验证的一个以乙。
所述SSH协议
SSH 在不安全的网络上提供安全通道
通过使用端到端加密
端到端加密 (E2EE) 是一种只有通信用户才能阅读消息的通信系统。原则上，它可以防止潜在的窃听者——包括电信提供商、互联网提供商，甚至通信服务提供商——能够访问解密对话所需的加密密钥。
端到端加密是一个概念。SSH 是一种协议。SSH 实现端到端加密。https 或任何其他数量的加密协议也可以。
如果协议是强大的，并且实现是正确的，那么知道加密密钥的唯一一方是两个经过身份验证的（端）方。
不知道密钥并且无法破坏协议的安全性，任何其他方都被排除在通信内容之外。
如果，如您所描述的：从客户端 A 直接到客户端 B，您直接向系统 B 进行身份验证，那么，只有客户端 A 和客户端 B 拥有密钥。没有其他。
案例A：VPS本身没有改变，但流量和文件被完全监控。
仅可以监视通信（日期、时间、结束 IP 等）以及一定数量的流量（千字节、兆字节）这一事实，而不是通信内容的实际内容。
情况 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 安全比简单的（??）公钥认证更复杂。
我的印象是公钥可以共享，但私钥或密码必须保持安全。
你的（一般）印象是正确的，但细节是魔鬼......
生成密钥对的人可以在不降低其安全性的情况下发布他的公钥。
收到公钥的人必须 独立确认公钥属于他认为属于谁的人。
否则，公钥的接收者可能正在与邪恶的伙伴进行通信。