1VPS 1VPS VPS情报 分享有趣

VPS 安全初始化教程：SSH、防火墙、自动更新与备份

这份 VPS 安全初始化教程适用于 Ubuntu 24.04/26.04 LTS 与 Debian 13，按不会锁死远程连接的顺序配置管理员、公钥 SSH、防火墙、自动安全更新、最小暴露和异地备份，并提供逐步验证与回滚方法。

计算阅读时间 0 阅读
VPS 安全初始化教程：SSH、防火墙、自动更新与备份

VPS 安全初始化不是运行一条“加固脚本”，而是按可回滚顺序缩小入口：先取得控制台和备份能力，再建立管理员与公钥登录，确认第二条 SSH 会话可用后关闭高风险入口，最后启用防火墙、自动安全更新和恢复验证。本文适合刚创建的 Ubuntu 或 Debian VPS，不替代应用、数据库和容器自身的安全配置。

本文于 2026 年 8 月 16 日按 Ubuntu 生命周期、Debian 13 稳定版信息及对应官方安全文档复核，适用 Ubuntu 24.04/26.04 LTS 与 Debian 13。Debian 12 上大部分命令相同，但应先确认其软件源和支持状态。预计耗时 30-60 分钟；全程保留当前 SSH 会话，只有新会话验证成功后才继续。

完成初次安全初始化后，如果还要部署 Docker、面板或网站，可继续阅读 VPS 建站与运维指南：SSH、安全、脚本与备份，按验收、部署、备份和回滚顺序延伸。

开始前必须具备的回滚条件

在修改 SSH 或防火墙前先完成以下准备：

  1. 确认服务商控制台、VNC、串口或救援系统能够在 SSH 失效时登录。
  2. 创建一次服务商快照，或至少备份 /etc/ssh、防火墙规则和应用配置；记录恢复入口。
  3. 在本地准备两个终端窗口。第一个保持现有连接，第二个用于反复验证新账号和新规则。
  4. 记录当前 SSH 端口、IPv4/IPv6、已监听端口和业务需要的入站端口。
  5. 如果服务商另有云防火墙或安全组，先确认其规则不会与主机防火墙冲突。

先保存系统和网络基线：

cat /etc/os-release
uname -r
whoami
ip -brief address
ip route
sudo ss -lntup
sudo sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

ss 的结果应与准备开放的服务一致。发现陌生监听端口时先识别进程，不要直接启用一套会中断业务的通用规则。

第一步：更新系统并检查是否需要重启

Ubuntu 和 Debian 都应从已配置的官方软件源获取更新：

sudo apt update
apt list --upgradable
sudo apt upgrade

阅读变更列表后再确认安装，不在生产机上默认使用无人确认的 -y。完成后检查失败服务与重启标记：

systemctl --failed
test -f /var/run/reboot-required && cat /var/run/reboot-required || true

如果内核或关键库要求重启，先确认控制台、快照和维护窗口，再执行 sudo reboot。重新连接后重复系统版本、监听端口和失败服务检查。

第二步：建立非 root 管理员

云镜像可能已经提供 ubuntu、debian 等 sudo 用户；先用 id 判断，不重复创建。如果当前只有 root，可建立独立管理员。纯 Debian 最小镜像没有 sudo 时，先以 root 安装它，执行时可省略命令前的 sudo：

sudo apt install sudo
sudo adduser <ADMIN_USER>
sudo usermod -aG sudo <ADMIN_USER>
id <ADMIN_USER>

预期 id 输出包含 sudo 组。随后切换用户验证权限：

su - <ADMIN_USER>
sudo -v
sudo whoami

最后一条应输出 root。这只说明 sudo 可用，还不能关闭 root 或密码 SSH。

第三步：创建并验证 SSH 公钥

Ubuntu OpenSSH 文档推荐 Ed25519 密钥。密钥应在本地电脑生成，私钥不得上传到 VPS、网盘或聊天工具：

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/<KEY_NAME>
ssh-copy-id -i ~/.ssh/<KEY_NAME>.pub <ADMIN_USER>@<SERVER_IP>

若 SSH 使用非 22 端口，在复制与连接命令中加入 -p <SSH_PORT>。然后从第二个本地终端建立新连接：

ssh -i ~/.ssh/<KEY_NAME> <ADMIN_USER>@<SERVER_IP>
sudo -v

确认新会话能登录、能执行 sudo，并保留原会话。服务器端再检查密钥文件权限：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

如果登录失败，在原会话查看实时日志：

sudo journalctl -fu ssh.service

常见原因是用户名、端口、私钥路径错误，或家目录、.ssh、authorized_keys 可被其他用户写入。

第四步：在确认公钥可用后收紧 SSH

先备份主配置并确认系统启用了片段目录：

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.pre-hardening
sudo grep -nE '^[[:space:]]*Include[[:space:]]+/etc/ssh/sshd_config.d/\*\.conf' /etc/ssh/sshd_config

Ubuntu 官方文档说明，大多数 OpenSSH 指令采用“第一个值生效”，而 Ubuntu 把 sshd_config.d 的 Include 放在主配置顶部。云镜像还可能写入更早加载的片段，因此本文使用靠前的文件名，并以 sshd -T 的有效值为最终依据：

sudo install -d -m 0755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/00-vps-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
EOF

不要立刻重启服务。先检查语法和最终生效值：

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

只有 sshd -t 无输出且有效值符合预期时，才重新加载 SSH：

sudo systemctl reload ssh.service
sudo systemctl is-active ssh.service

再次从第三个终端用公钥登录并执行 sudo -v。同时用未指定密钥的连接确认密码入口已关闭，但不要主动触发大量失败尝试。更改 SSH 端口不会消除扫描，也会增加防火墙、救援和自动化的维护成本，所以本文保留当前端口。

第五步：先放行 SSH，再启用 UFW

Ubuntu 防火墙文档将 UFW 作为简单主机防火墙入口。Debian 13 默认防火墙框架是 nftables，也可安装 UFW 管理简单规则；不要同时维护两套互相不清楚的规则。

先确认 SSH 的有效端口：

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

安装 UFW，设定默认策略，并用实际端口替换占位符：

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw --dry-run allow <SSH_PORT>/tcp
sudo ufw allow <SSH_PORT>/tcp

网站上线前才开放 HTTP/HTTPS；数据库、面板和监控端口不应因为“以后可能用”而提前暴露：

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered
sudo ufw enable
sudo ufw status verbose

启用后立即用新的 SSH 会话复测，并从外部验证网站端口。/etc/default/ufw 中 IPV6=yes 时规则同时覆盖 IPv6；如果 VPS 有公网 IPv6，不能只检查 IPv4。Docker 会管理自己的网络和防火墙规则，部署容器后还要结合 docker ps 与 ss -lntup 复核实际暴露，不能只看 UFW 列表。

第六步：启用并验证自动安全更新

Debian 的 unattended-upgrades 手册说明，该工具由 APT 定时服务执行并记录日志。先安装，再使用发行版提供的配置入口：

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

检查配置、定时器和一次模拟运行：

apt-config dump | grep -iE 'Periodic|Unattended-Upgrade'
systemctl list-timers 'apt-daily*'
sudo unattended-upgrade --dry-run --debug

模拟运行不应安装软件包。正式执行记录位于 /var/log/unattended-upgrades/。自动更新不能代替维护窗口：内核、数据库或运行时更新可能需要重启或应用级验证，生产环境还应监控失败记录，并在变更前保留可恢复备份。Debian testing/unstable 不适用本文的稳定版自动更新假设。

第七步：清点服务和账号，不盲目卸载

安全初始化的目标是让每个公开入口都有用途和负责人。先只读清点：

sudo ss -lntup
systemctl --type=service --state=running
systemctl --failed
awk -F: '$3 >= 1000 && $1 != "nobody" {print $1, $3, $7}' /etc/passwd
last -a | head

对不认识的服务，先用 systemctl status <SERVICE>、systemctl cat <SERVICE> 和包管理记录确认来源。不要删除服务商的网络、磁盘、备份或监控代理，也不要运行声称能自动“清理云监控”的未知脚本。需要测试或诊断工具时，可参考 常用 VPS 脚本工具清单，其中给出了先下载、审查再执行的流程。

第八步：建立异地备份并做一次恢复演练

Ubuntu 备份文档要求备份计划明确对象、频率、位置和恢复方法，并建议保留异地副本。服务商快照适合快速回滚，但同一账号、同一平台或同一故障域中的快照不应是唯一备份。

至少列出以下对象：

  • 应用代码、用户上传文件和环境配置；
  • 数据库的一致性导出，而不是只复制正在写入的数据文件；
  • /etc 中实际修改的系统、SSH、防火墙和服务配置；
  • DNS、证书签发、域名、对象存储和第三方服务的恢复信息；
  • 密钥轮换与紧急账号流程，私钥本身使用单独的加密保管方案。

一次合格的备份任务必须产生可监控的退出状态，并把副本送到不同账号或不同供应商。随后在临时目录或隔离实例中恢复一个配置文件、一个上传文件和一份数据库副本，记录耗时与校验结果。只看到“任务成功”而没有执行恢复，不能证明备份可用。

完成后的验收清单

在关闭最初的 root 会话前逐项确认：

sudo sshd -t
sudo sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '
sudo ufw status verbose
sudo ss -lntup
systemctl --failed
systemctl list-timers 'apt-daily*'
  • 新管理员可从全新会话用公钥登录并执行 sudo；
  • root 与密码 SSH 已按预期关闭；
  • SSH、HTTP/HTTPS 和业务端口同时通过主机与云防火墙验证；
  • IPv4 与 IPv6 均没有意外公开端口；
  • 自动安全更新有定时器、模拟结果和日志位置；
  • 异地备份完成一次真实恢复，而不只是生成文件或快照。

如果还要验收 CPU、磁盘、网络和路由，可按 VPS 测试方法保存初始化后的基线。安全配置完成后再部署面板、Docker 或网站，能更容易识别新增账号、服务和端口。

回滚 SSH 与防火墙

SSH 新配置导致异常时，在仍保持的旧会话或服务商控制台执行：

sudo rm /etc/ssh/sshd_config.d/00-vps-hardening.conf
sudo cp -a /etc/ssh/sshd_config.pre-hardening /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl restart ssh.service

确认原登录方式恢复后再关闭旧会话。UFW 规则错误时，优先从控制台查看编号并删除具体规则；只有完全失联且确认没有其他主机防火墙时，才临时执行 sudo ufw disable，修正后重新启用并复测。服务商云防火墙必须在其控制台单独回滚。

常见问题

关闭密码登录后为什么仍能用密码？

先运行 sudo sshd -T 查看有效配置。OpenSSH 多数指令取第一个值，云镜像片段、主配置和 Match 条件都可能影响结果。确认修改的是服务端 sshd_config，语法检查通过，并已重新加载正确的 ssh.service。

UFW 已启用，为什么端口仍可访问？

先检查服务是否监听公网地址、云防火墙是否另行放行，以及 Docker 或其他容器工具是否添加了独立规则。分别检查 IPv4、IPv6、ss -lntup、UFW 状态和外部探测，不能以一个工具的输出代表全部路径。

是否必须安装 Fail2Ban？

不是。公钥登录、关闭密码入口、最小开放端口和及时更新优先级更高。Fail2Ban 可降低重复认证尝试的噪声，但不能修复泄露密钥、弱权限或公开管理面板；需要时优先使用发行版软件包，并先确认不会封禁自己的固定运维出口。

服务商快照能否代替备份？

不能作为唯一备份。快照可能与生产账号、区域和平台同时不可用，也未必提供应用一致性。关键数据应有独立位置的副本，并通过实际恢复验证。

更新记录

  • 2026-08-16：建立 Ubuntu 24.04/26.04 LTS 与 Debian 13 的首版流程，覆盖 SSH、公钥、UFW、自动安全更新、服务清点、异地备份、验证和回滚。

评论