VPSMapConnect Globally. Live Freely.
客服
系统与运维

创建管理用户并理解 sudo 权限

VPSMap 编辑整理 · 内容更新 2026-09-26 · 19 分钟阅读 · 纯文本版本

在刚刚交付的 Linux 云服务器中，绝大多数镜像默认使用 root 账户作为初始登录入口。root 拥有不受约束的最高系统调用特权，任何一次带有笔误的文件覆写、错误的 rm -rf 路径或异常的权限变更（如 chmod -R 777 /），都会直接造成不可逆的系统崩溃或数据毁损。同时，在开放的公网 IPv4 环境下，针对 root 用户名发起的 SSH 端口暴力破解与弱口令扫描从未停歇。

建立正规的运维习惯，第一步就是创建具备明确归属的普通管理账户，通过 sudo 按需提权执行特权指令，并在验证完成后封堵 root 远程直连通道。

1. 为什么运维必须隔离 root 与日常操作#

将日常操作与特权执行分离开来，核心价值体现在三个工程维度：

  1. 构筑操作缓冲带（Safety Margin）：普通用户在执行系统级变更时，必须显式前缀 sudo。这一动作提供了心理缓冲与命令复核的机会，避免在日常切换目录、编辑应用配置或清理缓存时，因敲错通配符而伤及系统底层文件。
  2. 命令审计与可追溯性：系统日志（如 /var/log/auth.log 或 /var/log/secure）会精确记录每一次 sudo 调用的执行时间、发起用户、所在工作目录以及调用的完整指令。一旦多名工程师协同维护或发生异常变更，追溯根因远比所有人都直接共享 root 终端更清晰。
  3. 收敛攻击暴露面：禁用 root 远程登录后，外部恶意扫描工具无法直接利用固定的用户名猜测凭证，攻击者必须同时猜中特定的管理员用户名和高强度密钥或密码，入侵难度成倍增加。

服务商默认环境差异与带外救援通道#

在着手修改任何账户和认证配置之前，必须清楚当前服务器的初始状态及应急手段：

  • DMIT 实例：DMIT 的系统镜像在初始化时默认推行 SSH 密钥验证，其默认安全策略通常直接禁用远程 root 密码登录。若需要重置密码或更新公钥，可通过 DMIT 控制面板的「Access」标签页进行管理（注意：根据 DMIT Docs 规则，通过面板更换 SSH 密钥或密码后，必须按提示在面板中重启实例方可写入生效）。此外，DMIT 提供了基于 Web 的「Console」控制台，这是发生配置错误时的关键救援入口。
  • BandwagonHost（搬瓦工）实例：搬瓦工的认证体系划分得非常清晰——客户中心账单密码、KiwiVM 管理面板密码与操作系统的 root 密码彼此独立。KiwiVM 面板内置了「Interactive Console」（交互式终端）和「VNC」，即使在 SSH 配置写错、防火墙规则阻断或网络服务故障时，也能脱离公网 SSH 链路直接登录底层 Shell。

核心原则：在新建管理用户、配置公钥与调整 sudoers 的全过程中，切勿关闭最初建立的那个 root SSH 连接。所有测试操作都必须在电脑上开启新的本地终端窗口发起验证；一旦新窗口出现鉴权失败，原有的 root 终端仍可实时纠偏。

2. 环境前置：检查并安装 sudo 工具#

不同发行版的精简镜像（Minimal Image）对基础工具链的裁剪程度不同。例如在搬瓦工或 DMIT 上部署的精简版 Debian 系统，默认可能根本没有安装 sudo 工具；而 Ubuntu 默认已集成。

在当前的 root 会话中，首先检测系统是否存在 sudo：

bash
which sudo

如果未返回二进制路径（例如 /usr/bin/sudo），需立即通过系统官方源进行补齐：

Debian / Ubuntu 系：

bash
apt update && apt install -y sudo

Rocky Linux / AlmaLinux / CentOS / Fedora 系：

bash
dnf install -y sudo

安装完成后，可通过查看版本确认组件完整性：

bash
sudo -V | head -n 1

3. 创建管理用户并配置管理组#

在不同发行版中，管理权限依托的用户组名称并不一致：

  • Debian / Ubuntu：默认提权组为 sudo 组。
  • Rocky Linux / AlmaLinux / RHEL：默认提权组为 wheel 组。

以创建一个名为 deploy 的管理运维用户为例（请根据团队规范替换为具有辨识度的用户名）：

3.1 创建用户#

在 Debian 和 Ubuntu 环境下，推荐使用高阶交互工具 adduser，它会自动创建家目录、复制骨架配置（/etc/skel）并交互式要求设定用户密码：

bash
adduser deploy

在 Rocky Linux、AlmaLinux 或最小化 Debian 环境下，如果只有底层的 useradd 指令，需指定参数来补全家目录和登录 Shell：

bash
useradd -m -s /bin/bash deploy
passwd deploy

特别注意 sudo 密码的本质： 当用户执行 sudo <command> 时，系统默认提示输入的不是 root 密码，而是该普通用户自身的登录密码。即使服务器在 DMIT 或搬瓦工上配置了免密 SSH 密钥登录，Linux 本地的 PAM 认证模块依然依赖用户密码进行 sudo 校验。因此，必须通过 passwd 为该账户配置一个高强度的独立密码。

3.2 将用户追加至特权管理组#

将用户纳入系统预设的管理组。操作时务必使用 -aG（Append to Groups）参数；若漏写 -a 仅输入 -G，系统会将该用户从其他所有已有附加组中移除，引发权限事故：

Debian / Ubuntu 系（加入 sudo 组）：

bash
usermod -aG sudo deploy

Rocky Linux / AlmaLinux 系（加入 wheel 组）：

bash
usermod -aG wheel deploy

检查该用户的 UID、GID 及所属组信息：

bash
id deploy

正常输出应类似于：

text
uid=1001(deploy) gid=1001(deploy) groups=1001(deploy),27(sudo)

4. 为新用户部署 SSH 密钥认证#

生产环境中不应使用密码直接暴露在 SSH 端口上。由于 DMIT 等环境普遍采用公钥认证，需要将本地计算机的 SSH 公钥配置到新用户的家目录中。

4.1 规范初始化 .ssh 目录体系#

SSH 服务端对相关文件和目录的权限审查极为严苛。若权限放得过宽，sshd 的 StrictModes 机制会自动拒绝连接。

在已登录的 root 终端中，安全地为新用户创建密钥目录与凭证存储文件：

bash
mkdir -p /home/deploy/.ssh
touch /home/deploy/.ssh/authorized_keys

将你在本地开发机上生成的公钥（通常为 ~/.ssh/id_ed25519.pub 或 ~/.ssh/id_rsa.pub 的单行文本）写入该文件。可以通过文本编辑器打开写入：

bash
nano /home/deploy/.ssh/authorized_keys

4.2 修正属主与文件权限模式#

因为该文件是由 root 代为建立的，其初始拥有者为 root:root，普通用户无权读取或追加，会导致该用户登录时直接被服务端拒绝。必须立即修正所有权和最小权限位：

bash
# 变更属主归还给新用户
chown -R deploy:deploy /home/deploy/.ssh

# 目录必须且只能由所有者读写执行（700）
chmod 700 /home/deploy/.ssh

# 密钥文件必须且只能由所有者读写（600）
chmod 600 /home/deploy/.ssh/authorized_keys

4.3 验证双向登录与特权提升#

在本地电脑上打开一个全新的终端（切记保持原本的 root 连接不关），通过新创建的用户发起连接：

bash
ssh -p 22 deploy@你的服务器IP

连接建立后，分步运行以下验证指令：

bash
# 验证当前身份
whoami
# 输出应为：deploy

# 验证管理凭据缓存与提权状态（此时需输入 deploy 自身的密码）
sudo -v

# 验证能否成功获取 root 权限
sudo whoami
# 输出必须严格为：root

如果 sudo whoami 输出了 root，说明该管理用户的创建与系统组授权已全线打通。

5. 深度掌握 sudo 规则与 visudo 定制#

管理组赋予的权限是全量系统管理（等同于 root）。但在复杂架构中，我们常常需要配置细粒度授权（如允许 CI/CD 账户免密重启 Nginx、允许开发人员读取系统日志等）。

所有的 sudo 规则都收敛在 /etc/sudoers 及 /etc/sudoers.d/ 目录中。

5.1 绝对不要用常用文本编辑器直接改写 sudoers#

/etc/sudoers 文件具有特殊的语法结构。一旦有人使用 vim、nano 等工具直接编辑并不小心多敲了一个错别字或分号，保存退出后整个系统的 sudo 机制将当场瘫痪，导致所有非 root 用户都无法再次提权。

修改规则必须使用专用的检查工具：

bash
sudo visudo

visudo 在保存时会对修改后的内容执行原子级语法解析。如果存在语法错误，它会锁定退出流程并明确指出出错行号，允许运维人员修正；只有语法完全合法时才会真正刷入磁盘。

如果不进入交互模式，仅仅想在部署脚本后校验当前规则的语法完整性，可运行：

bash
sudo visudo -c

5.2 推荐的模块化配置：/etc/sudoers.d/#

不要将所有自定义规则堆砌在主文件 /etc/sudoers 内。最佳实践是在 /etc/sudoers.d/ 目录下为特定业务或账户创建独立文件。

规范要求：

  1. 目录内的文件权限必须是 0440（r--r-----）。
  2. 文件名不能以 . 开头，也不能包含 ~ 或 .，否则 sudo 会直接忽略该配置文件（这是系统预设的忽略规则）。

例如，为自动化部署账户配置免密重启特定服务的规则：

bash
sudo visudo -f /etc/sudoers.d/90-deploy-services

在打开的编辑器中，语法遵循通用范式：

text
# 语法构成：
# 谁（用户或组） 主机=(运行身份:运行组) [选项] 允许执行的程序路径

# 示例 1：允许 deploy 用户免密管理网络与系统服务（适合特定编排运维）
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx

# 示例 2：全量免密提权（常用于自动化流水线，但对个人账户应极其审慎）
# deploy ALL=(ALL) NOPASSWD: ALL

5.3 检查有效权限#

在任意用户下，无需猜测自己能干什么，执行：

bash
sudo -l

系统会逐条列出当前用户所匹配到的环境限制（Matching Defaults entries）以及被明确授权运行的具体命令列表。

5.4 警惕伪安全提权陷阱#

很多运维为了方便，会在 sudoers 中开放看起来很无害的命令，但如果缺乏安全防范，可能会导致普通用户直接绕过限制取得全权 root：

  1. 编辑器陷阱：赋予用户 sudo /usr/bin/vim /etc/nginx/nginx.conf 权限，用户只需在 vim 中输入 :!/bin/bash 或 :sh，就能直接弹出一个无需密码的 root Shell。需要赋予编辑权限时，应使用 sudoedit。
  2. 通配符与目录写权限陷阱：如果授权 sudo /opt/scripts/*.sh，而 /opt/scripts 目录或其中的脚本所属者是 deploy 自己，那么该用户可以修改脚本内容加入任意恶意指令，然后通过 sudo 执行，实际上完全等同于拥有无限制的 root 权限。
  3. 高危二进制提权：类似 find、awk、less 等原生具备 Shell 调用扩展能力的系统工具，绝不能随意加入免密提权列表。

6. 收敛攻击面：安全禁用 root 远程 SSH#

当新的管理用户确认能够稳定执行 ssh 和 sudo 后，必须在 SSH 守护进程中彻底关闭公网针对 root 的访问。

6.1 修改 SSH 服务端配置#

编辑主配置文件（或 /etc/ssh/sshd_config.d/ 下的子配置）：

bash
sudo nano /etc/ssh/sshd_config

定位并确保以下关键指令生效（取消前面的 # 注释）：

text
# 彻底禁止 root 用户通过 SSH 协议登录
PermitRootLogin no

# 强制仅允许密钥登录，全面关闭密码认证（视团队情况，建议开启以消除暴力破解）
PasswordAuthentication no

6.2 语法校验与平滑重载#

在重启服务前，先对 SSH 服务配置进行语法检测：

bash
sudo sshd -t

如果未输出任何报错信息，代表配置安全。此时平滑重载 SSH 进程：

bash
sudo systemctl reload sshd

注意：systemctl reload 只会应用新配置，绝不会中断当前已经连入的活跃 SSH 会话。

6.3 救援预案与失联排障#

如果由于失误配置（如将公钥贴错、权限设反或误禁了所有鉴权），导致新开启的终端被拒之门外，千万不要慌张。利用前文提到的两家服务商的底层机制进行恢复：

  • 搬瓦工用户：进入 KiwiVM 控制面板，在左侧导航选择「Interactive Console」或「Root shell - basic」。该终端是直接挂接在虚拟化层上的带外控制台，不受 SSH 服务状态影响。使用系统初始的 root 密码即可进入黑屏终端，修改 /etc/ssh/sshd_config 将 PermitRootLogin 临时改回 yes 并重启 sshd。
  • DMIT 用户：进入客户中心实例列表，找到出现故障的 VM 并点击「Console」进入 Web 救援页面，输入 root 凭据进入底层系统；如果由于关闭了密码导致无法输入，可先通过 DMIT 面板的「Access」选项重置凭据，按要求由面板重启后在控制台登录修复。

7. 账户生命周期的回收与注销#

运维人员变动或项目交接完成后，回收权限必须做到彻底与可控。需要明确：撤销 sudo 权限、踢出活跃会话与物理删除账户是三个完全独立的阶段。

7.1 撤销用户的管理权限（降权）#

仅需将用户从特权组中移除，其普通用户功能和数据完全不受影响：

Debian / Ubuntu 系：

bash
sudo deluser deploy sudo

Rocky Linux / AlmaLinux 系：

bash
sudo gpasswd -d deploy wheel

如果该用户在 /etc/sudoers.d/ 中有专属的独立配置文件，记得同步删除：

bash
sudo rm -f /etc/sudoers.d/90-deploy-*

7.2 吊销 SSH 登录凭证并封锁账户#

若该员工离职或设备遗失，第一步应使其无法继续通过网络鉴权，同时立即阻断已建立的连接：

bash
# 清空用户的授权公钥
sudo truncate -s 0 /home/deploy/.ssh/authorized_keys

# 锁定用户密码（阻止一切密码验证形式）
sudo usermod -L deploy

# 强制杀死属于该用户的所有存活进程与 SSH 建立的会话连接
sudo pkill -u deploy

7.3 审慎彻底删除账户#

在确认该用户下不再托管任何正在运行的 systemd 守护进程、Nginx 静态资源或关键数据库备份后，再执行最终删除：

bash
# 检查该用户是否有名下的定时任务
sudo crontab -u deploy -l

# 删除账户，并连带清理其家目录（-r / --remove-home）
sudo userdel -r deploy

警示：如果该账户的家目录存放了网站运行目录或代码仓库，切勿使用 -r 参数；应先将重要业务文件的归属权通过 chown -R 交接转移给新的运行用户（如 www-data 或其他管理员），确认无误后再清理废弃的账户元数据。