刚买的 2核2G 云服务器（当前参考低至 ¥38/年，价格查询于 2026-10-02），装好 Ubuntu 24.04 LTS 后如果只挂着 root 账号暴露在公网上，几分钟内就会被自动探测脚本盯上。第一小时不做完基础加固，机器等于在毫无防备地运行。
新机器的初始状态往往权限过大且端口全开。本文梳理了 Ubuntu 服务器初始化的核心流程。依次完成这 6 步，能把大量的自动探测请求挡在门外。
为什么要花时间做这些设置？
没有任何加固的机器平均无干扰运行时间是以分钟计算的。当你拿到一台全新的服务器时，它的状态就像一栋大门敞开、没有任何访问控制的仓库。
| 隐患 | 后果 | 解决方案 |
|---|---|---|
| root 直接暴露 | 密码猜测成功后接管整台机器 | 建立非 root 账号，禁用密码验证 |
| 端口默认全开 | 内部数据库测试服务对外暴露 | 开启防火墙放行白名单端口 |
| 缺乏操作限制 | 敲错命令把系统损坏无法恢复 | 限制默认权限，用 sudo 提权 |
1. 连入机器拿到 root 控制权
任意云厂商下发机器后，都会提供公网 IP 和初始凭证。第一时间通过终端连入服务器，直接使用系统提供的最高权限账号完成接下来的系统级操作。
威胁：云服务商默认分配的随机密码或旧版镜像的配置通常存在弱点。尽早登录接管系统是后续一切防守操作的前提。如果不及时登录并修改，可能会被自动化脚本通过默认凭证进入。
命令：
把 your_server_ip 替换为真实的公网 IP。
ssh root@your_server_ip验证：如果遇到主机真实性警告，输入 yes 继续。输入凭证后，终端前缀变为 root@hostname:~#，代表已获得服务器的控制权。
2. 建立日常受限账号
root 账号具备修改一切核心文件的权限。使用 root 长期在线操作时，一个敲错路径的删除命令就会引发不可逆的事故。建立一个权限受限的普通账号是隔离风险的第一道防线。即使普通账号被越权访问，外部人员也只能在用户目录下活动，无法轻易破坏系统组件。
威胁：滥用超级管理员身份运行日常服务，一旦服务由于自身弱点被利用，外部人员将直接接管整台宿主机。
命令：
创建一个名为 deployer 的常规账号。
adduser deployer验证：终端会要求设置强密码以及用户全名等信息。连续回车跳过附加信息，提示 Is the information correct? [Y/n] 时输入 Y 完成新建。
3. 分配 sudo 临时提权能力
普通账号无法修改系统配置、安装软件或管理后台进程。把新账号加入系统的管理白名单，能在需要时临时调用管理员指令，不需要在 root 和普通账号之间来回切换。
威胁：频繁切换到 root 操作不仅繁琐，还会打断工作流，更容易让人因为怕麻烦而长期停留在 root 环境。合理的做法是用普通账号操作，遇到需要权限的动作再加上 sudo。
命令：
Ubuntu 系统默认赋予 sudo 组成员这种临时提权的能力。
usermod -aG sudo deployer验证：执行 su - deployer 切换身份，再输入 sudo ls -la /root。系统要求输入一次用户密码，随后输出 /root 目录内容，证明提权机制已生效。
4. 迁移 SSH 密钥验证文件
很多云服务器在创建时会强制注入 SSH 密钥，此时基于密码的登录通常处于禁用状态。必须把 root 目录下的密钥公钥文件平移给新账号，否则新开的账号后续将无法通过 SSH 连入机器。
威胁：新账号缺少合法的鉴权文件，退出当前终端后就会被系统锁在外面。
命令：
使用 rsync 连同权限一起精确复制 .ssh 目录。
rsync --archive --chown=deployer:deployer ~/.ssh /home/deployer验证：执行 ls -la /home/deployer/.ssh，确认目录所有者已变成 deployer，且包含真实的 authorized_keys 文件。
5. 启用 UFW 防火墙放行核心端口
Ubuntu 自带 UFW 简单防火墙组件，它可以拦截所有未经授权的网络访问请求。但在开启它之前必须先放行 SSH 通信端口，否则防火墙规则启动的瞬间就会把当前的远程管理连接直接切断。
威胁：默认全端口开放会把后续安装的数据库、缓存等内部服务全部暴露给外网。关于更详细的规则拦截策略，可以查看 server-security-hardening。
命令： 先放行负责管理连接的 OpenSSH 预设配置。
ufw allow OpenSSH
ufw enable验证：输入 y 确认开启。执行 ufw status，终端输出 Status: active 且列表中包含 OpenSSH ALLOW Anywhere。
6. 停用密码身份验证机制
在当前会话不退出的前提下，新开一个终端窗口用新账号测试免密连接。连接成功后，关闭系统的密码登录途径。
威胁：只要开启密码登录，每天就会收到成千上万次来自外部的密码猜测尝试。关闭它能把系统由于密码较弱被登录的概率降到零。
命令： 打开 SSH 守护进程的主配置文件。
sudo nano /etc/ssh/sshd_config找到 PasswordAuthentication 字段，把对应的值修改为 no，然后重启相关服务：
sudo systemctl reload sshd验证：在新终端尝试用错误密码或不存在的账号登录，服务器不会再弹出密码输入框，而是直接抛出 Permission denied (publickey) 拒绝请求。
自动化脚本环境一次注入
如果你需要大批量初始化服务器，手动敲命令耗时费力。通过任意云控制台的初始化脚本功能，可以在开机时一次完成上述加固。
将下面这段脚本在创建服务器时粘贴进云主机的自定义数据框即可：
#!/bin/bash
# 自动建立账号并配置权限
adduser --disabled-password --gecos "" deployer
usermod -aG sudo deployer
# 迁移当前临时密钥
rsync --archive --chown=deployer:deployer ~/.ssh /home/deployer
# 配置防火墙规则
ufw allow OpenSSH
ufw --force enable
# 关闭密码验证并重启服务
sed -i 's/^#*PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl reload sshd脚本跑完后，你就可以直接用 deployer 账号结合私钥免密连入系统，跳过中间繁琐步骤。
日常维护边界：什么时候用 root
虽然我们建立了一个新用户来隔离风险，但并不意味着这台机器上 root 就失效了。在实际使用场景中，权限的划定有一条清晰的界线。
普通用户配合 sudo 可以满足绝大多数的日常操作，包括包管理安装、配置修改、服务重启等。只有在以下少数场景下，才会用 sudo su - 短暂切换到超级管理员环境：
- 需要大量对系统内核参数进行深层次调优时。
- 需要反复修改属于 root 的核心守护进程配置并排查日志时。
常见问题（FAQ）
1. Ubuntu 24.04 LTS 需不需要手动安装 UFW？
最新版 Ubuntu 安装镜像已将 ufw 和 openssh-server 作为默认核心系统包预装。只要不是精简的容器基础镜像，开箱即可直接执行上述命令。
2. 更改默认 SSH 端口能提高安全性吗？
改端口只能过滤掉最基础的全网盲扫，挡不住任何针对目标主机的定向探测。依赖密钥认证和严格防火墙才是本质解法，单纯改端口没有实质的防御收益。
3. rsync 复制密钥时多加了斜杠怎么修复？
如果在源路径敲成了 ~/.ssh/，命令会把文件夹里的具体文件直接散落到新用户的根目录下，而不是创建对应的 .ssh 目录。清理掉 /home/deployer/ 下的散落文件，去掉源路径末尾的斜杠，重新运行一次完整命令即可恢复。
参考链接：
- Initial Server Setup with Ubuntu
