“改用密钥就可以放心开放 SSH”和“加了 IP 白名单就不怕凭据泄露”，都容易被误用。密钥主要降低密码猜测和弱口令风险，白名单主要限制谁能接触登录入口；前者不能阻止互联网扫描，后者也不能防住来自获准网络的攻击。

美国服务器需要保留远程管理能力时，更稳妥的做法是：用独立密钥认证身份，用最小范围的白名单限制来源，再用普通账号与按需提权限制登录后的权限。这个方案成立的前提是管理来源可识别、密钥可撤销，并且有不依赖当前 SSH 会话的恢复入口。

先把“能登录”和“能接触入口”分开

企业技术负责人需要同时考虑两个需求：运维人员能够正常登录，以及不让无关来源长期尝试登录。两者对应不同控制层，不能互相替代。

密钥是身份控制，白名单是网络访问控制。二者叠加才会同时收缩认证风险与入口暴露面。服务器位于美国并不改变这个原理，也不能据此推断其默认安全状态。

如果业务并不需要任意地点直接管理，就没有必要让 SSH 端口面向所有公网来源。更换默认端口可以减少部分扫描噪声，但不应作为密钥和白名单的替代措施。

按管理来源选择白名单边界

白名单应填写服务器实际看到的出口地址，而不是管理员电脑的内网地址。公司出口、VPN 出口、IPv6 地址以及代理路径，都可能影响匹配结果。

IPv4 单地址规则通常使用 /32，IPv6 单地址规则使用 /128。这些只是地址匹配方式，不代表环境中一定有固定地址。实际变更前，应从连接记录或网络侧记录确认来源；SSH 会话中的 SSH_CONNECTION 也可用于辅助查看当前连接地址。

动态公网出口不适合靠“不断扩大网段”维持可用性。放行整个运营商地址段后，白名单的隔离价值会明显下降。若无法获得稳定来源，更合理的选择是先建立受控管理入口，而不是默认允许所有公网地址。

还要检查双栈情况：只限制 IPv4，而 SSH 仍通过 IPv6 对公网开放，不能算完成白名单收口。

先验证密钥，再关闭其他认证入口

以下操作以使用 systemd 的 Ubuntu、OpenSSH 服务端为例，服务名按 ssh 说明。其他环境应先核验实际配置路径与服务名，不要直接照搬。

准备恢复入口与回滚条件

修改前应完成以下准备：

• 确认控制台、串口或救援入口实际可用，而不只是知道入口存在。
• 保留当前 SSH 会话，并用另一个终端测试新连接。
• 备份 /etc/ssh/sshd_config、实际使用的配置片段，以及安全组和主机防火墙规则。
• 准备普通管理账号，验证其需要的 sudo 权限，避免禁用 root 后无法管理。
• 明确回滚方法：认证配置有误时恢复本次改动；白名单有误时从控制台恢复原规则。

认证变更通常影响后续登录，防火墙调整则可能影响新旧连接，具体取决于连接跟踪与规则实现。保留旧会话是缓冲措施，不是可靠的回滚通道。网络层和认证层应分批修改，避免一次操作同时切断两条恢复路径。

每人使用独立密钥

在管理员本地终端生成密钥，示例使用双方均支持的 Ed25519：

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_us_ops -C "ops-admin"

如果目标文件已经存在，应另选文件名，不要覆盖原密钥。交互中应为私钥设置口令，并将私钥留在受控终端；上传到服务器的是 .pub 公钥文件。

在已有可信登录方式下，可安装公钥。以下 ops 和 server.example 均需替换：

ssh-copy-id -i ~/.ssh/id_ed25519_us_ops.pub ops@server.example

首次连接时，应通过可信控制台等渠道核对服务器主机密钥指纹，不要为了省事关闭主机身份校验。安装公钥会增加该账号的登录凭据；应先备份原有 authorized_keys，回滚时只移除本次新增条目，避免误删其他管理员的授权。

随后单独验证密钥登录：

ssh -o IdentitiesOnly=yes \
    -o PasswordAuthentication=no \
    -o KbdInteractiveAuthentication=no \
    -i ~/.ssh/id_ed25519_us_ops ops@server.example

成功后还要验证账号的实际管理权限。多人共用一把私钥会使撤销、追责和设备丢失处理变得困难，不适合长期维护。

收紧服务端认证方式

对明确采用“仅公钥认证”、不依赖密码或 PAM 交互式多因素认证的管理账号，可按以下目标调整配置：

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

这里关闭交互式认证，是为了避免仅关闭 PasswordAuthentication 后仍存在其他口令入口。如果当前登录流程使用键盘交互式多因素认证，以上配置会破坏该流程，必须单独设计认证组合。

不要简单把配置追加到文件末尾。Include、已有条目和 Match 块可能使实际结果与预期不同。编辑后先检查语法：

sudo /usr/sbin/sshd -t

再检查指定用户和来源下的有效配置。示例地址是文档保留地址，应替换为真实管理出口；若存在主机名匹配规则，也应填写实际对应值：

sudo /usr/sbin/sshd -T \
    -C user=ops,addr=203.0.113.10,host=admin.example |
    grep -E '^(pubkeyauthentication|authenticationmethods|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

只有检查通过、服务名确认无误后，再重新加载：

sudo systemctl status ssh
sudo systemctl reload ssh

如果语法检查失败，不要继续加载；恢复或修正本次修改后重新检查。若加载后新连接失败，应利用保留会话或控制台恢复配置，再次检查并加载。

白名单必须覆盖实际生效的入口

网络侧访问控制和主机防火墙承担不同位置的拦截。环境支持时可以叠加使用，但规则应保持一致、变更应有记录，避免一层放行、一层拦截却无人知道。

对于 SSH，目标状态应明确为：

1. 允许指定管理出口访问实际 SSH TCP 端口。
2. 拒绝其他来源访问该端口。
3. 检查并撤销原有的全网放行规则，包括 0.0.0.0/0 和适用时的 ::/0。
4. 同步核对 IPv4、IPv6、其他监听地址和其他 SSH 端口。

“新增一条白名单”不一定等于“其他来源被拒绝”。部分安全组采用允许规则叠加，原有全网规则仍在时，窄范围规则并不会收紧访问；主机防火墙还可能受到规则顺序影响。

防火墙变更前应导出规则，并确认规则优先级、默认策略和恢复方式。不要在远程会话里直接清空规则，也不要套用整套防火墙模板。只调整 SSH 对应入口，可以减少误伤网站、监控等已有业务的范围。

用新连接确认结果，并保留适用边界

变更完成后，至少验证以下四种情况：

• 从白名单来源，使用授权密钥建立全新连接，应成功。
• 从白名单来源，显式禁用公钥认证，仅尝试密码和键盘交互式认证，应失败。
• 从非白名单来源连接，应无法进入 SSH 认证阶段。
• 使用 root 直接登录，应被拒绝；普通管理账号仍能完成必要工作。

测试应避免复用已有 SSH 连接。可在客户端加入 -o ControlMaster=no -o ControlPath=none 强制建立独立连接。测试密码禁用时，应排除客户端自动使用密钥，否则“登录成功”不能证明密码入口仍然开放。

失败结果也要区分：

• 密钥登录被拒绝：核对用户名、公钥是否装入正确账号、文件归属及权限，并查看认证日志。
• 白名单来源连接超时：核对真实出口、IPv4/IPv6 路径，以及网络侧和主机侧规则。
• 非白名单仍进入认证阶段：优先检查残留的全网放行规则、其他监听入口和规则顺序。

即使上述测试全部通过，密钥加白名单也不能替代持续维护。管理员终端被入侵后，攻击者可能同时获得私钥和合法网络来源；白名单中的跳板失陷也有类似风险。因此仍需及时更新 OpenSSH、保护私钥口令，并在人员离职、设备丢失或任务下线时撤销对应授权。自动化密钥还应按需限制命令、转发和交互能力，而不是默认赋予完整管理权限。

对于管理出口固定的美国服务器，可以采用“个人独立密钥＋固定来源白名单＋普通账号提权”；对于移动办公团队，应先稳定受控管理入口，再收紧服务器来源；对于临时维护，应让新增来源和密钥都有明确撤销时间。若恢复入口尚未验证，则先补齐恢复能力，再关闭现有登录路径，比一次性收紧所有规则更可控。