端口可达，不等于服务器已经失陷

“SSH 暴露在公网就不安全”这句话有一定道理，但容易被理解成只要端口开放就必然会被攻破。更准确的判断是：公网可达会扩大攻击面，让扫描、口令尝试和针对 SSH 服务的攻击更容易发生；实际风险还取决于认证方式、账号权限、软件更新情况和网络访问控制。

把端口改成非默认值，通常只能减少一部分自动扫描和日志噪声，不能代替认证和来源限制。对日本服务器而言，判断 SSH 是否暴露，应先确认哪些地址能够连到 SSH 端口，再检查这些连接是否必须经过可靠的身份验证。

密钥认证与来源 IP 限制解决的是不同问题

SSH 公钥认证是身份验证：客户端用私钥证明自己持有对应凭据，服务器通过公钥验证。它能显著减少对 SSH 口令的猜测风险，但不能防止私钥被盗，也不能自动限制哪些网络位置可以发起连接。

来源 IP 限制是网络访问控制：防火墙只允许指定公网地址或网段访问 SSH 端口。它能缩小可连接范围，却不能证明连接者就是授权用户。例如，办公网络出口 IP 下的设备可能共用同一条允许规则；如果其中一台设备或账号失陷，单靠来源限制仍不足以保护服务器。

因此，比较稳妥的做法是两者并用：先在防火墙上限制可达来源，再要求 SSH 使用密钥认证，并以普通账号登录、按需提权。任何一层都不应被当成另一层的替代品。

停用口令前，先确认密钥登录可用

操作前确认自己有服务器控制台或其他可恢复的管理入口，并保持当前 SSH 会话不断开。先在客户端生成密钥，再把公钥配置到服务器对应账号。以下示例适用于支持 Ed25519 的 OpenSSH；若客户端或服务器不支持，应选双方支持的算法。

ssh-keygen -t ed25519 -C "admin-key"

生成时应给私钥设置口令，并妥善保管私钥；不要把私钥上传到服务器，也不要通过不可信渠道传递。把公钥加入服务器用户的 ~/.ssh/authorized_keys 后，先另开一个终端，明确指定该用户和密钥测试登录。只有新会话确认可用，才继续调整认证策略。

服务器端可以检查并设置以下全局项：

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

这些设置的含义是启用公钥认证、关闭 SSH 口令及键盘交互式认证，并禁止 root 直接登录。使用前要确认已有具备管理权限的普通账号和有效密钥；如果当前只能依靠 root 或口令登录，不要先关闭这些入口，应先配置并验证替代登录方式。

不同系统可能通过主配置文件和 Include 文件共同加载 SSH 设置，Match 区段也可能影响特定用户或来源地址。不要只看自己刚编辑的那几行，应先检查配置语法和实际生效值：

sudo sshd -t
sudo sshd -T | grep -E 'pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

如果配置中有针对用户或地址的 Match 规则，还应按实际用户和来源地址核对对应生效配置。确认语法无误、密钥登录已测试后，再按发行版使用的服务名称重新加载 SSH 服务；服务名可能是 ssh 或 sshd，应先核实，不要猜测。重载后保持原会话，另开新会话复测。

按可信来源限制 SSH 端口

来源限制可以设置在主机防火墙，也可以设置在服务器前置的网络防火墙。规则应明确允许的来源地址、目标 SSH 端口和协议，并确保不存在仍对所有来源开放同一端口的宽泛规则。若 SSH 使用的不是 22 端口，应以实际监听端口为准。

例如，使用 UFW 的系统可以先查看当前规则，再为可信出口地址添加 SSH 访问规则：

sudo ufw status numbered
sudo ufw allow from 198.51.100.24 to any port 22 proto tcp
sudo ufw status numbered

198.51.100.24 是示例地址，实际操作要替换为可信网络的公网出口 IP。添加这条规则并不代表限制已经生效：如果原来仍有允许所有来源访问 22 端口的规则，宽泛规则可能继续放行。应结合 ufw status numbered 检查规则，并确认默认入站策略及其他服务规则；不要为限制 SSH 而误删网站、监控或其他管理服务需要的规则。

修改防火墙前保存当前规则和配置，并确保有控制台或其他恢复路径。规则调整后，从允许的网络测试 SSH 登录，再从不在允许范围内的网络测试连通性。确认操作无误后再结束原有会话。如果配置导致无法连接，应通过控制台恢复之前保存的规则；不要在没有恢复入口时直接清空防火墙或批量删除规则。

来源地址要按实际网络情况维护。家庭宽带或移动网络的出口地址可能变化，企业环境也可能经过 NAT；如果允许列表没有及时更新，正常管理者也会被挡在外面。需要考虑 IPv6 是否启用：只限制 IPv4 而让 SSH 仍可通过 IPv6 从任意来源访问，并没有达到预期的限制效果。若管理来源并不固定，可评估先接入具有固定出口地址的可信网络，再从该出口管理服务器。

用实际连接验证，而不是只看配置文件

验证至少要覆盖配置、监听和网络访问三个层面：

1. 检查配置是否生效。 用 sshd -t 检查语法，并用 sshd -T 查看有效设置。若存在按用户或地址区分的规则，应核对对应场景，而不只检查全局值。
2. 确认 SSH 在预期端口监听。 可运行 ss -lntp 查看监听地址和端口。监听在所有接口上，并不必然代表公网可访问；是否能从外部连接，还取决于主机和上游防火墙。
3. 从不同来源测试。 从允许的网络确认密钥登录成功；从不允许的网络确认连接受到阻止。被防火墙拦截时，外部连接可能超时，这与 SSH 服务主动拒绝认证并非同一种结果。
4. 查看登录记录。 观察系统认证日志中是否还有口令尝试、未知账号登录或异常来源。日志路径和服务名称随发行版而异，应使用该系统的日志管理方式核实。

若仍能从非允许来源连上 SSH，优先检查是否遗漏了 IPv6、其他网卡对应的规则、上游防火墙规则，或是否存在另一个 SSH 端口。若允许来源无法连接，则检查出口 IP 是否变化、规则是否应用到正确端口，以及前置防火墙是否也需要同步调整。

这类防护的适用边界

密钥认证和来源 IP 限制适用于管理入口相对明确、允许来源可以维护的场景。它们不能替代及时更新 SSH 软件、移除失效公钥、限制账号权限和保护客户端私钥。若私钥已泄露，应撤销对应公钥并重新配置凭据；仅修改来源规则不应被视为完成处置。

如果业务要求 SSH 必须对任意公网地址可达，来源白名单可能不适用，但仍应停用不需要的认证方式、禁止不必要的 root 登录、控制账号权限并保持软件更新。反过来，只有固定来源白名单、却仍允许弱口令或长期不轮换的共享凭据，也不能算作充分保护。最终要核对的是：谁能连到端口、谁能通过认证，以及登录后能做什么。