香港服务器上线前验收清单：检查SSH连接、端口连通性与服务器安全加固

香港服务器交付后，应按“核对资源 → 验证SSH → 检查业务端口 → 安全加固 → 复测留证”的顺序完成上线验收。能登录不代表业务可用，端口连通也不代表访问权限设置正确。通过标准是：授权来源能正常访问，未授权入口受到限制，实际资源与交付信息一致，异常项有复测记录。

以下命令以已安装OpenSSH的Ubuntu 22.04 LTS、systemd环境为例。操作前准备管理控制台或带外入口，并保留现有SSH会话。其他系统应先确认服务名、日志位置及防火墙工具，不能直接照搬修改操作。

先明确哪些结果才算通过

带宽、线路及香港到目标用户网络的访问质量，应按交付约定和实际业务来源验收。单次Ping不能证明带宽达标，也不能代表所有地区、运营商和时段的访问情况。

第一步：核对资源并验证SSH连接

登录控制台后，先记录系统和资源信息：

cat /etc/os-release
lscpu
free -h
lsblk
df -hT

注意磁盘原始容量与文件系统可用容量不是同一指标；内存显示也可能受单位和系统预留影响。发现差异时，先核对计量口径、分区和挂载状态。

在管理电脑执行以下命令，将示例地址、账号及端口替换为实际交付值：

ssh -vv -o ConnectTimeout=10 -p 22 admin@203.0.113.10

首次连接应通过可信交付渠道或控制台核对主机密钥指纹，不要直接忽略指纹变化提示。控制台可查看常用的Ed25519主机公钥指纹：

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

常见SSH连接问题可按现象分流：

• 连接超时：优先检查地址、路由、上游访问控制和主机防火墙，不能直接判断SSH服务损坏。
• Connection refused：通常表示目标或中间设备明确拒绝，检查监听端口及拒绝规则。
• Permission denied：说明已进入认证阶段，重点检查账号、密钥、文件权限及认证策略。
• 主机密钥变化：先确认是否重装或更换服务器；未核实前不要删除旧记录继续连接。

服务端通过控制台查看：

sudo systemctl status ssh --no-pager
sudo ss -lntp
sudo journalctl -u ssh --since "15 minutes ago" --no-pager

客户端报错时间应与服务端日志对应。认证失败时，日志通常比反复更换密码更有定位价值。

第二步：从监听状态查到业务响应

服务器端口不通，按“进程监听 → 本机访问 → 防火墙 → 外部访问”排查，避免同时改动多层配置。

sudo ss -lntup
sudo ufw status verbose

127.0.0.1:端口表示仅本机可访问；0.0.0.0:端口表示监听所有IPv4接口，但仍可能被防火墙拦截。IPv6监听不能直接证明IPv4可用。UFW未启用也不等于没有其他主机或上游过滤规则；使用Docker时还要检查端口发布及转发规则。

以HTTPS网站为例，在装有nc和curl的外部Linux测试机执行：

nc -vz -w 5 203.0.113.10 443
curl -I --connect-timeout 10 \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

替换示例域名和IP。--resolve可在DNS切换前指定目标，同时保留域名、TLS证书及虚拟主机校验。

• TCP连接成功，只证明该来源到该端口能建立连接，不代表应用正常。
• HTTPS返回预期状态码、证书校验通过，才继续检查页面和业务接口；不应要求所有路径都返回200。
• 本机正常、外部失败，重点查绑定地址及各层访问控制。
• TCP成功但HTTP返回5xx，应转查反向代理、应用服务及其依赖日志。
• 此处测试的是TCP；UDP业务应使用对应协议客户端验证响应。

不要用关闭全部防火墙的方式定位问题。确需临时放行时，只开放必要来源和端口，并记录恢复规则。

第三步：加固后必须重新验收

服务器安全加固应以不丢失管理入口为前提。修改SSH配置前先备份：

sudo cp -a /etc/ssh "/etc/ssh.backup-$(date +%Y%m%d-%H%M%S)"
sudo /usr/sbin/sshd -t

备份包含主机私钥，应保留严格权限，不要上传到工单或公共仓库。加固按以下顺序实施：

1. 建立普通运维账号，配置公钥，并确认必要的sudo权限。
2. 用第二个独立终端验证新账号登录成功，再考虑禁用root远程登录和密码认证。
3. 检查/etc/ssh/sshd_config及其包含的配置文件。存在MFA、自动化账号或Match条件时，应分别验证实际认证策略。
4. 将SSH限制为管理网段、VPN或堡垒机来源；数据库、缓存等内部服务不直接暴露公网。
5. 安排系统安全更新，启用日志、监控和备份；涉及重启时预留维护窗口。

修改后先运行sshd -t，通过后再加载：

sudo /usr/sbin/sshd -t && sudo systemctl reload ssh

保持旧会话不退出，从新终端重新登录。失败时使用旧会话或控制台恢复本次修改的文件，重新检查语法并加载。不要同时修改SSH端口、认证方式和防火墙，否则难以判断锁定原因。

上线签字前保留这些证据

• 记录验收时间、系统版本、交付配置、测试来源网络及目标端口。
• 保存SSH认证结果、监听列表、防火墙规则和应用响应；脱敏账号、地址及敏感请求头，不提交密码或私钥。
• 异常项保留原始报错、对应日志、变更内容，以及相同来源和方法下的复测结果。
• 分别验证“授权来源可访问”和“未授权来源被限制”，避免只测放行路径。
• 确认控制台可用、回滚责任人明确，并在首次计划重启后复查服务自启和规则持久化。

仍存在管理入口不可恢复、非必要公网暴露或业务响应异常时，应保留为未通过项，不以“偶尔能连接”代替上线验收。