Ubuntu 18.04 创建带sudo权限的普通用户完整指南

1. 项目概述：在 Ubuntu 18.04 上安全创建具备 sudo 权限的普通用户

你刚装好一台 Ubuntu 18.04 服务器或开发机，系统默认只给了 root 用户（或者安装时设置的那个初始用户）sudo 权限。现在你要给团队新成员、测试环境里的隔离账户，或者只是想给自己建一个“不带 root 默认权限”的日常操作账号——但又必须能执行管理命令，比如apt update、systemctl restart nginx、ufw allow 80这类操作。这时候，直接用root登录是高危行为，而手动改/etc/sudoers文件又容易因语法错误导致整个系统无法提权。最稳妥、最符合 Linux 管理规范的做法，就是创建一个新用户，并将其加入sudo用户组。这个操作本身不复杂，但背后涉及用户身份模型、权限继承机制、PAM 认证链和 setuid 位的安全设计逻辑。Ubuntu 18.04 的关键特征在于：它默认启用sudo组的免密码提权策略（通过/etc/sudoers.d/10-installer配置），且sudo命令本身由 root 拥有并设置了 setuid 位（即ls -l /usr/bin/sudo显示-rwsr-xr-x），这意味着任何被授权的用户调用sudo时，实际是以 root 身份运行后续命令。这正是为什么我们不推荐用usermod -aG sudo $USER给自己加权限后立刻生效——因为 shell 会话不会自动重载组信息，必须重新登录或newgrp sudo才能识别新组。我试过不下二十次线上环境部署，凡是跳过“验证组成员身份”这一步就直接跑sudo apt install的，十有八九卡在Sorry, user xxx is not allowed to execute ...的报错上。所以这篇不是教你怎么敲几行命令，而是带你把整个权限链条从内核 UID/GID 到 PAM 模块再到 sudoers 规则全部串起来，确保你建的每个用户都真正“活”在 sudo 生态里，而不是表面看起来能用、一到关键步骤就掉链子。

1.1 核心需求解析：为什么不能只用 adduser + passwd？

很多新手看到标题第一反应是：“不就是adduser alice然后passwd alice吗？”——这确实完成了“创建用户”，但离“可用的 sudo 用户”还差三步关键验证。
第一，adduser创建的是标准用户，默认属于同名私有组（alice:alice），但Ubuntu 18.04 的 sudo 权限不是靠用户名匹配，而是靠组成员身份判断。它的 sudoers 配置里写的是%sudo ALL=(ALL:ALL) ALL，意思是“所有属于sudo组的用户，可以在任意主机、以任意用户/组身份执行任意命令”。如果你没把alice加进sudo组，她连sudo ls /root都会被拒绝。
第二，即使你补上usermod -aG sudo alice，这个操作只是修改了/etc/group文件，而当前已存在的 shell 会话（包括你刚开的终端）不会自动感知组变更。Linux 内核在用户登录时读取一次/etc/passwd和/etc/group并缓存 GID 列表，之后整个会话生命周期内都沿用这份快照。所以你必须让alice完全退出再登录，或者用su - alice切换会话强制重载。
第三，也是最容易被忽略的：密码策略与 shell 类型。Ubuntu 18.04 默认使用adduser而非useradd，前者会自动配置合理的家目录权限（755）、复制/etc/skel模板、设置/bin/bash为默认 shell；而后者创建的用户默认 shell 是/bin/sh，且家目录权限可能为700，导致某些 GUI 工具或 SSH 密钥认证失败。我曾经在 Jetson Nano 上遇到过sudosetuid 位丢失的问题（chmod u+s /usr/bin/sudo被误删），结果所有用户提权都失效，连apt update都报command not found——这说明，sudo 不是魔法，它依赖底层文件权限、PAM 模块加载、以及用户组关系三者严丝合缝。所以本指南每一步都附带验证命令，不是让你“相信它工作了”，而是让你亲眼看到 UID、GID、组列表、sudoers 规则四者同步生效。

1.2 技术影响范围：这个操作牵动哪些系统模块？

创建一个带 sudo 权限的用户，表面看只是几条命令，实则横跨 Linux 权限模型的五个核心层：

• 内核层：用户 ID（UID）和组 ID（GID）的分配与校验。adduser会从/etc/login.defs中读取UID_MIN（1000）和GID_MIN（1000）参数，确保新用户不与系统账户冲突。
• 文件系统层：/etc/passwd（存储 UID/GID/shell/家目录）、/etc/group（记录用户所属组）、/etc/shadow（加密密码哈希）三文件联动更新。usermod -aG sudo alice实质是向/etc/group中sudo:x:27:alice这一行追加用户名。
• PAM 层：/etc/pam.d/sudo定义了 sudo 调用时的认证流程，其中pam_group.so模块负责检查用户是否属于sudo组。如果该模块被注释或配置错误，即使组关系正确，sudo 也会拒绝。
• sudoers 层：/etc/sudoers及其包含的/etc/sudoers.d/下文件，定义权限策略。Ubuntu 18.04 的关键规则是@includedir /etc/sudoers.d和sudo ALL=(ALL:ALL) ALL，前者允许模块化管理权限，后者是权限主体。
• Shell 层：用户登录后启动的 shell（如 bash）会读取/etc/group并缓存组列表，id -nG命令显示的就是这个缓存值，而非实时查询磁盘文件。

这五层中任意一层断裂，都会导致“用户存在但 sudo 失效”。比如网络热词里提到的qstandardpaths: xdg_runtime_dir not set，本质是用户会话未正确初始化 D-Bus 环境变量，常发生在用su alice切换而非login登录时；而sudo: 'apt-key': command not found则是因为 Ubuntu 20.04+ 已弃用apt-key，但用户误以为是 sudo 权限问题——其实apt-key本就不该在普通用户环境下调用，它需要 root 权限且已被官方标记为 deprecated。所以本指南所有验证步骤都直击这五层，确保你建的用户不是“纸面合法”，而是“全栈可用”。

2. 核心细节解析与实操要点：为什么选 adduser 而非 useradd？组权限如何精准控制？

2.1 工具选型逻辑：adduser 是交互式封装，useradd 是底层裸命令

Ubuntu 官方文档明确推荐adduser而非useradd来创建普通用户，这不是风格偏好，而是功能代差。useradd是 SysV 时代的古老命令，设计初衷是快速创建系统账户（如www-data、mysql），它默认不创建家目录、不复制骨架文件、不设置密码、不指定 shell，所有参数都需手动指定。例如，用useradd alice创建的用户：

• 家目录/home/alice根本不存在；
• /etc/passwd中 shell 字段为空或为/bin/sh；
• /etc/shadow中密码字段为!（锁定状态）；
• 用户组只有alice（私有组），不自动加入sudo或其他功能性组。

而adduser是 Perl 脚本封装，它会：

1. 交互式询问全名、房间号、电话等（可全留空）；
2. 自动创建/home/alice并设权限755（owner rwx, group rx, other rx）；
3. 复制/etc/skel/下所有文件（.bashrc,.profile,.vimrc等）到家目录；
4. 设置默认 shell 为/bin/bash；
5. 调用passwd命令强制设置密码；
6. 允许通过--gecos参数跳过交互，实现脚本化（如adduser --gecos "" --disabled-password alice）。

提示：生产环境自动化部署时，adduser --gecos "" --disabled-password alice比useradd -m -s /bin/bash alice更可靠，因为前者确保家目录权限和骨架文件完整，后者可能因/etc/adduser.conf配置差异导致家目录权限为700（拒绝组和其他用户访问），进而影响systemd --user服务或 SSH agent forwarding。

2.2 组权限的本质：sudo 组 vs admin 组的历史变迁

Ubuntu 18.04 使用sudo组而非旧版的admin组，这是 Debian/Ubuntu 社区在 2011 年左右推动的重大安全改进。admin组的权限规则是%admin ALL=(ALL) ALL，意味着用户可以以任意身份执行任意命令，但不强制要求输入密码（除非显式配置NOPASSWD）。而sudo组的规则%sudo ALL=(ALL:ALL) ALL在 Ubuntu 18.04 中默认启用了Defaults env_reset和Defaults mail_badpass，更重要的是，它通过/etc/sudoers.d/10-installer文件设置了Defaults !lecture（禁用首次使用提示）和Defaults env_keep += "LANG LC_*"（保留语言环境变量），但没有默认开启 NOPASSWD。这意味着新用户加入sudo组后，每次执行sudo仍需输入自己的密码（不是 root 密码！），这是纵深防御的关键：即使用户密码泄露，攻击者仍需二次认证才能提权。

注意：网上流传的“usermod -aG sudo alice && echo '%alice ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers”是危险操作。直接 echo 追加会破坏/etc/sudoers语法（缺少visudo的语法检查），且NOPASSWD开放过大，违背最小权限原则。正确做法是用visudo -f /etc/sudoers.d/alice-nopasswd创建独立文件，内容为alice ALL=(ALL) NOPASSWD: /usr/bin/apt, /usr/bin/systemctl，精确限定可免密命令。

2.3 密码策略与安全加固：为什么不能跳过 passwd 步骤？

adduser创建用户时强制要求设置密码，这不是形式主义。Ubuntu 18.04 的 PAM 配置（/etc/pam.d/common-password）默认启用pam_pwquality.so，它会校验密码强度：至少 8 位、包含大小写字母、数字、符号。如果你用useradd -p直接传入加密密码（如useradd -p $(openssl passwd -1 "weak") alice），会绕过 PAM 校验，导致弱密码入库。更严重的是，-p参数接受的是已加密的字符串，而openssl passwd -1生成的是 MD5 hash，Ubuntu 18.04 默认使用 SHA-512（$6$前缀），MD5 hash 会被当作明文密码存储，造成安全隐患。

实操心得：我在线上环境曾用adduser --disabled-password alice创建无密码用户，本意是后续用 SSH 密钥登录，结果发现sudo提权时仍提示Sorry, try again。排查发现，/etc/shadow中alice行密码字段为*（表示无密码且账户锁定），而sudo的 PAM 链要求用户密码必须可验证（即使不实际输入），*状态被判定为“密码不可用”。解决方案是sudo passwd -d alice清空密码（字段变为空），或sudo passwd alice设置一个强密码再禁用（sudo passwd -l alice）。

3. 实操过程与核心环节实现：从创建到验证的完整闭环

3.1 第一步：创建用户并设置密码（交互式）

打开终端，确保你当前是管理员用户（如安装时创建的ubuntu用户），执行：

sudo adduser alice

系统会依次提示：

• Enter new UNIX password:输入密码（不显示，输完回车）；
• Retype new UNIX password:再次输入确认；
• Full Name []:可留空；
• Room Number []:留空；
• Work Phone []:留空；
• Home Phone []:留空；
• Other []:留空；
• Is the information correct? [Y/n]输入Y确认。

此时adduser已完成：

• 创建/home/alice目录，权限755；
• 将/etc/skel/下文件复制进去；
• 在/etc/passwd添加alice:x:1001:1001::/home/alice:/bin/bash:/usr/sbin/nologin（注意最后字段是/usr/sbin/nologin？不对，adduser默认设为/bin/bash）；
• 在/etc/shadow添加alice:$6$...:18901:0:99999:7:::（SHA-512 hash）；
• 在/etc/group添加alice:x:1001:（创建私有组）。

验证命令：sudo cat /etc/passwd | grep alice应输出alice:x:1001:1001::/home/alice:/bin/bash:/usr/sbin/nologin？等等，这里有个陷阱：adduser默认 shell 是/bin/bash，但某些云镜像可能预配置为/usr/sbin/nologin。务必用getent passwd alice查看真实值，cat /etc/passwd可能被getent缓存覆盖。正确命令是getent passwd alice，输出应含/bin/bash。

3.2 第二步：将用户加入 sudo 组（关键权限赋予）

执行以下命令将alice加入sudo组：

sudo usermod -aG sudo alice

-aG参数至关重要：-a表示 append（追加），-G指定附加组列表。如果不加-a，usermod -G sudo alice会清空用户所有现有组，只保留sudo组，导致alice丢失alice私有组权限，家目录访问失败。

验证命令：groups alice应输出alice sudo。但注意！这只是/etc/group文件的静态快照，不代表当前会话已生效。如果你在 root 用户下执行此命令，groups alice显示正确；但如果你切换到alice用户终端，groups仍只显示alice，因为会话未重载。此时必须exit当前终端，或su - alice新建登录会话。

3.3 第三步：切换到新用户并验证 sudo 权限（必须重载会话）

关闭当前终端，新开一个终端窗口，或直接执行：

su - alice

su -中的-表示模拟完整登录（login shell），它会：

• 重载/etc/passwd和/etc/group，获取最新 GID 列表；
• 读取/home/alice/.bashrc和/home/alice/.profile；
• 设置正确的$HOME、$PATH、$SHELL环境变量。

然后执行：

id -nG

输出应为alice sudo，证明组关系已加载。接着验证 sudo：

sudo whoami

输入alice的密码（不是 root 密码！），应输出root。如果报错user alice is not in the sudoers file，说明usermod未成功，检查/etc/group中sudo行是否含alice：sudo:x:27:root,alice。

实操心得：我在 Jetson Nano 上遇到过sudosetuid 位丢失（ls -l /usr/bin/sudo显示-rwxr-xr-x而非-rwsr-xr-x），导致所有用户提权失败。修复命令是sudo chmod u+s /usr/bin/sudo。但切记，setuid位只能由 root 设置，且必须确保/usr/bin/sudo所有者为 root（sudo chown root:root /usr/bin/sudo）。这个案例说明，sudo 权限不是黑盒，它依赖底层文件权限，运维必须懂这些细节。

3.4 第四步：深度验证与环境初始化（避免常见坑）

仅仅sudo whoami成功还不够，要验证真实场景。在alice用户下执行：

# 测试包管理 sudo apt update && sudo apt list --upgradable | head -5 # 测试服务管理 sudo systemctl is-active ssh # 测试防火墙（如果安装了 ufw） sudo ufw status verbose 2>/dev/null || echo "ufw not installed" # 测试文件系统操作 sudo touch /tmp/test-sudo && sudo rm /tmp/test-sudo

如果sudo apt update报错E: Could not get lock /var/lib/dpkg/lock-frontend，说明有其他 apt 进程在运行（如后台自动更新），需sudo lsof /var/lib/dpkg/lock-frontend查看并终止。

关键验证：sudo运行后提示qstandardpaths: xdg_runtime_dir not set？这是 Qt 应用的环境变量缺失，不影响命令执行，但若要运行 GUI 工具（如sudo gedit），需在alice的~/.bashrc中添加：

export XDG_RUNTIME_DIR="/run/user/$(id -u)"

然后source ~/.bashrc。这是因为sudo默认不继承XDG_RUNTIME_DIR，而 Qt 5.7+ 强制要求该变量。

3.5 第五步：可选加固——限制 sudo 权限范围（最小权限原则）

如果alice只需管理软件包，无需重启服务，可精细化授权。用visudo编辑专属配置：

sudo visudo -f /etc/sudoers.d/alice-apt

输入以下内容（注意语法严格）：

# User rules for alice alice ALL=(ALL) NOPASSWD: /usr/bin/apt, /usr/bin/apt-get, /usr/bin/aptitude

保存退出后，alice执行sudo apt update不再需要输密码，但sudo systemctl restart nginx会拒绝。

注意：visudo -f会自动语法检查，避免直接编辑/etc/sudoers导致系统锁死。文件名必须以.sudoers结尾（如alice-apt.sudoers）才能被/etc/sudoers.d/自动加载，否则无效。

4. 常见问题与排查技巧实录：从报错日志到内核级诊断

4.1 典型报错速查表与根因分析

4.2 深度诊断：当 sudo 看似工作但部分命令失败

现象：sudo whoami输出root，但sudo apt update报错E: Could not get lock /var/lib/dpkg/lock-frontend。
这不是权限问题，而是资源竞争。apt锁文件机制防止并发修改包数据库。解决方法：

1. 查看谁占用了锁：sudo lsof /var/lib/dpkg/lock-frontend；
2. 如果是unattended-upgrades进程，等待其完成或sudo systemctl stop unattended-upgrades；
3. 切勿直接sudo rm /var/lib/dpkg/lock-frontend，这会导致包数据库损坏。

另一个高频问题：sudo docker pull mysql:5.7报错permission denied while trying to connect to the Docker daemon socket。这是因为docker套接字/var/run/docker.sock所属组是docker，而alice未加入该组。解决方案：

sudo groupadd docker 2>/dev/null sudo usermod -aG docker alice sudo systemctl restart docker su - alice # 重载会话 docker ps # 验证

4.3 网络热词专项解析：那些看似相关实则误导的搜索词

• command 'nvidia-smi' not found：这是 NVIDIA 驱动未安装，与 sudo 无关。nvidia-smi是驱动自带工具，sudo apt install nvidia-utils-390是安装驱动配套工具，但前提是已安装对应内核模块。正确流程是先ubuntu-drivers devices查看推荐驱动，再sudo apt install nvidia-driver-390。
• effective user id is not 0：sudo执行命令时，进程的 EUID（Effective UID）必须为 0 才能提权。sudo本身通过 setuid 位实现 EUID=0，如果sudo二进制权限被改（如chmod u-s /usr/bin/sudo），EUID 就是用户 UID，自然失败。用ls -l /usr/bin/sudo检查。
• sudo apt-get install g++ failed：常见于源列表配置错误（如sources.list中 URL 无效）或网络代理未配置。先sudo apt update看是否报Failed to fetch，再检查/etc/apt/sources.list是否含http://archive.ubuntu.com（18.04 已停用，应为http://old-releases.ubuntu.com）。
• sudo: apt-key: command not found：Ubuntu 20.04+ 已弃用apt-key，但 18.04 仍存在。若报此错，说明apt包损坏，重装：sudo apt install --reinstall apt。

4.4 终极验证：用 strace 追踪 sudo 的内核级行为

当你遇到无法解释的 sudo 失败，用strace直接观察系统调用：

strace -e trace=execve,openat,stat,connect sudo whoami 2>&1 | grep -E "(execve|openat|EACCES|EPERM)"

典型输出：

• execve("/usr/bin/sudo", ["sudo", "whoami"], ...)→sudo启动成功；
• openat(AT_FDCWD, "/etc/sudoers", O_RDONLY) = 3→ 成功读取 sudoers；
• openat(AT_FDCWD, "/etc/sudoers.d/10-installer", O_RDONLY) = 4→ 加载配置；
• stat("/home/alice", {st_mode=S_IFDIR|0755, ...})→ 检查家目录；
• 若出现openat(... "/etc/shadow" ...) = -1 EACCES，说明/etc/shadow权限错误（应为640，属组shadow）。

我踩过的坑：某次误操作chmod 600 /etc/shadow，导致所有用户sudo失败，因为sudo需要读取/etc/shadow验证密码。修复命令：sudo chmod 640 /etc/shadow && sudo chown root:shadow /etc/shadow。这个案例说明，sudo 的每一环都依赖系统文件权限，运维必须对整个信任链有掌控力。

5. 进阶实践：批量创建与自动化脚本编写

5.1 批量创建用户的 Bash 脚本（生产环境可用）

以下脚本可创建多个用户并统一加入 sudo 组，支持密码随机生成：

#!/bin/bash # batch-add-users.sh USERS=("alice" "bob" "charlie") PASSWORD_FILE="/tmp/user-passwords.txt" echo "=== 批量创建用户 ===" for user in "${USERS[@]}"; do echo "创建用户: $user" # 生成 12 位随机密码（含大小写字母、数字、符号） PASS=$(openssl rand -base64 12 | tr -d "=+/" | cut -c1-12) # 创建用户，禁用交互式提问 sudo adduser --gecos "" --disabled-password "$user" # 设置密码（避免明文出现在命令行历史） echo "$user:$PASS" | sudo chpasswd # 加入 sudo 组 sudo usermod -aG sudo "$user" # 记录密码 echo "$user: $PASS" >> "$PASSWORD_FILE" done echo "=== 用户创建完成 ===" echo "密码已保存至: $PASSWORD_FILE" echo "请立即分发密码并删除临时文件！"

运行前赋予执行权限：chmod +x batch-add-users.sh，然后./batch-add-users.sh。脚本特点：

• 使用chpasswd而非passwd，避免密码出现在进程参数中；
• 密码生成用openssl rand，比date | md5sum更安全；
• 密码文件路径为/tmp/，建议执行后立即shred -u "$PASSWORD_FILE"安全擦除。

5.2 Ansible Playbook 实现零接触部署（DevOps 标准化）

对于大规模服务器集群，Ansible 是更优解。以下 playbook（create-sudo-users.yml）可一键部署：

--- - name: Create sudo users on Ubuntu 18.04 hosts: all become: yes vars: sudo_users: - name: alice password: "{{ 'alice_pass' | password_hash('sha512') }}" - name: bob password: "{{ 'bob_pass' | password_hash('sha512') }}" tasks: - name: Ensure sudo group exists group: name: sudo state: present - name: Create users with sudo access user: name: "{{ item.name }}" password: "{{ item.password }}" groups: sudo append: yes create_home: yes shell: /bin/bash state: present loop: "{{ sudo_users }}" - name: Verify users exist and are in sudo group command: id -nG "{{ item.name }}" loop: "{{ sudo_users }}" register: user_groups ignore_errors: yes - name: Debug user groups debug: var: user_groups.results

运行命令：ansible-playbook -i inventory.ini create-sudo-users.yml。优势：

• 密码哈希化存储，不暴露明文；
• append: yes确保不覆盖现有组；
• ignore_errors: yes允许部分用户验证失败（如用户已存在）；
• 符合 CI/CD 流水线集成，审计日志完整。

5.3 安全审计：定期检查 sudo 用户权限合规性

创建用户只是开始，持续审计才是关键。以下命令可生成 sudo 权限报告：

# 列出所有 sudo 组成员 echo "=== sudo 组用户 ===" getent group sudo | cut -d: -f4 | tr ',' '\n' | sort # 检查是否有用户被错误授予 NOPASSWD echo -e "\n=== NOPASSWD 用户 ===" grep -r "NOPASSWD" /etc/sudoers* 2>/dev/null | grep -v "^#" | cut -d: -f1,2 # 检查 sudo 二进制权限 echo -e "\n=== sudo 二进制权限 ===" ls -l /usr/bin/sudo # 检查 /etc/shadow 权限 echo -e "\n=== /etc/shadow 权限 ===" ls -l /etc/shadow

将此脚本加入 cron 每周执行：0 2 * * 0 /path/to/audit-sudo.sh > /var/log/sudo-audit.log 2>&1。真正的安全不是“一次配置”，而是“持续验证”。

6. 总结与个人经验沉淀

我在 Ubuntu 18.04 上创建过上千个 sudo 用户，从单台开发机到 500+ 节点的 HPC 集群，每一次都坚持三个铁律：第一，永远用adduser而非useradd，因为它封装了所有安全默认值；第二，usermod -aG sudo后必须su -重载会话，这是 90% 的“sudo 不生效”问题的根源；第三，绝不直接编辑/etc/sudoers，所有定制化权限都走/etc/sudoers.d/的独立文件，用visudo -f保证语法安全。这些不是教条，而是血泪教训换来的肌肉记忆。比如有一次，我用useradd -m -s /bin/bash alice创建用户，结果alice的家目录权限是700，导致systemd --user服务无法启动，因为~/.config/systemd/user/需要组可读。又比如，在容器化环境中，sudo的 setuid 位常因镜像构建被意外清除，ls -l /usr/bin/sudo必须成为上线检查清单的第一项。技术没有银弹，但扎实的基本功能让问题在发生前就被扼杀。你现在掌握的不是几条命令，而是一套 Linux 权限治理的思维框架：从 UID/GID 分配，到组策略继承，再到 PAM 认证链，最后到 sudoers 规则引擎。这套框架，足以应对未来十年内任何 Linux 发行版的权限管理挑战。