香港服务器使用Linux系统时，如何选择发行版并完成基础安全配置？

香港服务器使用linux系统时，发行版不需要按地域选择，重点应放在应用兼容性、团队运维习惯、软件仓库稳定性和维护周期上。通用网站、API、面板或容器主机，通常可优先考虑仍在维护周期内的 Ubuntu LTS 或 Debian 稳定版；如果现有业务依赖 RPM、DNF、SELinux 或企业级中间件，则可选择 Rocky Linux、AlmaLinux 等 RHEL 兼容发行版。

完成系统安装后，建议按照“确认系统信息 → 创建管理账号 → 更新补丁 → 配置密钥登录 → 加固 SSH → 设置防火墙 → 检查监听服务”的顺序执行。修改 SSH 和防火墙前，必须保留当前登录会话，并确认可以使用服务器控制台或救援终端，以便配置错误时回滚。

一、先确定发行版是否适合业务

1. 根据软件生态选择

不建议仅因为服务器位于香港就更换发行版。地域不会改变 Linux 的软件包管理方式，也不会解决应用本身的兼容问题。应先确认服务器供应商提供的镜像版本仍处于维护周期内，并检查业务软件对系统版本、CPU 架构和内核特性的要求。

登录服务器后，先执行以下检查：

cat /etc/os-release
uname -a
uname -m
df -h
free -h
ip -br addr

重点确认：

• /etc/os-release 中的发行版名称和版本；
• uname -m 是否符合业务软件要求，例如 x86_64 或其他架构；
• 根分区是否有足够空间完成更新；
• 当前登录账号是否具备 sudo 权限；
• 服务器是否能够正常访问软件仓库。

如果发行版与部署脚本不一致，不要直接混用命令。先确认脚本支持范围，再决定更换系统或调整部署方式。

二、部署前准备与安全边界

正式修改前，准备以下条件：

• 已保存业务数据、配置文件和数据库备份；
• 已创建服务器快照，或确认可以通过服务商控制台进入救援环境；
• 已记录当前 SSH 端口，不要假定一定是 22；
• 已准备一台可正常连接服务器的管理终端；
• 当前 SSH 会话保持打开，不要在新连接验证前关闭；
• 已确认服务器上没有正在进行的关键升级、迁移或发布任务。

先检查当前 SSH 端口和监听服务：

sudo sshd -T | awk '$1=="port"{print}'
sudo ss -lntup

如果系统提示找不到 sshd，先查找 OpenSSH 服务端是否安装：

command -v sshd
dpkg -l | grep -E '^ii[[:space:]]+openssh-server' 2>/dev/null
rpm -q openssh-server 2>/dev/null

不要在尚未确认 SSH 服务状态时直接启用防火墙，否则可能把自己锁在服务器外。

三、创建独立管理账号

长期使用 root 账号登录会放大误操作影响。建议先创建一个具备必要管理权限的普通账号，验证成功后再限制 root 远程登录。

1. Debian 或 Ubuntu 系统

以下命令会创建账号并授予 sudo 组权限：

sudo adduser deployadmin
sudo usermod -aG sudo deployadmin
id deployadmin

adduser 执行过程中会要求设置密码。密码仅用于初始管理或应急场景，后续主要使用 SSH 密钥登录。

2. Rocky Linux、AlmaLinux 等 RHEL 兼容系统

sudo useradd -m -s /bin/bash deployadmin
sudo passwd deployadmin
sudo usermod -aG wheel deployadmin
id deployadmin

验证该账号是否可以执行管理操作：

su - deployadmin
sudo -v
sudo id

预期结果中应包含 uid=0(root)，说明 sudo 权限有效。若提示账号不在 sudoers 中，先检查用户是否加入正确的管理组：

id deployadmin
getent group sudo
getent group wheel

不要在此时删除原有管理账号。新账号能够独立登录并完成权限验证后，再考虑禁用不再使用的账号。

四、配置 SSH 密钥登录

1. 在管理终端生成密钥

如果本地尚未有专用密钥，可在管理终端执行：

ssh-keygen -t ed25519 -f ~/.ssh/hk_server_ed25519

私钥只保存在管理终端，不要上传到服务器，也不要通过公开渠道传递。

2. 将公钥写入服务器

如果管理终端安装了 ssh-copy-id，可以执行：

ssh-copy-id -i ~/.ssh/hk_server_ed25519.pub deployadmin@服务器地址

如果没有 ssh-copy-id，可先登录服务器，再执行：

sudo install -d -m 700 -o deployadmin -g deployadmin /home/deployadmin/.ssh
sudoedit /home/deployadmin/.ssh/authorized_keys

将公钥内容写入 authorized_keys，保存后修正权限：

sudo chown -R deployadmin:deployadmin /home/deployadmin/.ssh
sudo chmod 700 /home/deployadmin/.ssh
sudo chmod 600 /home/deployadmin/.ssh/authorized_keys

在启用密钥登录前，先打开一个新的终端验证：

ssh -i ~/.ssh/hk_server_ed25519 deployadmin@服务器地址

登录后执行：

whoami
sudo -v

预期结果分别为 deployadmin 和成功获取 sudo 凭据。如果密钥登录失败，不要关闭原有 root 或管理员会话，先检查：

sudo ls -ld /home/deployadmin/.ssh
sudo ls -l /home/deployadmin/.ssh/authorized_keys
sudo journalctl -u ssh -n 50 --no-pager 2>/dev/null
sudo journalctl -u sshd -n 50 --no-pager 2>/dev/null

RHEL 兼容系统如果启用了 SELinux，还可检查并修正文件上下文：

sudo restorecon -Rv /home/deployadmin/.ssh

五、更新系统补丁

更新前确认已经完成备份或快照。系统升级可能替换内核、系统库和关键服务，升级期间不建议进行业务发布。

Debian 或 Ubuntu

sudo apt update
sudo apt full-upgrade

确认软件包管理器没有未完成的事务：

sudo dpkg --audit
sudo apt-get check

RHEL 兼容系统

sudo dnf upgrade
sudo dnf check

如果升级过程中出现依赖冲突，不要直接使用强制删除或覆盖参数。先保存错误信息，检查冲突软件包和已启用的软件仓库，再根据业务窗口处理。

如果更新了内核或关键系统库，按照维护窗口重启：

sudo reboot

重启后重新登录并确认：

uptime
uname -r
systemctl --failed

如果重启后无法登录，应优先通过服务器控制台查看启动日志，必要时使用升级前快照恢复，而不是反复执行升级命令。

六、加固 SSH 配置

SSH 加固前必须满足两个条件：

1. deployadmin 已经能够使用密钥登录；
2. 当前 SSH 会话仍保持连接，并且具备控制台回退方式。

先备份原配置：

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

检查系统是否加载配置片段目录：

grep -E '^[[:space:]]*Include[[:space:]]+/etc/ssh/sshd_config.d/' \
  /etc/ssh/sshd_config

如果输出包含对应 Include，可以创建配置片段：

sudo install -d -m 755 /etc/ssh/sshd_config.d

sudo tee /etc/ssh/sshd_config.d/99-baseline.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
EOF

如果系统没有加载 sshd_config.d，应使用 sudoedit /etc/ssh/sshd_config 修改已有配置项，或在配置文件前部加入相应设置，不要直接假定新建的片段会生效。

修改后先检查语法，不要未经检查就重启 SSH：

sudo sshd -t

没有输出通常表示语法检查通过。随后确认实际生效值：

sudo sshd -T | grep -E \
'^(permitrootlogin|passwordauthentication|pubkeyauthentication|permitemptypasswords|maxauthtries|logingracetime) '

服务名称可能是 ssh 或 sshd，应根据发行版执行对应命令：

# Debian 或 Ubuntu
sudo systemctl reload ssh

# Rocky Linux、AlmaLinux 等 RHEL 兼容系统
sudo systemctl reload sshd

重新打开一个终端测试：

ssh -i ~/.ssh/hk_server_ed25519 deployadmin@服务器地址

确认能登录后，再检查 root 和密码登录是否确实被限制：

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication) '

如果新的密钥会话无法建立，立即回到原会话，执行 sshd -t 查看错误。不要先重启服务器。

七、配置主机防火墙

防火墙配置的原则是：先放行当前 SSH 端口，再启用防火墙；业务端口只有在应用确认监听后才放行。不要同时启用多个主机防火墙管理工具。

先获取实际 SSH 端口：

SSH_PORT="$(sudo sshd -T | awk '$1=="port"{print $2; exit}')"
printf 'SSH port: %s\n' "$SSH_PORT"

1. 使用 UFW 的系统

先确认 UFW 是否存在：

command -v ufw

放行 SSH 端口并查看规则：

sudo ufw allow "${SSH_PORT}/tcp"
sudo ufw status numbered

确认规则无误后再启用：

sudo ufw enable
sudo ufw status verbose

2. 使用 firewalld 的系统

command -v firewall-cmd
sudo firewall-cmd --state
sudo firewall-cmd --permanent --add-port="${SSH_PORT}/tcp"
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

如果应用已经确认监听 HTTP 或 HTTPS 端口，再按实际需求放行对应端口。不要为了“方便测试”开放所有端口。

检查防火墙后，从另一台终端重新建立 SSH 连接：

ssh -i ~/.ssh/hk_server_ed25519 -o ConnectTimeout=10 \
  deployadmin@服务器地址

如果无法连接，先不要重复添加规则。确认是主机防火墙、服务商侧访问控制，还是 SSH 服务本身拒绝连接。

八、完成基础运行状态检查

系统更新、账号和防火墙配置完成后，执行一次整体检查：

sudo ss -lntup
sudo systemctl --failed
sudo journalctl -p warning -b --no-pager | tail -n 50
timedatectl status

重点核对：

• 监听端口是否只有业务需要的服务；
• SSH 是否监听在预期端口；
• 是否存在启动失败的系统服务；
• 当前时间同步服务是否正常；
• 日志中是否有 SSH、磁盘、文件系统或权限错误。

如果系统使用 systemd，可以确认自动启动状态：

systemctl is-enabled ssh 2>/dev/null || systemctl is-enabled sshd
systemctl is-active ssh 2>/dev/null || systemctl is-active sshd

业务服务安装完成后，还应从服务器本机验证应用端口：

sudo ss -lntp
curl -I http://127.0.0.1:应用端口

curl 返回应用响应，且监听地址、端口与防火墙规则一致，才适合进行外部访问测试。

九、常见失败处理与回滚

SSH 配置错误

先检查：

sudo sshd -t

如果语法检查失败，使用备份文件恢复。将实际备份路径替换为创建时记录的文件：

sudo cp -a /etc/ssh/sshd_config.bak.创建时间 \
  /etc/ssh/sshd_config
sudo sshd -t

确认无误后重新加载服务：

# Debian 或 Ubuntu
sudo systemctl reload ssh

# RHEL 兼容系统
sudo systemctl reload sshd

如果使用了配置片段，还要暂时移除或重命名新增片段，再执行语法检查。

防火墙导致无法连接

如果仍有已建立的 SSH 会话，可以撤销刚才的规则：

# UFW
sudo ufw status numbered
sudo ufw delete allow "${SSH_PORT}/tcp"

# firewalld
sudo firewall-cmd --permanent --remove-port="${SSH_PORT}/tcp"
sudo firewall-cmd --reload

如果已经无法通过 SSH 访问，使用服务器控制台执行恢复。UFW 可以临时关闭：

sudo ufw disable

firewalld 可以停止服务进行定位，但停止防火墙会扩大暴露面，故障确认后应尽快恢复正确规则：

sudo systemctl stop firewalld

密钥登录失败

按以下顺序检查：

1. 公钥是否完整写入 authorized_keys；
2. .ssh 目录权限是否为 700；
3. authorized_keys 权限是否为 600；
4. 文件所有者是否为目标用户；
5. SSH 配置是否启用了 PubkeyAuthentication yes；
6. SELinux 是否阻止了密钥文件访问；
7. 客户端是否使用了正确的私钥文件。

不要通过放宽整个用户目录权限来“解决”登录问题。

更新后服务无法启动

先查看具体服务状态和日志：

sudo systemctl status 服务名 --no-pager
sudo journalctl -u 服务名 -b --no-pager

确认是配置错误、依赖变化还是端口冲突后再处理。软件包升级通常不能简单地用一个命令完整回退，因此生产环境应优先使用快照或备份恢复，避免直接批量降级系统组件。

验收与回滚清单

验收时至少确认以下项目：

• 发行版版本符合业务软件支持范围；
• deployadmin 可以使用 SSH 密钥登录；
• sudo -v 执行成功；
• root 远程登录和密码登录策略符合预期；
• sshd -t 检查通过；
• SSH 服务处于 active 状态；
• 防火墙仅开放 SSH 和已确认的业务端口；
• systemctl --failed 没有关键失败服务；
• 监听端口与业务清单一致；
• 时间同步和磁盘空间状态正常；
• 当前会话、新密钥会话、服务器控制台三种管理路径至少保留两种可用。

图示对应原文命令：deployadmin。 需要回滚时，优先按照“恢复 SSH 配置备份 → 撤销新增防火墙规则 → 通过控制台确认服务状态 → 必要时恢复系统快照”的顺序操作。不要在无法验证新连接的情况下关闭旧会话，也不要在未确认备份有效性前删除原有管理账号。