Linux海外服务器如何做好基础安全加固？从SSH登录到防火墙逐步配置

目标状态是：服务器不再允许 root 直接登录，管理员通过密钥登录并使用 sudo 提权；SSH、业务端口和管理端口按需开放；系统及时安装安全更新；防火墙采用默认拒绝入站；关键配置和登录行为能够被追踪。下面以使用 systemd、OpenSSH 和 UFW 的 Ubuntu 22.04/24.04 或 Debian 12 为例，给出一套可回滚的 linux系统的海外服务器使用教程。

开始前必须保留当前 SSH 会话，并准备服务器控制台、带外管理或其他应急登录方式。所有 SSH 配置和防火墙变更都应在第二个终端验证成功后，再关闭原会话。以下示例使用 opsadmin 作为管理员账号、22/tcp 作为 SSH 端口；如果实际端口不同，应将命令中的端口替换为当前值。

一、准备条件与现状检查

1. 确认系统、当前用户和监听端口

先确认发行版、当前 SSH 服务名以及服务器正在监听的端口。不要在未确认端口的情况下直接启用防火墙。

cat /etc/os-release
id
hostnamectl
sudo ss -lntup
sudo systemctl status ssh --no-pager

Ubuntu 和 Debian 通常使用 ssh.service，部分发行版或自定义安装可能使用 sshd.service。如果 systemctl status ssh 报错，可以执行：

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

重点关注 ss -lntup 的结果：

• 0.0.0.0:22 或 [::]:22 表示 SSH 可能监听所有网络地址；
• 0.0.0.0:80、0.0.0.0:443 通常是对外提供 Web 服务；
• 数据库、缓存和内部管理服务如果没有对公网提供服务，应尽量只监听 127.0.0.1 或内网地址；
• 仅仅修改 SSH 端口不能代替认证和防火墙加固，端口变更主要用于减少自动化扫描干扰。

2. 备份 SSH 和防火墙状态

防火墙和 SSH 配置变更都可能造成远程失联，先保存备份。备份目录权限设置为仅 root 可读。

sudo install -d -m 700 /root/security-backup
sudo cp -a /etc/ssh/sshd_config \
  /root/security-backup/sshd_config.$(date +%F-%H%M%S)

if [ -d /etc/ssh/sshd_config.d ]; then
  sudo cp -a /etc/ssh/sshd_config.d \
    /root/security-backup/sshd_config.d.$(date +%F-%H%M%S)
fi

sudo ufw status numbered > /root/security-backup/ufw-status-before.txt 2>&1 || true
sudo ufw show raw > /root/security-backup/ufw-raw-before.txt 2>&1 || true

如果服务器使用的不是 UFW，而是其他防火墙管理工具，应先确认现有规则，不能把多个工具同时作为主要规则入口。

二、建立密钥登录和独立管理员账号

1. 在本地生成密钥

在管理员自己的电脑上执行，而不是在服务器上生成私钥。Ed25519 适合大多数现代 OpenSSH 环境，生成时应设置私钥口令。

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

生成后会得到：

• ~/.ssh/id_ed25519：私钥，只保存在本地；
• ~/.ssh/id_ed25519.pub：公钥，可以写入服务器。

不要通过聊天工具、工单或公开代码仓库传输私钥。

2. 创建独立管理员账号

当前仍使用原有可登录账号操作，创建一个专用管理账号：

sudo adduser opsadmin
sudo usermod -aG sudo opsadmin

如果账号已经存在，只执行加入 sudo 组的命令即可。确认权限：

sudo id opsadmin
sudo -l -U opsadmin

在 Ubuntu/Debian 中，sudo 组通常可以执行管理员命令。不要直接给业务账号配置无限制的 NOPASSWD: ALL。需要执行单个运维命令时，应在 /etc/sudoers.d/ 中通过 visudo -f 创建最小权限规则，并用下面的命令检查语法：

sudo visudo -c

3. 写入公钥并验证权限

从本地电脑执行：

ssh-copy-id -i ~/.ssh/id_ed25519.pub opsadmin@SERVER_IP

如果系统没有 ssh-copy-id，可以在服务器上检查目录和文件权限：

sudo install -d -m 700 -o opsadmin -g opsadmin /home/opsadmin/.ssh
sudo chmod 600 /home/opsadmin/.ssh/authorized_keys
sudo chown opsadmin:opsadmin /home/opsadmin/.ssh/authorized_keys

然后从新的终端测试密钥登录：

ssh -i ~/.ssh/id_ed25519 opsadmin@SERVER_IP

此时不要关闭原有 root 或旧管理员会话。必须确认新账号能够登录，并且能够正常执行 sudo，才能继续禁用 root 和密码登录。

三、更新系统补丁

SSH 加固不能替代系统补丁。先查看可更新软件，再执行常规升级。升级可能重启服务，也可能因为内核更新需要重启服务器，因此应避开业务高峰。

sudo apt-get update
apt list --upgradable
sudo apt-get -s upgrade

确认模拟结果不会删除关键软件后执行：

sudo apt-get upgrade

检查是否需要重启：

if [ -f /var/run/reboot-required ]; then
  cat /var/run/reboot-required
  cat /var/run/reboot-required.pkgs 2>/dev/null || true
fi

如果需要重启，先确认业务服务能够自动拉起，并保留控制台入口。可以在维护窗口执行：

sudo systemctl reboot

升级失败时，不要直接删除软件包或手工覆盖系统库。先查看 APT 日志和服务状态：

sudo tail -n 100 /var/log/apt/history.log
sudo systemctl --failed

安全更新通常不建议随意回滚到旧版本；应优先修复依赖、完成未完成配置，并验证服务是否正常。

四、加固 SSH 认证和登录参数

1. 修改前确认配置来源

OpenSSH 可能同时读取主配置文件和 /etc/ssh/sshd_config.d/ 下的配置。先找出相关参数，避免同一参数在多个文件中产生误判：

sudo grep -RniE '^[[:space:]]*(Port|PermitRootLogin|PubkeyAuthentication|PasswordAuthentication|KbdInteractiveAuthentication|AllowUsers|AllowGroups|MaxAuthTries|X11Forwarding|AllowAgentForwarding)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

下面示例编辑主配置文件：

sudoedit /etc/ssh/sshd_config

确保同一参数只有明确的一处生效配置，参考值如下：

Port 22
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowAgentForwarding no
PermitUserEnvironment no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE

参数作用和风险如下：

如果服务器上有多个管理账号，不要直接使用 AllowUsers opsadmin，否则其他账号会被排除。确实需要限制登录账号时，应一次性列出全部账号，例如：

AllowUsers opsadmin deployadmin

AllowAgentForwarding no、X11Forwarding no 可能影响特定运维流程，应用前应确认业务不依赖这些功能。不要为了追求配置数量而关闭正在使用的能力。

2. 检查并平滑加载 SSH 配置

修改后先做语法检查。检查失败时不能 reload 或 restart：

sudo sshd -t

进一步查看 OpenSSH 实际采用的参数：

sudo sshd -T | grep -E '^(port|permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitemptypasswords|maxauthtries|x11forwarding|allowagentforwarding|loglevel) '

语法检查通过后，使用 reload，使已有连接继续保持：

sudo systemctl reload ssh

如果系统使用的是 sshd.service，改用：

sudo systemctl reload sshd

随后从新的终端测试：

ssh -i ~/.ssh/id_ed25519 opsadmin@SERVER_IP

确认新连接成功、sudo 正常后，才可以考虑关闭原会话。

五、按需配置防火墙

1. 只允许必要的入站端口

以 UFW 为例，先确认工具已安装：

command -v ufw || sudo apt-get install ufw

配置默认策略。默认允许出站通常便于系统更新和业务访问，但如果环境有严格的出站控制要求，应另外设计出站白名单。

sudo ufw default deny incoming
sudo ufw default allow outgoing

先放行 SSH，再启用防火墙：

sudo ufw allow 22/tcp comment 'SSH'

如果服务器确实对公网提供 Web 服务，再放行对应端口：

sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

不需要对公网开放的数据库、缓存、内部 API 和监控端口，不应为了“方便测试”直接执行 ufw allow。启用前检查规则：

sudo ufw status numbered

确认 SSH 端口已经允许后，才执行：

sudo ufw enable
sudo ufw status verbose

ufw enable 会改变入站访问行为。如果当前 SSH 端口没有提前放行，远程连接可能立即中断，因此应在第二个 SSH 会话和控制台都可用时操作。

2. 修改 SSH 端口时采用双端口过渡

如果计划从 22 改为 22022，不要先删除旧端口。正确顺序是：

1. 在防火墙中放行新端口；
2. 在 SSH 配置中临时同时保留 Port 22 和 Port 22022；
3. 执行 sshd -t 并 reload；
4. 从新终端测试 22022；
5. 确认新端口工作后，删除旧端口配置和防火墙规则。

示例：

sudo ufw allow 22022/tcp comment 'SSH-new'
sudoedit /etc/ssh/sshd_config

配置中临时保留：

Port 22
Port 22022

检查并加载：

sudo sshd -t
sudo systemctl reload ssh
ssh -p 22022 -i ~/.ssh/id_ed25519 opsadmin@SERVER_IP

确认成功后，再删除 Port 22，并删除旧规则：

sudo ufw delete allow 22/tcp
sudo ufw status numbered

新端口不是安全认证措施，也不能代替密钥登录。不要仅因为扫描日志中出现大量 22 端口探测，就关闭其他安全控制。

六、落实最小权限和服务暴露控制

1. 检查公网监听服务

防火墙规则和服务监听地址必须同时检查：

sudo ss -lntup
sudo ufw status numbered
sudo systemctl --type=service --state=running

如果一个内部服务监听在 0.0.0.0 或 [::]，即使当前防火墙暂时拦截，也应评估是否可以改为监听本机或内网地址。常见处理方式是：

• SSH 只开放给管理来源或管理端口；
• 数据库和缓存只监听 127.0.0.1 或私有网络；
• Web 服务只开放实际使用的 80/tcp、443/tcp；
• 不使用的服务先确认依赖关系，再停止、禁用或卸载。

不要直接批量执行 systemctl disable。某些服务可能被其他程序依赖，错误禁用会造成业务中断。每关闭一个服务，都应记录服务名、用途、原状态和恢复命令。

2. 限制管理员账号权限

日常操作使用 opsadmin，只有安装软件、修改系统配置、重启服务等操作才使用 sudo。不要使用共享账号，也不要把私钥复制到多台不受控设备。

检查管理员的授权范围：

sudo -l -U opsadmin
getent group sudo

如果某个自动化账号只需要重启特定服务，可以使用 sudoers 精确授权，而不是授予全部 root 权限。编辑时使用：

sudo visudo -f /etc/sudoers.d/service-operator

保存后检查：

sudo visudo -c

七、启用基础审计和登录检查

1. 查看 SSH 和系统认证日志

Ubuntu/Debian 常用以下命令检查登录记录：

sudo journalctl -u ssh --since "24 hours ago" --no-pager
sudo tail -n 100 /var/log/auth.log
last -a
sudo lastb -a 2>/dev/null | head -n 30

重点关注：

• 不认识的源 IP；
• 短时间内大量失败登录；
• 非预期时间段的成功登录；
• root 登录尝试；
• 管理员账号的 sudo 操作。

日志中的失败登录不等同于服务器已经被入侵，判断时应结合成功登录、账号变更、文件修改和服务异常一起分析。

2. 记录关键安全配置变化

需要更细粒度审计时，可以安装 auditd：

sudo apt-get install auditd
sudo systemctl enable --now auditd

先备份已有规则文件，再创建独立规则：

sudo cp -a /etc/audit/rules.d/50-hardening.rules \
  /root/security-backup/50-hardening.rules.before 2>/dev/null || true

sudoedit /etc/audit/rules.d/50-hardening.rules

加入以下内容：

-w /etc/ssh/sshd_config -p wa -k ssh_config
-w /etc/ssh/sshd_config.d -p wa -k ssh_config_dropin
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d -p wa -k sudoers

加载并验证：

sudo augenrules --load
sudo auditctl -l
sudo ausearch -k ssh_config -i --start today
sudo ausearch -k sudoers -i --start today

这些规则主要记录 SSH 和 sudo 授权配置的变化，不建议在没有日志容量规划的情况下审计所有命令执行。检查审计日志占用：

sudo journalctl --disk-usage
sudo du -sh /var/log/audit 2>/dev/null

八、验收标准

完成配置后，从新的管理终端逐项验证，不要只看配置文件内容。

密码登录的失败测试不要在唯一的 SSH 会话中进行。可以使用新的终端，并明确指定认证方式：

ssh -o PubkeyAuthentication=no \
    -o PreferredAuthentications=password \
    opsadmin@SERVER_IP

如果命令仍然进入密码认证提示，说明客户端仍在尝试密码流程；最终是否允许登录，应结合服务端日志判断。测试完成后不要反复输入真实密码。

九、常见失败处理与回滚

1. sshd -t 检查失败

不要 reload。查看错误行：

sudo sshd -t
sudo grep -RniE '^[[:space:]]*(Port|PermitRootLogin|PasswordAuthentication|AllowUsers|AllowGroups)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

如果无法快速修复，使用备份恢复主配置，再检查并 reload：

sudo cp -a /root/security-backup/sshd_config.YYYY-MM-DD-HHMMSS \
  /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl reload ssh

实际恢复时，将文件名替换为准备阶段生成的备份文件。恢复前确认当前 SSH 会话仍然存在。

2. 公钥登录失败

保持原会话不退出，依次检查：

sudo ls -ld /home/opsadmin /home/opsadmin/.ssh
sudo ls -l /home/opsadmin/.ssh/authorized_keys
sudo chown -R opsadmin:opsadmin /home/opsadmin/.ssh
sudo chmod 700 /home/opsadmin/.ssh
sudo chmod 600 /home/opsadmin/.ssh/authorized_keys
sudo journalctl -u ssh --since "10 minutes ago" --no-pager

本地增加详细输出：

ssh -vvv -i ~/.ssh/id_ed25519 opsadmin@SERVER_IP

常见原因包括公钥未写入正确账号、文件属主错误、目录权限过宽、客户端使用了错误私钥，以及 SSH 配置中存在未发现的 AllowUsers 或 AllowGroups 限制。

3. 启用防火墙后无法连接

优先通过服务器控制台进入系统，不要反复重启。确认 SSH 服务和规则：

sudo systemctl status ssh --no-pager
sudo ufw status numbered
sudo ss -lntup

如果确认规则配置错误，可以在控制台临时关闭 UFW，恢复连接后重新配置：

sudo ufw disable
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw status numbered
sudo ufw enable

如果使用的是自定义 SSH 端口，应将 22 替换为实际端口。关闭防火墙只是应急回滚，不应作为长期状态。

4. 新 SSH 端口无法访问

保留旧 SSH 会话，确认三处设置：

sudo ss -lntup | grep -E ':(22|22022)[[:space:]]'
sudo ufw status numbered
sudo sshd -T | grep '^port '

只有当 SSH 实际监听新端口、UFW 放行新端口、外部客户端连接参数正确时，才可以删除旧端口。若新端口失败，恢复 Port 22，执行 sshd -t 和 reload，确认旧端口可用后再排查。

5. SSH 配置整体回滚

如果新的 SSH 策略造成管理员无法登录，可在控制台执行：

sudo cp -a /root/security-backup/sshd_config.YYYY-MM-DD-HHMMSS \
  /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl reload ssh

如果使用了新的 drop-in 文件，还需要删除或移出该文件，再重新检查有效配置。回滚后应重新建立管理员密钥登录，再逐项恢复加固项，而不是一次性重新覆盖全部配置。

十、上线前检查清单

• [ ] 已确认当前 SSH 端口、服务名和公网监听服务。
• [ ] 已保留第二个 SSH 会话或服务器控制台。
• [ ] 已创建独立管理员账号，并验证密钥登录和 sudo。
• [ ] 已备份 sshd_config、配置目录和防火墙规则。
• [ ] 已通过 sshd -t 检查配置，且使用 reload 而不是盲目 restart。
• [ ] 已禁止 root 直接登录，并确认没有误伤必要的管理员账号。
• [ ] 已按需关闭密码认证，确认没有依赖该方式的业务流程。
• [ ] 已更新系统补丁，并记录是否需要重启。
• [ ] UFW 已设置默认拒绝入站，只放行 SSH 和实际业务端口。
• [ ] 已检查 ss -lntup，没有将内部服务无必要地暴露到公网。
• [ ] 已验证 SSH、业务访问、防火墙和审计日志。
• [ ] 已保存失败处理和配置回滚命令，确保后续维护可恢复。