美国服务器使用CN2 GIA线路，并不意味着主机端口或SSH登录天然安全。上线前应先确认业务实际需要开放哪些端口，再配置主机防火墙；SSH则应先验证密钥登录，再逐步限制密码、root账户和登录用户。所有远程防火墙与SSH变更都应保留当前会话，并准备可用的控制台或带外管理入口，避免配置错误后失去服务器访问能力。

常见现场是：服务器已能正常访问，运维人员准备启用防火墙并关闭密码登录，却没有先放行SSH端口，或还未验证密钥就断开了原会话。判断安全配置是否可上线，不能只看命令是否执行成功，还要从外部确认业务端口可用、非必要端口不可达，并用新会话验证SSH认证结果。

先梳理端口，再调整防火墙

端口加固的目标不是“端口越少越好”，而是只允许业务、管理和必要基础服务使用的入口。Web服务通常需要对外提供HTTP或HTTPS访问；数据库、管理面板和内部服务则应按实际架构限制来源，不能因为应用部署完成就默认向所有地址开放。

上线前可先检查本机正在监听的端口：

sudo ss -lntup

这条命令适用于常见Linux发行版。LISTEN表示存在监听套接字，但不代表该端口一定能从公网访问；还需结合主机防火墙、上游访问控制规则和服务绑定地址判断。对每个监听端口，确认对应进程、用途及访问范围。无法说明用途的监听服务，应先核实其是否为业务必需，不要仅凭端口号猜测服务类型。

可以把端口按以下方式分类：

主机防火墙并非唯一控制层。如果服务器前还有云侧访问控制、机房边界防护或其他网络策略，需同时核对各层规则。外层规则允许而主机防火墙拒绝，服务仍不可达；反过来，主机防火墙放行也不代表外部一定能访问。

UFW环境的操作方式

以下示例适用于已安装并使用UFW的系统。操作前先确认SSH实际端口；如果仍使用默认端口，先添加SSH放行规则，再启用防火墙。不要在未确认规则生效的情况下直接启用或清空规则。

sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status numbered

示例中的业务端口应按实际服务调整。若SSH使用其他端口，应将22替换为真实端口；若只允许特定管理来源，可采用来源地址限制规则，但需确认该地址稳定且不会误排除当前管理出口。UFW规则变更可能影响现有连接及其他业务，执行前应保存当前规则状态，并准备控制台恢复入口。

不要同时套用UFW、firewalld及手工nftables规则来管理同一主机的防火墙，除非已明确它们之间的关系。多套规则并存时，容易出现“规则已添加但访问仍失败”或维护人员无法判断实际生效规则的情况。

firewalld环境的操作方式

使用firewalld的系统，先查看活动区域和已开放项目，再根据实际SSH端口及业务端口添加规则：

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

只有在服务名与本机配置相符时，才使用--add-service。若SSH使用非默认端口或业务服务未定义为firewalld服务，需要按本机端口配置添加规则，并确认规则加入的是实际活动区域。修改前记录原有区域和规则；若重载后管理连接异常，应通过控制台恢复原规则，而不是继续盲目添加放行项。

变更完成后，既要在服务器本机检查规则，也要从外部网络测试预期开放的端口。外部测试失败时，依次核对服务是否监听、监听地址是否正确、主机防火墙是否放行、上游访问控制是否允许；本机连接成功不能代替外部验证。

SSH认证先验证，再收紧

SSH加固最容易出问题的环节，是在没有可用密钥登录时关闭密码认证。较稳妥的顺序是：为运维账户配置密钥并验证新会话；确认账户权限和登录路径正常；再关闭不需要的认证方式；最后限制允许登录的账户。

在管理终端生成密钥的示例：

ssh-keygen -t ed25519

密钥应由实际运维人员保管，私钥不要上传到服务器或放入多人共用的目录。将公钥安装到服务器账户后，另开一个终端测试密钥登录，确认能登录到正确账户并具备所需的管理权限。不要先关闭原有密码登录会话，也不要仅凭公钥文件已存在就认定认证成功。

确认密钥可用后，再检查SSH服务端配置。不同发行版的配置文件、服务名以及是否启用配置片段可能不同，先确认本机实际使用的配置：

sudo sshd -t
sudo sshd -T | grep -E '^(port|permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|allowusers|maxauthtries|logingracetime) '

sshd -t用于检查配置语法；sshd -T显示服务端解析后的有效配置。若系统对命令路径有差异，可先用command -v sshd确认程序位置。配置片段和主配置文件之间可能存在覆盖关系，不能只查看某一行就判断最终生效值。

对于只使用密钥登录、且没有依赖密码或交互式认证的服务器，可在SSH服务端配置中设置类似以下参数：

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
MaxAuthTries 3
LoginGraceTime 30

参数应放在有效的全局配置区域；若文件中已有Match段，需避免把全局设置误放到只针对特定用户或来源的区块内。PasswordAuthentication no可能影响依赖密码登录的运维流程；关闭交互式认证也可能影响已配置的多因素认证，因此不要未经核对就追加相关设置。PermitRootLogin no适用于已准备好具备管理权限的普通账户；先验证该账户可登录并能按需执行管理操作，再禁止root直接登录。

限制可登录账户时，可按团队管理方式配置AllowUsers等规则，但应先逐一确认运维账户名称和来源条件。写错用户名或限制条件可能把管理员全部挡在服务器之外。减少账户数量、使用个人账户而非多人共用账户，有助于追溯操作来源；管理权限只授予确有需要的账户，不应让普通业务账户长期拥有不必要的系统管理权限。

修改SSH配置前，应备份原文件，并保留当前会话。检查语法通过后，使用系统对应的服务管理命令重新加载或重启SSH服务；服务名可能是ssh或sshd，不要不经核验直接套用。重新加载前先用系统工具确认服务名称：

systemctl list-unit-files | grep -E '^(ssh|sshd)\.service'

若无法确认服务是否支持安全重载，应先查询本机服务状态和发行版文档。配置更新后，保持原会话不动，另开新会话测试密钥登录；确认新会话正常后，再结束旧会话。若测试失败，应通过仍在使用的原会话或控制台恢复备份配置，不能在仅剩一条未经验证的连接时继续修改。

最小权限与补丁纳入上线检查

开放端口与账户权限应一起审查。SSH能登录不等于账户应拥有全部管理权限；仅负责查看日志或维护应用的账户，通常不需要直接获得全部系统管理权限。需要提权的操作应由授权账户按职责执行，并定期核对账户、授权配置和离职人员访问权限。

补丁处理也应安排在上线前，而不是只完成防火墙配置后就结束。确认系统仍在维护范围内，检查待更新项目是否涉及系统安全组件和SSH服务；更新前安排维护窗口，评估重启或服务重载对业务的影响，并准备可用的恢复方式。生产环境不宜未经验证就批量更新并立即重启；更新后需检查服务状态、业务健康情况和SSH登录能力。

通过审计发现配置遗漏

防火墙和认证策略生效后，还要确认登录行为可追踪。常见Linux系统可通过系统日志查看SSH相关事件，日志位置与服务配置会因发行版而异：

sudo journalctl -u ssh -u sshd --since "1 hour ago"

若系统未通过上述单元记录日志，应按发行版检查认证日志文件及日志服务配置。还可结合登录记录检查异常成功登录和来源变化：

last

审计时重点关注失败登录是否持续增加、是否出现不认识的账户、是否有非预期的成功登录，以及规则变更是否留下可核对的记录。日志应保留到足以支持日常排查和事件追溯的范围，并限制普通账户随意修改或删除日志。审计日志不能替代实时防护，发现异常后还需核实账户、密钥和服务配置。

上线前复核容易遗漏的环节

最终验证应由外到内进行：从外部确认预期业务端口可访问、非必要端口不可访问；再用新SSH会话确认密钥认证有效、被禁止的认证方式确实无法登录；最后在服务器内核对有效配置、活动防火墙规则、账户权限和近期日志。

若业务端口不通，优先检查服务监听与各层防火墙规则；若SSH新会话失败，先不要关闭旧会话，核对客户端使用的账户、密钥、服务端有效配置和日志提示。若更改认证策略后自动化任务或既有运维流程中断，应确认其是否依赖被关闭的认证方式，再决定调整流程还是恢复配置。

非默认SSH端口只能减少常见扫描带来的噪声，不能替代密钥认证、访问来源限制和日志审计。来源地址限制也只有在管理出口稳定、变更流程可控时才适用。对于上线前尚未验证的规则，应保留备份与控制台恢复路径；对于用途不明的端口、账户或认证依赖，先查清再关闭。