☰

你做了什么

tag-icon • tag-icon ssh networking security 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 的公司是否有可能“拦截”该文件并读取该文件的（未加密）内容？

答案1

你做了什么

你用过三ssh命令：

  1. 当在一个乙控制台你做了：

    ssh -4 -N -f -R 18822:localhost:22 <user>@<vps>

    命令 sshd （服务器）打开端口18822，a偏僻的vps:18822连接到本地主机 (B) 端口 22 的端口。

  2. 当在一个虚拟专用网控制台你做了：

    ssh -g -f -N -L 0.0.0.0:18888:localhost:18822 <user>@localhost

    命令 ssh（客户端）打开18888可用端口外部的( 0.0.0.0) 上的 ( vps) 端口连接到内部端口 18822。

    这将打开一个互联网可见端口vps:18888，该端口将流量重定向到18822该端口，而该端口又重定向到B:22.

  3. 当在一个A控制台（和仅有的A 参与的连接）：

    从客户端连接A直接给客户乙在vps:18888。

重要的是最后一个连接。
整个 SSH 安全性取决于验证的A到乙。

这是什么意思

这SSH协议

SSH 通过不安全的网络提供安全通道

通过使用端到端加密

端到端加密 (E2EE) 是一种只有通信用户才能读取消息的通信系统。原则上，它可以防止潜在的窃听者（包括电信提供商、互联网提供商，甚至通信服务提供商）访问解密对话所需的加密密钥。

端到端加密是一个概念。 SSH 是一种协议。 SSH 实现端到端加密。 https 或任何其他数量的加密协议也可以。

如果协议很强大，和实施是正确的，唯一知道加密密钥的各方是两个经过验证的（完） 各方。

由于不知道密钥并且无法破坏协议的安全性，任何其他方都被排除在通信内容之外。

如果，正如你所描述的：从客户端A直接到客户端B您直接向系统 B 进行身份验证，然后，只有客户端 A 和客户端 B 拥有密钥。没有其他。

Q1

案例A：VPS本身没有改动，但流量和文件被完全监控。

只能监控正在发生的通信（日期、时间、最终 IP 等）以及一定量的流量（千字节、兆字节），但无法监控所通信的实际内容。

Q2

情况 B：VPS 完全被破坏，文件系统内容可以被更改。

没关系，即使通信通过其他站点/地点重新路由，知道密钥的唯一两方是 A 和 B。即：如果通信开始时的身份验证是在 A 和 B 之间进行的。

（可选）检查 A 连接的 IP 的有效性，然后： 使用公钥身份验证（仅使用一次只有 A 和 B 知道的私钥-公钥对），完成。

了解你必须确保使用的公钥安全地传送到系统B。您不能信任同一个通道来传送密钥，然后传送加密。有可能破坏协议的中间人攻击。

第三季度

如果我现在通过 SFTP 从客户端 A 向客户端 B 发送文件，托管 VPS 的公司是否有可能“拦截”该文件并读取该文件的（未加密）内容？

不，如果公钥安全地放置在两端，则发生这种情况的可能性微乎其微。

带着带有公钥的磁盘走到对方去安装，再也不用担心了。

评论

从你的评论来看：

Q1

所以，基本上我的设置中的 VPS 除了转发端口之外什么也不做，并且不参与从客户端 A 到 B 发生的实际 SSH 连接或身份验证，对吗？

有点儿。是的，VPS应该不参与认证。但它是“中间”的，也就是说，它从一侧接收数据包并将它们（如果工作正常）传送到另一侧。但还有一个替代方案，VPS（或任何中间设备）可以选择说谎和执行“中间人攻击”。它可能会冒充客户端 B 对客户端 A 撒谎，也可能会冒充客户端 A 对客户端 B 撒谎。这将向“中间人”揭示通信中的所有内容。这就是为什么我强调这个词应该多于。

我还应该说:

...没有工具针对使用公钥方法验证的 SSH 连接实施 MITM ...

基于密码的身份验证是不是公钥方法。

如果您使用密码进行身份验证，您可能会受到中间人攻击。还有其他几种替代方案，但超出了本文的范围。

基本上，使用 ssh-keygen 生成一对密钥（假设在 A 面），并且（为了正确的安全性）将磁盘内的公共部分传送到 B 面并将其安装在授权密钥文件中。做不是使用网络安装公钥，即：不要使用 ssh-copy-id通过网络除非你真的做确切地知道你在做什么，并且你有能力验证B方的身份。您需要成为专家才能安全地执行此操作。

Q2

不过，关于公钥，它不是公开的吗？

  • 是的，它是公开的。
    嗯，是的，生成公私对的实体可以将公共部分发布给任何人（每个人）并且不会丢失任何秘密。如果有人用其公钥加密，那么它就可以用匹配的（和秘密的）私钥解密任何消息。

  • SSH 加密。
    顺便说一下，SSH 加密是对称的，而不是非对称的（公开的）。身份验证是不对称的（或者DH（迪菲-赫尔曼)（对于密码）或RSA、DSA、Ed25519 关键实力或其他（对于公钥）），然后根据该身份验证生成对称密钥并用作通信加密密钥。

  • 用于身份验证。
    但对于 SSH，公钥（使用 ssh-keygen 生成）带有一个额外的秘密：它验证公钥的所有者。

    如果您从互联网收到公钥：您如何知道它属于谁？您相信公钥声称的内容吗？你不应该 ！！

    这就是为什么您应该将公钥文件携带到远程服务器（以安全的方式）并将其安装在那里。之后，您可以信任该（已验证的）公钥作为验证您登录该服务器的方法。

第三季度

我之前也从 VPS 连接到客户端 B（主要是为了测试），这不是已经交换了公钥吗？

它交换一组用于加密的公钥（一组 DH 生成的公钥）。不是验证使用 ssh-keygen 生成的公钥。一旦通信关闭，该通信中使用的密钥就会被删除并被遗忘。

好吧，您还接受（并使用）了一个密钥来验证远程服务器的 IP。确保 IP 安全比简单更复杂（??) 公钥认证。

我的印象是公钥可以共享，但私钥或密码必须保持安全。

你的（总体）印象是正确的，但问题在于细节......

生成密钥对的人可以发布他的公钥，而不会降低他的安全性。

谁收到公钥必须 独立地确认公钥属于他认为属于的人。

否则，公钥的接收者可能会与邪恶的伙伴进行通信。

生成您的密钥

答案2

如果你使用ssh连接A到C，然后C到B，那么它就不是端到端的。它是C的一端，C的另一端。 C 可以看到正在传输的内容。

对于端到端加密，您需要 ssh 连接两端。你经历了什么并不重要。

如果两端看不到对方，但可以看到 C，则可以建立（安全或非安全）连接 A—C 和 B—C。然后使用 ssh 建立安全连接 A—B。

相关内容