答案取决于您的风险偏好。将对 SSH 端口的访问限制为仅已知 IP 地址可以显着减少攻击面。无论出现什么问题（私钥泄露、SSH 中的 0-day 等），它都只能被来自这些特定 IP 地址的攻击者利用。否则，攻击者可以从任何地方访问该端口，这在未修补的 SSH 漏洞和野外可用的漏洞的情况下尤其糟糕。

系统及其数据对您的重要性由您决定。如果它不是那么重要，那么向世界开放的 SSH 端口的便利性可能是合适的。否则，我会建议限制访问，以防万一。SSH 中的严重 0-day 不会每天都出现，但你永远不知道下一个何时会出现。

ssh 密钥将分发给一小部分人。

不，不要那样做。永远不要共享私钥。让你的人自己生成密钥对并收集他们的公钥。采取合理措施确保公钥确实来自正确的人。

或者，如果您不介意麻烦，您可以尝试使用统一的身份验证方案，例如 SSH CA，这样您就可以签署证书，这两者都可以安全地分发（没有私钥，证书毫无用处）。

LDAP 甚至更好，但我不会为小型服务器而烦恼。设置和维护起来太复杂了。

打开一个 SSH 端口到互联网本身并不是不安全的。这取决于它如何进行身份验证。SSH 扫描在互联网上每分钟发生一次。尝试将其仅打开一天并检查/var/log/auth.log无效的用户名。

我想说，只要您使用公钥身份验证并保持私有部分的安全，鉴于 OpenSSH 等常见的 SSH 实现没有 0-days，没有人可以在实际时间内暴力破解您的服务器经常弹出。共享私钥不安全，也不方便。密钥可能在传输过程中泄漏，可能在某些时候您甚至都没有意识到。这就是危险的。

回答 不 不是很不安全，但仍然不理想。

我管理多个 AWS 实例，虽然它们中的大多数都具有限制 SSH 入站访问的安全组，但业务需要其中一个实例在端口 22 上侦听所有连接。

因此，该主机每天都会受到数以千计的脚本小子（skiddy）连接的影响。这在登录时由 MOTD 消息指示，例如

Last login: Fri Jun 19 23:17:36 UTC 2020 on pts/2
Last failed login: Sat Jun 27 01:00:44 UTC 2020 from 120.70.103.239 on ssh:notty
There were 21655 failed login attempts since the last successful login.
host1234 ~ # date
Sat Jun 27 01:12:18 UTC 2020

因此，这大约是每天 2,500 个或每小时 100 个。当然，它们中的大多数只是自动探测，但是如果发现并利用了零日漏洞会发生什么？
通过限制您的暴露，您可以降低风险。

解决方案包括一个/部分/全部：

• 使用 AWS 安全组仅允许来自 Internet 上特定 IP 的连接
• 使用 VPN 解决方案并要求通过 VPN 完成 SSH。VPN 可以监听所有来源，拥有证书和 2FA，并且通常会添加更多层。OpenVPN 运行良好，或者有多个 AWS 产品可以完成相同的任务。
• 将 SSH 移动到另一个端口 - 它不会增加任何安全性，但这确实减少了 ssh 连接尝试的次数，从而减少了噪音。任何称职的人都会扫描所有端口，而不仅仅是默认端口。
• 如果您必须混杂地监听 SSH，请探索类似fail2ban/etc/hosts.deny的解决方案，如果它们在 Y 分钟内失败超过 X 次，它会添加源，并且可以在一天左右后再次删除它们。
• 探索 IPv6 - 就像更改侦听端口一样，IPv6 增加了扫描时间，因此小艇有更多的搜索空间。v6 扫描仍然发生。

对我来说，sshing-in 的设备是硬件，所以它们有一个有效的用户证书并且它们总是成功地验证。我们编写了一个脚本来扫描/var/log/secure并查找“未找到用户”或类似内容，并立即将这些来源永久添加到 hosts.deny 文件中。
我们考虑过扩展它以根据查找阻止整个子网，但这还不是必需的。

我们目前阻止：

host1235 ~ # grep -ci all /etc/hosts.*
/etc/hosts.allow:79
/etc/hosts.deny:24292

我不会分享坏源 IP 的列表，因为有些地方认为 IP 地址是个人身份信息（或 PII）

请注意，我们的办公室 IP 位于hosts.allow其中hosts.deny，因此如果有人从办公室登录失败，那么它不会锁定人类用户。

请要求澄清 - 我知道我已经传达了很多细节。

您可能需要考虑使用AWS Session Manager。当我的公司使用 AWS 时，它似乎不是一个超级广为人知的工具。本质上，它只是让您通过 AWS 控制台从浏览器（或命令行^† ）登录 EC2 实例。您使用 IAM 策略而不是 SSH 密钥进行授权。

冒着听起来像广告的风险，我将继续引用文档的相关部分。

• 没有开放的入站端口，也无需管理堡垒主机或 SSH 密钥

  在您的实例上打开入站 SSH 端口和远程 PowerShell 端口会大大增加实体在实例上运行未经授权或恶意命令的风险。会话管理器允许您关闭这些入站端口，让您无需管理 SSH 密钥和证书、堡垒主机和跳转框，从而帮助您改善安全状况。

因此，如果您确实怀疑打开端口 22 会是一个问题（我认为Demento 的回答很好地涵盖了您是否应该这样做），那么这是一种您可以使用它来保持它关闭，同时仍然允许 SSH 访问（从某个点至少查看）。

†：这里有一个第三方工具可以从命令行使用会话管理器。