服务器安全基础：新 VPS 到手先做这 6 件事（2026）

官网核实最后核验：2026-11-13 · 依据：Ubuntu、OpenSSH 与 Fail2ban 官方文档的公开转述

一句话结论：新 VPS 到手，按更新、密钥登录、非 root 用户、防火墙、登录防护、备份的顺序做 6 件事；顺序有讲究——先验证密钥能登录再禁用密码，先放行 SSH 再启用防火墙。

核验信息：本文为官网核实，未实测。6 件事的做法来自 Ubuntu 官方服务器文档、OpenSSH 官方手册与 Fail2ban 官方文档的公开转述，命令与配置项名以官方文档为准；本文不贴整段配置文件。逐条来源见研究笔记。

下表是 6 件事的总览，正文按顺序逐件说明做什么、为什么、官方做法是什么。本文以 Ubuntu 为例，其他发行版以各自官方文档为准。

顺序	事项	关键动作
1	系统更新	更新全部软件包，并启用自动安全更新
2	密钥登录	生成密钥、验证登录，再禁用密码登录
3	非 root 用户	新建日常用户加 sudo，禁用 root 直接登录
4	防火墙	默认拒绝入站，只放行需要的端口
5	登录防护	Fail2ban 或等效防护，拦截反复失败的登录尝试
6	备份与快照	拍快照、做备份，并确认备份能恢复

第 1 件：系统更新

做什么：登录后先更新软件包列表并升级全部软件包，升级完成后按提示决定是否重启。接着启用自动安全更新，让系统每天自动安装安全补丁。

为什么：新实例的系统镜像制作于部署之前，软件包可能已落后于最新安全补丁；服务器暴露在公网上，补丁越晚打，暴露窗口越长。

官方做法：Ubuntu 官方文档的做法是使用 apt 更新与升级，并用 unattended-upgrades 实现自动安全更新：安装后用 dpkg-reconfigure 配置，默认只自动安装安全更新；自动重启由 50unattended-upgrades 里的 Automatic-Reboot 与 Automatic-Reboot-Time 控制，内核更新生效需要重启。

第 2 件：密钥登录

做什么：在自己的电脑上生成 SSH 密钥对，把公钥装到服务器对应用户的 authorized_keys 文件里，用密钥登录验证成功后，再禁用密码登录。整个过程中保持当前 SSH 会话不断开。

为什么：密码可以被反复猜测，公网服务器的 SSH 端口每天都会收到大量密码猜测尝试；密钥登录用密钥文件验证，禁用密码登录后，这类猜测就没有了可猜的目标。

官方做法：Ubuntu 官方文档推荐 Ed25519 算法生成密钥（ssh-keygen），并用 ssh-copy-id 把公钥复制到服务器；RSA 4096 位是备选。禁用的关键配置项是 PasswordAuthentication，设为 no；同时确认 PubkeyAuthentication 为 yes；键盘交互认证由 KbdInteractiveAuthentication 单独控制，是否一并禁用，取决于服务器是否依赖它做多因素认证。OpenSSH 对多数配置项取第一个读到的值，而 Ubuntu 的主配置文件会包含 sshd_config.d 目录下的片段文件，云厂商镜像可能已在该目录预置配置；改完后用 sshd -t 检查语法、用 sshd -T 查看实际生效值，确认无误再重启 SSH 服务。

第 3 件：非 root 用户

做什么：新建一个日常用户，加入 sudo 组，让它可以通过 sudo 执行管理命令；把 SSH 密钥装到这个用户，确认能用密钥登录；然后禁用 root 账户的 SSH 直接登录。

为什么：root 账户拥有全部权限，误操作没有二次确认，账户被盗用的后果也是全部权限。日常用非 root 用户、需要时用 sudo 提权，误操作的范围被限制在普通权限内。

官方做法：Ubuntu 官方文档的流程是：用 adduser 创建用户、用 usermod 把用户加入 sudo 组。禁用 root 直接登录的关键配置项是 PermitRootLogin，设为 no；改完后同样用 sshd -T 确认生效值。注意顺序：先建好有 sudo 权限的用户并验证密钥登录，再禁用 root 登录。

第 4 件：防火墙

做什么：启用防火墙，默认拒绝入站连接、默认允许出站连接；放行 SSH 端口，再按实际服务放行端口：Web 服务放行 80 与 443 端口，其他服务按需放行。启用防火墙之前，必须先放行 SSH 端口。

为什么：防火墙决定哪些服务能从公网访问。默认拒绝的策略下，新装的服务即使默认监听在全部地址，也不会直接暴露到公网；最小放行把暴露面压到实际需要的端口。

官方做法：Ubuntu 自带的防火墙前端是 UFW，官方文档的做法是：设置默认策略为拒绝入站、允许出站，放行 OpenSSH 服务名对应的端口，再启用防火墙；放行 Web 端口时用端口号加协议的方式指定。UFW 的 limit 规则可以对 SSH 做速率限制，作为登录防护的补充。需要注意，容器工具（如 Docker）会直接改动底层防火墙规则，容器发布出去的端口可能绕过 UFW 的限制，用容器的服务器要按容器工具的官方文档单独核对。

第 5 件：登录防护

做什么：安装并启用 Fail2ban，启用针对 SSH 的 jail（sshd），让它监视认证日志，对短时间内多次登录失败的来源 IP 做临时封禁；确认服务在运行、jail 已启用。不用 Fail2ban 的，也可以用云厂商的防火墙组、速率限制等效防护代替。

为什么：禁用密码登录后，密码猜测尝试已经无法成功，但尝试本身仍会持续产生日志、占用连接资源；Fail2ban 把反复失败的来源暂时挡在门外，减少无效流量。

官方做法：Fail2ban 官方文档的做法是：从发行版仓库安装，自定义配置写在 jail.local 或 jail.d 目录下的覆盖文件里，不直接改 jail.conf；关键配置项是 bantime（封禁时长）、findtime（统计窗口）、maxretry（失败次数）与 banaction（封禁动作，如配合 UFW）；用 fail2ban-client status 查看 jail 状态。较新的 Ubuntu 与 Debian 默认不再写传统的 auth.log，Fail2ban 需要把 backend 设为 systemd 才能读 systemd 日志；启用后检查 jail 是否真的在监视日志。

第 6 件：备份与快照

做什么：大改动前拍快照，长期运行的服务启用自动备份，网站文件与数据库另外存一份在实例之外的副本；做完备份后，确认备份文件存在、能读取，并实际验证一次恢复流程。

为什么：前面 5 件降低的是被入侵与误操作的概率，第 6 件处理的是“已经出问题”的情况：配置改坏、文件误删时，没有备份就只能重建；有备份但没验证过恢复流程，等于备份的有效性未知。

官方做法：以 Vultr 为例，官方文档区分了手动快照与自动备份：快照手动拍摄，按存储量收费；自动备份按计划自动拍摄，频率可选每天、隔天、每周或每月，费用为实例费用的 20%，备份内容不包括挂载的块存储卷。费用与频率数字见站内Vultr 建站全流程文章。其他服务商的规则各不相同，以各自官方文档为准；无论用哪家，异地副本与恢复验证这两点都不能省。

做完 6 件之后

6 件事做完，服务器就有了基础的安全基线；之后定期确认自动更新与防护都在运行，新增服务时确认只放行了需要的端口，改动 SSH 配置时先验证、再断开旧会话。拿不准的配置，以官方文档原文为准。

局限

本文做法以 Ubuntu 与 2026 年 11 月的官方文档口径为准，其他发行版可能不同。Fail2ban 的 backend 要求与 UFW 的容器绕过问题，来自多家 2026 年指南的转述，未逐项打开官方文档原文核对，操作前以官方文档为准。本文只讲基础的 6 件事，不涉及入侵检测、审计与合规等主题。

更新日志：
2026-11-13：首发