新 VPS 到手后先别部署：30 分钟完成这 8 项安全检查
新 VPS 上线前，用一份可执行清单完成密钥登录、最小端口、更新、备份与恢复入口检查。
新 VPS 到手后先别部署：30 分钟完成这 8 项安全检查
新机器刚开通时，最容易发生的错误不是命令输错，而是急着装面板、部署网站、开放端口。等服务跑起来才发现 root 密码还在用、所有端口都对公网开放、备份从没配置，修起来会比一开始多花几倍时间。
**先说结论：**安全检查不是把 VPS 变成“绝对安全”，而是先删掉最常见、最不必要的暴露面。先建立一个可以可靠登录、能够回滚和可观察的最小环境，再部署业务。
上线前的 8 项清单
1. 更新系统，并记录版本
登录后先确认发行版、内核和磁盘空间，再更新安全补丁。Debian/Ubuntu 常见的基础动作是：
sudo apt update
sudo apt upgrade -y
sudo reboot
重启后重新登录，确认服务没有异常。更新完成不代表以后不必更新，应给自己设定固定的检查节奏。
2. 创建日常管理用户
root 权限只在必要时使用。创建一个有 sudo 权限的日常管理员，再把公钥加入该用户。关键不是用户名，而是不要让每个人共享一个 root 密码。
sudo adduser ops
sudo usermod -aG sudo ops
3. 先验证密钥登录，再关闭密码
从本地生成密钥、将公钥写入服务器后，务必新开一个终端会话验证密钥登录成功。只有新会话确认可用，才考虑修改 SSH 配置关闭密码登录或 root 远程登录；否则一次配置错误就可能把自己锁在服务器外。
4. 防火墙只允许业务真正需要的入口
远程管理端口只对管理需要开放；Web 服务才开放 HTTP/HTTPS；数据库、缓存和管理面板默认不应直接暴露到公网。不要因为“以后可能用到”就先全放开。
5. Docker 端口不一定受 UFW 预期保护
Docker 官方文档提示：容器发布端口时，可能绕过 UFW/firewalld 的规则。使用 Docker 的机器要额外确认端口发布方式及 DOCKER-USER 规则，详见 Docker 的官方防火墙说明。
6. 从外部确认实际暴露面
安装完应用后，从外部网络再看一次：哪些端口能连、管理后台是否有认证、测试页面是否已删除、默认账号是否已修改。不要只在服务器本机看到“服务已启动”就当成上线完成。
7. 在业务数据出现前配置备份
至少明确应用配置、数据库、上传文件和容器数据卷四类内容。备份目标不要与生产数据只隔一个目录；更重要的是写下恢复步骤，并在非关键数据上做一次恢复演练。
8. 留下监控和应急入口
检查磁盘、内存、证书到期、关键端口和服务进程。保留服务商控制台入口、系统重装/快照规则和最近备份位置；这些信息在 SSH 无法登录时比临时搜索命令更有用。
常见误区
| 常见做法 | 问题 | 更好的做法 |
|---|---|---|
| 只换 SSH 端口 | 减少噪声，不等于身份验证安全 | 密钥登录、最小权限、日志检查一起做 |
| 把所有服务端口映射到公网 | 管理面和数据库暴露 | 只发布必须给用户访问的端口 |
| 先禁密码再测密钥 | 配错就可能无法登录 | 保留会话，新开会话验证后再改 |
| 备份放在同一块磁盘 | 磁盘故障时一起丢失 | 使用独立位置并做恢复测试 |
FAQ
防火墙只留 22、80、443 就够了吗？
不一定。SSH 端口应与你的实际管理配置一致；没有 Web 服务时不必开放 80/443。原则是按需开放，不是固定背一组端口。
关闭 root 登录会影响服务运行吗？
正常服务应由专门用户、systemd 或容器运行，不应依赖日常 root 远程登录。改动 SSH 前先验证新的管理员用户和密钥登录。
下一步需要容器化时，可接着看 第一次用 VPS 部署 Docker。需要一个用于测试、建站或长期运行的实例时，可从 MatrixIDC 的现有配置开始评估。