☰

一个无线网络上的 SSH 主机标识发生变化

tag-icon • tag-icon networking ssh security access-point
一个无线网络上的 SSH 主机标识发生变化

我经常通过 SSH 从 Ubuntu 系统连接到默认端口 22 上的远程服务器。我们称该服务器为example.org。我确信此服务器配置正确，并且我已确认以下问题与我的操作系统无关，并且在重新安装后仍然存在。

有一个特定的Wifi接入点，如果我连接到服务器（ssh example.org），我会得到以下信息：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:[REDACTED].
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:3
  remove with:
  ssh-keygen -f "/home/user/.ssh/known_hosts" -R "serv.org"
ED25519 host key for serv.org has changed and you have requested strict checking.
Host key verification failed.

有问题的接入点属于一个学术机构，似乎比商业 ISP 网络更封闭（例如，我无法从中下载种子）。如果我返回另一个网络（例如，使用我的手机作为接入点），我可以再次连接。

根据Wireshark：

  • 即使在有问题的接入点上，对 的 DNS 查询8.8.8.8也example.org返回相同的 IP 地址。
  • SSH 密钥交换似乎照常发生，但是当我通过有问题的 AP 连接时，服务器在“ECDH 密钥交换答复”中发送的密钥确实具有不同的指纹。

我不明白这个网络在做什么。阻止端口 22 是一回事，但在这里我似乎可以访问服务器并收到错误的密钥作为响应。

此接入点是否会故意篡改 SSH 连接？尽管如此，我是否有办法安全地通过它使用 SSH？我是否应该避免使用它？

答案1

这个系统主机密钥正在更改，或者某人/某物正在对 SSH 连接进行 MITM 攻击。

适当的做法是将该主机视为受到损害（尽管可能不是主机本身，而是连接），除非/直到您有解释。

您可能需要联系该 AP 的系统管理员并告知他们您的顾虑，然后尝试与他们一起追踪此问题。

答案2

因为它是一个学术机构，所以我认为它可能是一个防火墙/安全网关，可以拦截和分析 SSH 流量，以用于数据丢失防护（DLP）或一般审计日志记录等。

例如这样的防火墙：https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/decryption/decryption-concepts/ssh-proxy.html

答案3

davidgo 的回答是正确的。请注意，只要您使用的是公钥身份验证而不是密码，此 MITM 就不会危及您的凭据的安全性。但它确实会危及通过会话传输的任何内容的隐私和真实性。请注意，“通过会话传输的任何内容的真实性”包括（或者说可能完全包括）发送到 shell 或您正在交互的任何进程的命令以及发回的输出。

我最初的建议如下：危险的错误，至少在没有采取进一步措施的情况下：

一个简单的解决方法是双重 ssh。假设您登录的主机允许端口转发，使用受感染的连接登录一次，使用公钥身份验证并启用转发以将本地端口转发到localhost:22，例如-L 12345:localhost:22。现在，您可以运行通过第一个隧道传输的第二个 ssh 会话，除非攻击者积极地预料到您会这样做，否则第二个会话将具有正确的主机指纹，并且您知道它实际上是安全的，不会受到 MITM 的拦截。

这是我匆忙写下的，以简化我心中的正确做法，即拥有一个单独的登录帐户，仅用于转发，没有 shell，我相信在受到攻击（MITM'd）的连接下使用这种方法仍然是安全的，但我仍然建议谨慎行事。也可以设置文件authorized_keys以限制用于初始（MITM'd）登录的密钥，使其无法发出任何命令，只能转发连接；如果是这样，这样的设置应该是安全的。

相关内容