在端口 < 1024（至少在 *nix 服务器上）上运行的服务通常被认为更安全，因为它们需要 root（或具有 root 权限的受信任用户）来启动它们 - 而在端口 >= 1024 上运行的服务可能是由服务器上不受信任的（可能是流氓）用户运行。

因此，您复制的 reddit 帖子中描述的攻击可能会被服务器上的恶意用户在没有 root 权限的情况下实施。

关于"1.The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue."：这是真的 - 如果用户之前已经登录到服务器，并且他的 SSH 客户端固定了服务器的公钥。在这种情况下，用户的 SSH 客户端（可能）会警告他服务器的公钥已更改，并且用户（可能）会知道发生了什么事。但是，只有当用户之前登录到服务器并且他的客户端固定了服务器的公钥时，他才会被警告。

关于"2.If key based authentication is in use, little can be gained from intercepting communications."：我对此持怀疑态度。用户的 SSH 客户端将像往常一样在 SSH 会话开始期间发送其公钥，然后流氓 SSH 服务器可以简单地验证客户端（通常情况下，客户端的公钥存在于服务器的 authorized_keys 文件中）和使用客户端发送的公钥继续会话。

如果在您的 Raspberry Pi 上运行了一个流氓进程，那么您已经被入侵了，尽管攻击者或自动恶意进程显然还没有设法提升到 root 权限。

流氓进程无法访问主机密钥，因此在连接时会向用户显示不同的指纹，从而提醒他们注意问题。

那是真实的。但是，这取决于您的用户是否可能会注意到这一点。在一般系统上，许多用户会点击警告，但是对于使用 SSH 的基于 Linux 的系统，这个标准通常会提高到只有半专家用户才能连接，从而增加了他们意识到出现问题的可能性。

如果使用基于密钥的身份验证，则拦截通信几乎无法获得任何好处。

同意。即使可以从 SSH 客户端检索公钥，流氓服务也无法拦截私钥，因为它从未发送过。

如果改用密码身份验证，则可能存在风险，尽管如前所述，用户将不得不忽略任何主机密钥警告消息。

因此，总的来说，当公钥身份验证到位时，使用非特权端口进行 SSH 不会引入额外的风险。我能想到的唯一攻击是流氓 SSH 守护进程让用户连接，希望用户立即发出 sudo/su 然后输入密码，然后捕获该密码。如果这没有立即完成，那么由于流氓进程不会拥有与真实用户相同的权限，用户可能会注意到有问题。

一些 SE 线程正在从安全角度讨论这个的利弊。更改默认端口号实际上会增加安全性吗？我应该将 SSH 端口更改为 < 1024 吗？.

但是，也存在风险，您提到的流氓进程实际上将您锁定在服务器之外。发生这种情况的可能性可能很低，但如果发生呢？如果您可以在没有 SSH 访问权限的情况下重新启动服务器，您将会很幸运。并且希望在启动时 SSH 守护进程在恶意进程之前声明该端口。