新买香港云服务器上线前检查什么？核对SSH登录、端口暴露与系统更新

新买的香港云服务器上线前，至少要完成三类验收：确认 SSH 能用且仍有可靠的管理入口，确认公网真正暴露的端口与业务需求一致，确认系统更新状态和重启要求可控。不要只在控制台看到“实例运行中”就直接绑定域名或部署业务，因为 SSH 配置错误、数据库端口外露和未完成的系统更新，往往会在上线后才暴露风险。

建议按照“保留恢复入口—核对 SSH—盘点监听端口—从外部复测—检查并执行更新—再次复核”的顺序操作。正常标准不是“端口越少越好”，而是每个开放端口都有明确用途、允许来源和责任服务；每个管理账号都能验证登录，且修改 SSH 或防火墙后仍有回滚路径。

一、先确定上线验收标准

开始检查前，先记录服务器的公网 IPv4、IPv6（如果已分配）、操作系统版本、管理员账号、SSH 端口、云平台侧访问控制规则，以及你当前登录服务器的公网出口 IP。

可以把以下内容作为上线前的最低验收标准：

如果服务器尚未部署业务，优先完成安全基线再开放业务端口。如果已经准备上线网站，也应先只开放必要的 Web 端口，其他服务暂时保持内网或本机监听，避免“为了测试方便”把所有端口放开。

二、准备恢复入口和检查环境

1. 保留一个未关闭的 SSH 会话

任何涉及 SSH 配置、防火墙、账号权限的操作，都不要先关闭当前 SSH 会话。至少保留以下恢复条件中的一项：

• 云平台提供的远程控制台、串口终端或救援入口可正常使用；
• 已验证第二个管理员账号可以通过密钥登录；
• 已创建可回滚的系统快照或备份；
• 已明确知道如何在控制台中恢复 SSH 或防火墙规则。

这里的“已验证”是指实际完成过一次登录，而不是账号已经创建。关闭密码登录、禁止 root 登录或调整防火墙之前，应从另一个终端建立第二条 SSH 连接，确认新账号、密钥和 sudo 权限都正常。

2. 记录系统和基础状态

不同发行版的服务名称、包管理器和防火墙工具可能不同，先确认系统，不要直接套用其他系统的命令。

cat /etc/os-release
uname -a
hostname
id
timedatectl
df -h
free -h
systemctl --failed

重点看以下结果：

• /etc/os-release 能确认是 Debian、Ubuntu、Rocky Linux、AlmaLinux 还是其他发行版；
• 当前账号是否为预期账号，是否属于需要的管理组；
• 磁盘是否有足够空间完成更新，尤其是 /、/var 和 /boot；
• 系统时间和时区是否正确，时间偏差可能导致 SSH 密钥、日志和证书判断出现误差；
• systemctl --failed 是否存在启动失败的服务。

如果磁盘已经接近满载，先处理空间问题再更新。包管理器在磁盘不足时可能只完成部分操作，导致 SSH、内核或依赖包处于不完整状态。

三、核对 SSH 登录和加固条件

SSH 检查不能只看“能不能登录”，还要核对登录来源、账号权限、认证方式和配置实际生效值。

1. 从管理终端验证登录

在自己的管理电脑上执行，替换为实际账号和地址：

ssh -vv -o ConnectTimeout=10 admin@203.0.113.20

-vv 会显示认证过程，适合判断连接失败发生在哪一层：

• 出现 Connection timed out，通常先检查云侧访问控制、路由或端口是否可达；
• 出现 Connection refused，通常表示目标地址可达，但该端口没有服务监听，或主机侧主动拒绝；
• 出现 Permission denied (publickey)，说明网络已到达 SSH 服务，问题转向账号、密钥、权限或认证配置；
• 成功进入 shell 后，再执行下面的身份核对：

whoami
id
hostname
sudo -n true
echo $?

sudo -n true 返回 0，通常表示当前账号可以在不交互输入密码的情况下执行 sudo；如果返回非零，不一定代表账号没有管理权限，也可能是系统要求输入密码。此时应使用符合服务器策略的方式再验证一次，不要把密码写入命令或日志。

首次连接时，SSH 客户端会显示服务器主机密钥指纹。不要在无法确认来源时机械输入 yes。可以通过云平台控制台或服务器本地查看指纹，再与管理电脑提示的指纹进行比对：

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

如果服务器没有该文件，可先查看可用的主机密钥：

sudo find /etc/ssh -maxdepth 1 -type f -name 'ssh_host_*_key.pub' -print

ssh-keyscan 可以帮助获取远端当前呈现的指纹，但它本身不能证明服务器身份，仍需要通过控制台、已保存的可信记录或其他独立渠道比对：

ssh-keyscan -t ed25519 203.0.113.20 2>/dev/null | ssh-keygen -lf -

2. 检查 SSH 服务是否正常运行

先确定服务单元名称：

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

常见系统中，Debian、Ubuntu 使用 ssh 较多，RHEL 系列通常使用 sshd。根据实际输出检查状态：

sudo systemctl status ssh

或：

sudo systemctl status sshd

正常状态应当是服务处于 active (running)，并且没有连续重启、配置解析失败或端口绑定失败等错误。若服务状态异常，先查看日志，不要反复执行 restart：

sudo journalctl -u ssh -n 80 --no-pager

如果系统使用 sshd，将命令中的 ssh 替换为 sshd。

3. 检查实际生效的 SSH 配置

直接查看配置文件不一定准确，因为配置可能来自主配置文件、sshd_config.d 下的片段，或者受到 Match 条件影响。先进行语法检查：

sudo sshd -t
echo $?

返回 0 才表示当前配置可以被解析。然后查看关键的生效值：

sudo sshd -T | grep -E '^(port|listenaddress|permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|allowusers|allowgroups)'

重点核对：

• port 是否为预期 SSH 端口；
• listenaddress 是否绑定到了预期地址；
• pubkeyauthentication 是否为 yes；
• passwordauthentication 是否符合你的管理方案；
• permitrootlogin 是否仍允许不必要的 root 直接登录；
• allowusers 或 allowgroups 是否把当前管理员排除在外；
• maxauthtries 是否被设置为异常宽松的值。

如果配置包含按用户或来源地址匹配的 Match 条件，应使用具体参数查看该连接实际得到的配置。下面的命令仅为示例，需替换账号、管理端公网 IP 和主机名：

sudo sshd -T \
  -C user=admin,addr=198.51.100.25,host=server.example \
  | grep -E '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|allowgroups)'

4. SSH 加固的判断边界

如果已经确认管理员密钥可用，通常可以考虑以下方向：

• 禁止 root 直接登录，改用普通管理员账号配合 sudo；
• 不再需要密码登录时，关闭密码认证，仅保留密钥认证；
• 将 SSH 访问来源限制为办公出口、固定管理地址或云侧安全组中的管理网段；
• 不使用的临时账号及时锁定或删除；
• 不把私钥放在服务器上，也不要把私钥内容粘贴到工单、聊天记录或脚本中。

典型配置项如下，但不能在未验证备用入口前直接复制覆盖：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

修改 SSH 配置属于高风险操作。执行前应备份相关配置，确认是否存在 Include 文件，并保持当前会话不退出：

sudo cp -a /etc/ssh/sshd_config \
  "/etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)"
sudo sshd -t

如果配置文件语法检查失败，先恢复备份或修正配置，不要重载服务。语法检查通过后，使用第二个终端验证新账号和密钥，再考虑重载 SSH 服务。不要在唯一会话中直接重启 SSH。回滚时，应通过仍保持的旧会话或云平台控制台恢复配置，并再次执行 sshd -t 后重载。

四、盘点监听端口和公网暴露面

端口检查要分成两层：服务器本地到底有哪些程序在监听，外部网络实际上能访问哪些端口。只看其中一层是不够的。

1. 查看本机监听服务

在服务器上执行：

sudo ss -lntup

参数含义大致如下：

• -l：只显示监听状态；
• -n：直接显示数字地址和端口，避免 DNS 解析干扰；
• -t：查看 TCP；
• -u：查看 UDP；
• -p：显示关联进程。

示例输出：

LISTEN 0 128 0.0.0.0:22    0.0.0.0:*    users:(("sshd",pid=812,fd=3))
LISTEN 0 511 0.0.0.0:80    0.0.0.0:*    users:(("nginx",pid=1260,fd=6))
LISTEN 0 128 127.0.0.1:5432 0.0.0.0:*  users:(("postgres",pid=1430,fd=7))

判断时注意地址范围：

• 127.0.0.1:端口 或 ::1:端口：通常只接受本机访问；
• 0.0.0.0:端口：通常表示监听所有 IPv4 网卡；
• [::]:端口：通常表示监听所有 IPv6 网卡，是否同时接受 IPv4 还要结合系统配置验证；
• 某个内网地址：通常只在对应网卡或私有网络上提供服务。

上例中，SSH 和 HTTP 监听所有 IPv4 地址，PostgreSQL 只监听本机，符合“网站对外、数据库不直接对外”的常见设计。但这仍不是最终结论，因为云侧规则和系统防火墙可能改变外部可达性。

对每个监听端口逐项记录：

如果 ss 显示了未知进程，先记录 PID 和命令路径，再决定是否处理：

sudo ps -fp 1260
sudo readlink -f /proc/1260/exe
sudo systemctl status nginx

不要看到陌生端口就直接执行 kill -9 或删除程序。先确认是否为系统组件、云平台代理或正在使用的业务服务，必要时通过服务管理器停止，并保留回滚方式。

2. 检查云侧和主机侧防火墙

公网访问通常要经过云平台访问控制、服务器操作系统防火墙和具体服务监听三层。三者任意一层拒绝，外部都可能无法访问；三者同时放行，端口才可能真正暴露。

根据系统安装情况选择检查命令，不要盲目启用或清空防火墙规则：

sudo ufw status verbose

sudo firewall-cmd --state
sudo firewall-cmd --list-all

sudo nft list ruleset

同时在云平台控制台核对入方向规则，至少确认：

• SSH 端口是否只允许管理端公网 IP 或明确的管理网段；
• 80、443 是否按照网站需求放行；
• 数据库、缓存、监控和管理面板端口是否被误设为 0.0.0.0/0；
• IPv4 和 IPv6 规则是否分别配置；
• 是否存在一条临时测试规则忘记删除。

如果准备调整防火墙，先保存当前规则或截图，保持当前 SSH 会话，并确认云平台控制台可以恢复规则。防火墙变更的回滚方式应提前写下来，例如恢复原访问控制组、删除新增放行项，或通过控制台进入系统后恢复备份。不要在没有控制台或备用 SSH 的情况下执行“清空所有规则”“默认拒绝全部流量”等操作。

3. 从服务器外部进行端口复测

本机显示监听，只能证明服务绑定了本机地址，不能证明公网可以访问。应使用另一台不在该服务器上的管理电脑进行测试，且只扫描自己拥有或已获授权的地址。

如果管理电脑已安装 Nmap，可以检查明确关心的端口：

nmap -Pn -sT --reason -p 22,80,443,3306,5432 203.0.113.20

如果 SSH 使用自定义端口，应将端口加入列表。例如：

nmap -Pn -sT --reason -p 22022,80,443 203.0.113.20

常见结果可以这样理解：

• open：目标端口可从当前测试位置访问，且有服务响应；
• closed：目标地址可到达，但该端口没有服务监听或被主机明确拒绝；
• filtered：中间防火墙或访问控制没有返回足够信息，不能简单判断服务是否运行；
• 扫描超时：可能是云侧规则、网络路径、地址错误或主机不可达，需要结合 SSH 和其他端口继续判断。

单端口也可以使用：

nc -vz -w 3 203.0.113.20 22
nc -vz -w 3 203.0.113.20 443

对于网站端口，再用应用层请求确认：

curl -I --max-time 10 http://203.0.113.20

如果服务器启用了 IPv6，要单独验证 IPv6 地址和规则：

nmap -6 -Pn -sT --reason -p 22,80,443 2001:db8::20

“扫描不到”不等于“没有风险”。可能是防火墙拦截，也可能是测试地址不对。验收记录中应写明扫描时间、测试来源、目标 IP、端口列表和结果，避免以后无法区分“端口关闭”与“路径不可达”。

五、检查系统更新和重启要求

系统更新的验收重点不是追求“所有包都立即升级”，而是知道当前待更新内容、更新是否涉及 SSH 或内核、是否需要重启，以及应用依赖能否承受服务重载。

1. Debian 或 Ubuntu

先刷新软件包索引并查看可更新内容：

sudo apt-get update
apt list --upgradable 2>/dev/null

正式安装前可先模拟升级：

sudo apt-get -s upgrade

重点关注：

• openssh-server、openssl、内核和系统基础库是否待更新；
• 是否会删除或替换应用依赖；
• 是否存在包管理器错误、仓库连接失败或签名校验失败；
• 是否提示需要重启服务或系统。

确认快照、备份和维护窗口都已准备好后，再执行实际更新：

sudo apt-get upgrade

没有充分验证前，不建议直接使用可能引入更多依赖变化的全量升级方式。更新期间不要强行中断包管理器；如果终端断开，应先重新连接并检查包管理器状态，而不是重复启动多个更新进程。

2. RHEL 系列及兼容发行版

先检查更新状态：

sudo dnf check-update

dnf check-update 返回 0 通常表示没有可用更新，返回 100 通常表示存在可用更新，其他返回值可能表示仓库或执行错误，不能只看屏幕文字。

可以先模拟操作：

sudo dnf upgrade --assumeno

确认影响范围后再执行：

sudo dnf upgrade

如果系统使用较旧的发行版，也可能提供 yum 命令，但应先通过 cat /etc/os-release 确认，不要把 apt、dnf 和 yum 混用。

3. 判断是否需要重启

更新后检查系统是否提示重启：

if [ -f /var/run/reboot-required ]; then
  echo "reboot required"
  cat /var/run/reboot-required.pkgs 2>/dev/null
else
  echo "no reboot marker found"
fi

RHEL 系列可以在系统安装了相应工具时检查：

command -v needs-restarting && sudo needs-restarting -r

如果更新了内核、底层库或 SSH 相关组件，不要只看命令返回成功就宣布完成。安排维护窗口重启后，重新验证：

uptime
uname -r
systemctl --failed

如果业务暂时不能重启，至少应记录“更新已完成但仍运行旧内核”或“某服务尚未重载”的状态，不要把未完成状态当成上线验收通过。

六、更新后重新验证 SSH 和端口

系统更新或重启可能改变服务状态、监听地址、防火墙规则和 SSH 配置，因此必须重复关键检查。

1. 先确认管理入口

从第二个终端重新登录：

ssh -o ConnectTimeout=10 admin@203.0.113.20

登录后确认：

whoami
hostname
sudo -n true

如果 SSH 端口、认证方式或账号策略发生变化，先验证新连接，再关闭旧连接。出现登录失败时，不要立即修改多个配置项，应根据错误类型区分网络不可达、服务未启动、密钥不匹配和权限拒绝。

2. 再确认服务和端口

sudo sshd -t
sudo ss -lntup
systemctl --failed

然后在外部管理电脑重新执行受控端口测试：

nmap -Pn -sT --reason -p 22,80,443,3306,5432 203.0.113.20

验收通过的典型条件是：

• SSH 从允许的管理来源可以连接，从不应允许的来源无法连接或被过滤；
• 预期的 Web 端口状态与业务计划一致；
• 数据库、缓存和管理端口没有意外出现在公网开放列表；
• 本机监听进程、云侧规则、系统防火墙和外部扫描结果能够相互解释；
• 更新后没有出现失败服务或反复重启的服务。

七、异常处理和留证方法

1. SSH 修改后无法登录

优先使用仍保持的旧会话或云平台控制台，不要立刻重装系统。按以下顺序处理：

1. 检查 sudo sshd -t 是否报错；
2. 检查 SSH 服务是否运行；
3. 检查实际监听端口与客户端连接端口是否一致；
4. 检查管理员公钥是否写入正确账号的 authorized_keys；
5. 检查账号家目录和 .ssh 权限是否被错误修改；
6. 恢复最近一次配置备份，再重新验证。

恢复配置后，先执行语法检查，再重载服务。不要同时修改端口、认证方式、账号权限和防火墙，否则很难判断是哪一项造成锁定。

2. 发现不应开放的端口

先记录 ss -lntup 输出、外部扫描结果、关联 PID 和服务状态，再判断来源：

• 如果服务是业务必需，优先限制监听地址或访问来源；
• 如果服务只供本机使用，考虑改为监听 127.0.0.1 或 ::1；
• 如果服务不再使用，通过对应服务管理器停止并设置为不随系统启动；
• 如果服务身份不明，先隔离或暂停上线，保留日志和进程信息，不要直接删除文件。

涉及防火墙的调整，要保留当前 SSH 会话并准备回滚。验证新规则后，再从外部重复扫描，确认端口状态确实发生预期变化。

3. 更新失败或包管理器异常

不要在更新中途强制关机，也不要并行运行第二个包管理器。先查看命令输出和系统日志，确认是否为仓库不可达、磁盘空间不足、锁文件占用或依赖冲突。处理前保存终端输出，并确认快照或备份可用。

如果更新涉及 SSH、内核或基础库，更新失败时不宜直接绑定域名承接生产流量。应先恢复包管理器一致状态，确认服务能够启动，再重新进行完整验收。

4. 保存一份可复核的检查记录

可以建立只对当前管理员可读的记录目录，保存时间、系统版本、监听端口、服务失败状态和 SSH 语法检查结果：

record_dir="$HOME/preflight-$(date +%F-%H%M%S)"
umask 077
mkdir -p "$record_dir"

{
  date -Is
  echo "== OS =="
  cat /etc/os-release
  echo "== Kernel =="
  uname -r
  echo "== Identity =="
  id
  echo "== Failed services =="
  systemctl --failed --no-pager
  echo "== Listening ports =="
  sudo ss -lntup
  echo "== SSH syntax =="
  sudo sshd -t
} 2>&1 | tee "$record_dir/check.txt"

sha256sum "$record_dir/check.txt" > "$record_dir/check.txt.sha256"

记录中不要保存密码、私钥、云平台访问令牌、完整环境变量或包含敏感内容的配置文件。云侧防火墙规则可保存截图或导出文本，但应放在受控位置。外部端口扫描则记录目标地址、测试来源、端口范围、时间和结果。

完成上线前验收后，至少保留以下复核事项：已验证的 SSH 账号和密钥、SSH 配置备份位置、云侧和主机侧防火墙规则、更新前后内核版本、是否需要重启、开放端口清单，以及下一次复查时间。后续每次新增服务、修改 SSH、调整防火墙或完成系统更新，都应重新执行端口和登录复测，而不是沿用第一次上线时的判断。