在 Ubuntu 上新建用户并赋予管理权限看起来是个两三分钟就能搞定的小事但我在工作中见过太多因此翻车的案例有人直接把 /etc/sudoers 改坏导致整台机器上没人能用 sudo有人用 useradd 建完用户后忘记创建家目录程序启动时疯狂报错还有人图省事把所有账号都塞进 sudo 组结果一条误操作把数据库目录清空。这篇文章就不绕弯子直接把 Ubuntu 22.04 上从 adduser 新建用户到用 usermod 和 visudo 赋予管理权限再到验证和排错的完整链路讲清楚。不管你刚接触 Linux 还是在生产环境做运维按这套流程走既能开箱即用又能避开常见的坑。1. 整体思路拆解为什么建独立用户而不是直接操作 root1.1 直接使用 root 的隐患很多教程尤其是老版的 Linux 入门资料上来就让你用 root 登录然后在 root 家目录下做一切事情。这种习惯在一次性虚拟机里没什么问题但放到长期使用的服务器上风险非常大。root 是系统里权限最高的账号它不需要任何审批机制rm -rf 这类命令敲下去就直接执行了系统不会拦你也不会提醒你。之前在帮客户做等保检查时遇到过一台机器某位同事在 root 环境下清理日志路径写错一个字符直接删掉了 /var 下的数据库目录。如果当时用的是普通用户加 sudo至少还有一次密码确认的机会能让人停下来想一想。另外多人协作时如果大家都拿 root 上手服务器上就没有身份区分了。出了问题排查日志只能看到 root看不到具体是谁在何时执行了哪条命令。而独立用户的方案就清晰很多每个人有自己的账号操作时通过 sudo 提权系统的 auth.log 和 journald 会在第一时间记录下命令来源。所以在 Ubuntu 22.04 上正规做法永远是先建普通用户再按需给管理权限。这也是这篇文章的出发点。1.2 adduser 与 useradd 怎么选Ubuntu 系统里有两个建用户的命令adduser 和 useradd。第一次接触的人经常混因为它们在命令行只差一个字母行为却天差地别。useradd 是系统原生的低级工具它很机械你给它什么参数它就做什么不会主动创建家目录不会帮你设置密码也不会复制 /etc/skel 下的默认配置文件。这是因为它面向的是脚本和自动化场景一切行为都要由调用方显式指出。如果新手直接用 useradd 建用户后面往往会发现 home 目录不存在登录后连命令提示符都不正常。adduser 则是对 useradd 的 Perl 封装它把创建用户的全流程串起来了自动建家目录、自动复制 /etc/skel 里的文件、自动设置用户 shell、交互式让你填密码和用户信息。对新手最友好对老手来说也省事。所以我在这篇文章里主推 adduser日常交互操作基本都用它。如果你以后要写部署脚本那再去研究 useradd 也不迟后面会额外补充非交互式的命令写法。1.3 sudo 权限组的工作原理Ubuntu 的默认 sudo 配置里其实预先定义好了两个管理组sudo 组和 admin 组。你打开 /etc/sudoers 就能看到类似下面的规则%sudo ALL(ALL:ALL) ALL %admin ALL(ALL:ALL) ALL第一列的 %sudo 表示组名后面几个 ALL 分别代表主机名、可切换成哪个用户、以及可执行什么命令。翻译成人话就是只要某个用户属于 sudo 组它就能在任意主机上以任意用户身份执行任意命令。这也是 Ubuntu 和 RHEL 系发行版的一个重要区别RHEL 系列默认管理组是 wheelUbuntu 则是 sudo 或 admin。如果你之前习惯改 /etc/sudoers 给用户添加 wheel 组迁移到 Ubuntu 就很容易踩空。选对组名权限才给得进去。将这些规则理清楚之后下面进入实操环节。2. 动手前确认环境版本、当前账号与 sudo 状态2.1 用两条命令确认 Ubuntu 版本不管是新装的系统还是接手别人留下的旧服务器第一步永远先看版本。很多旧资料沿用 18.04 或 20.04 的包名和配置路径搬到 22.04 上不一定兼容。看版本很简单lsb_release -a cat /etc/os-release如果系统里没有 lsb_release 命令那就看 /etc/os-releaseUbuntu 22.04 的内容会明确写着 VERSION_ID22.04版本名称是 jammy。确认好版本后面的源配置和软件安装才有基础。2.2 确认当前用户是谁、有没有 sudo 权限接下来要确认自己现在的身份以及是否具备提权条件。用以下三条命令whoami id sudo -lwhoami 看当前用户名id 看 uid、gid 和所属组sudo -l 列出当前用户被允许执行的 sudo 命令。假如你本来就是 root可以在创建用户时省略 sudo 前缀假如当前用户在 sudo 组里那就直接走正常流程如果 sudo -l 报错说当前用户不在 sudoers 文件中说明这个账号本身没有管理权限你得先想办法用别的管理员把它加进去否则后面什么也做不了。2.3 顺手检查软件源和系统时间创建用户本身不依赖网络也不依赖软件源但创建完成后往往想马上装个软件验证权限所以建议顺便确认两点。第一是软件源状态执行一次sudo apt update能正常拉取索引就没有问题。第二是系统时间date 命令看一眼。时间偏差会导致 sudo 相关认证异常这类故障排查起来非常隐蔽日志里也不会直接提示时区问题。如果你后面遇到 sudo 反复询问密码、明明输对了却说密码错误可以先怀疑时间同步。3. 新建用户完整流程adduser 命令一步步详解3.1 交互式创建用户现在开始建用户。以创建一个名为 deploy 的账号为例命令是sudo adduser deploy当前是 root 的话可以去掉 sudo。执行后 adduser 会自动配置 shell 为 /bin/bash创建 /home/deploy 家目录并把 /etc/skel 下的默认隐藏文件复制进去。然后它会进入交互界面先让你设置密码再让你填一堆可选信息。3.2 交互过程中每个字段的含义整个交互过程大致是这样的输入新用户的密码确认密码。要注意终端里输入密码时不会显示任何字符这是正常行为不是键盘坏了。接下来是 Full Name直接回车跳过即可。然后是 Room Number、Work Phone、Home Phone、Other这些默认信息在绝大多数场景都不需要一路回车。最后会问 Is the information correct?输入 Y 确认。确认后adduser 会完成用户创建、家目录初始化等工作。这里有一个关键点adduser 默认建出来的用户只是一个普通用户不属于 sudo 组也不能执行 sudo。所以你输完密码以为大功告成其实管理权限还在下一步。也许有人会问既然最终要管理权限为什么不直接在 adduser 里把组一次性加上adduser 本身没有加 sudo 组的标准参数而且在实际工作中建账号和给权限往往是两个审批步骤。先建普通账号再授权逻辑上更清晰也方便审计。3.3 创建后立即检查家目录和属主建完用户不要急着走先用下面两条命令验证id deploy ls -ld /home/deployid 会显示该用户当前的 uid、gid 和 groups。正常情况下groups 里只有 deploy 自己看不到 sudo。ls -ld 则验证家目录是否归属 deploy。如果显示的属主是 root后续用户会无法正常写入自己的 home出现各种权限报错。遇到这种情况用 chown 修一下sudo chown -R deploy:deploy /home/deploy但更推荐从源头确认adduser 默认不会犯这个错除非你之前手动动了什么配置。3.4 非交互式创建用户的方法写脚本或者批量初始化机器时没法像交互式那样一路回车这时候用 useradd 更合适。例如sudo useradd -m -s /bin/bash -G sudo -p $(openssl passwd -6 YourPass123) ops这里 -m 表示创建家目录-s 指定 shell-G sudo 表示直接把用户加入 sudo 组-p 接收的是加密后的密码不是明文所以要先用 openssl passwd 或 mkpasswd 生成哈希。如果你不想在命令行里写哈希也可以先用 useradd 建普通用户再用 passwd 交互式设密码最后用 usermod -aG sudo 加入管理组效果完全一样。4. 赋予管理权限的三种操作方案4.1 方案一用 usermod -aG sudo 加入管理组把用户加入 sudo 组最常见也最不容易出错sudo usermod -aG sudo deploy这个命令里有几个细节非常重要。第一-a 表示 append也就是追加不是覆盖。如果漏写 -a命令会变成 -G sudo这时候系统会把用户从所有其他附加组中移除只保留 sudo 这一个组导致用户原本所在的 docker、developers 等组权限全部丢失。第二-G 后面指定的是附加组这里写 sudo。加组后不需要重启机器但当前会话不会立刻刷新。新用户需要注销重新登录或者执行 newgrp sudo 临时刷新一次组信息然后才能让 sudo 生效。4.2 方案二用 visudo 在 sudoers 主文件里加规则另一种方式是直接编辑 /etc/sudoers给指定用户单独写一条授权规则。但这里我必须强调永远别用 vim 直接打开 /etc/sudoers 改一定用 visudo。原因在于visudo 保存时会检查语法如果语法错误它会阻止保存并提示修复选项。而 vim 直接编辑的话哪怕只打错一个符号也有可能让整个系统里所有用户都无法执行 sudo到时候你连恢复错误的机会都没有只能进单用户模式或救援盘。在 visudo 打开的界面里找到类似的一行root ALL(ALL:ALL) ALL在其下方插入deploy ALL(ALL:ALL) ALL保存退出。这种方案的价值在于它为特定用户写了一条显式规则运维审计时能直观看到谁有权限。如果你只想给单个用户开完整管理权限不打算让整个组都拥有这个方案比加组更精确。4.3 方案三在 /etc/sudoers.d/ 下创建独立规则文件如果你的机器上会有多个用户和多种权限需求我强烈推荐第三种方式在 /etc/sudoers.d 目录下为每个用户或每个业务建一个独立文件。Ubuntu 默认在 /etc/sudoers 文件末尾 include 了这个目录所以你不用改主文件只要把新文件放进去即可。编辑时同样建议用 visudo 的专用参数sudo visudo -f /etc/sudoers.d/deploy然后写入deploy ALL(ALL:ALL) ALL保存退出后权限立即生效。这个方案最大的优点是模块化多个用户的规则互不干扰哪怕其中某个文件写坏了影响的也只是一个独立文件不至于牵连整个 sudo 配置。清理时也更方便删除对应文件就撤销了相关授权。4.4 三种方案怎么选我一般按场景这样区分方案复杂度适用场景优点注意点usermod -aG sudo低单用户授权、个人开发机命令简单符合 Ubuntu 社区习惯授权粒度较粗组内成员可执行任意命令visudo 主文件规则中单个用户精确授权规则直观审计方便主文件内容多了之后有合并风险/etc/sudoers.d 独立文件中多用户、批量运维场景模块化、易清理需要记得目录存在别漏看 include就个人日常使用而言我 90% 的场景都用 usermod -aG sudo因为它符合 Ubuntu 的用户习惯而且 id 命令一看就知道权限范围。到了生产环境要做命令级白名单时再去建 /etc/sudoers.d 文件。5. 验证权限与高频故障排查5.1 从新用户视角验证 sudo 是否生效授权完成后别急着安心先切换过去实测一次su - deploy sudo whoami这里有个小坑如果你使用 su deploy 而不是 su - deploy环境变量可能残留上一个用户的状态sudo 有时会报一些诡异的问题。su - 会完整加载目标用户的环境所以习惯上要带横杠。sudo whoami 如果输出 root说明管理权限已经生效。然后再执行 sudo -l它会详细列出当前用户在所有主机上被允许执行的命令。看到形如 (ALL : ALL) ALL 的内容就说明授权没有遗漏。5.2 高频故障速查表我把这些年常遇到的情况整理成一个表覆盖了大部分求助帖里的问题。现象原因解决办法user is not in the sudoers file用户不在 sudo 组也没有显式规则用有权限的账号执行 usermod -aG sudo 用户名不在 sudoers 文件中此事将被报告授权未生效或者组被误删让用户重新登录检查 /etc/sudoers 语法sudo: unable to resolve host/etc/hosts 里的主机名和系统 hostname 不匹配修改 /etc/hosts添加本机主机名解析Sorry, user xxx is not allowed to executesudoers 规则中的主机别名或命令范围写错用 visudo 检查规则修正 ALIAS 定义新用户 sudo 一直提示密码密码绝对没错系统时间偏差或 PAM 配置异常同步时间检查 /etc/pam.d/sudo登录后命令行提示符异常没有家目录useradd 没加 -m 参数手动创建家目录并 chown 给用户用户已在 sudo 组但 sudo 仍失败当前会话组信息没刷新用 newgrp sudo 或重新登录5.3 排查权限问题的正确顺序排查权限问题时我习惯按这个顺序来能省不少时间。先看 id确认用户当前属于哪些组。再看 /etc/sudoers 和 /etc/sudoers.d 下有没有相关规则。最后翻日志。Ubuntu 22.04 上sudo 的每次成功和失败都会记录到认证模块中查看命令是journalctl -u sudo grep sudo /var/log/auth.log如果用户被拒绝auth.log 里会直接写明 user not in sudoers 或者 command not allowed。相比对着配置文件猜日志给出的信息要准确得多。我调试过一次环境变量导致的诡异问题最后就是靠 auth.log 发现了一个重复的 PAM 配置这种情况只看 sudoers 永远找不到答案。6. 权限管理的安全加固与使用心得6.1 sudo 免密配置怎么做以及风险在哪有些自动化脚本不希望每次执行 sudo 都要求输入密码可以在规则里加 NOPASSWDdeploy ALL(ALL) NOPASSWD: ALL这样配置后deploy 用户执行 sudo 时不再提示密码。但也要清醒地认识到风险如果这个账号被爆破或者泄露攻击者可以直接在整台机器上执行任意命令连二次确认都没有。所以我建议只在受控的 CI 环境、或一次性测试机中使用免密并且最好配合下面讲到的命令白名单一起限制。6.2 限制 sudo 命令范围把权限缩小到业务所需如果想给用户一个能管理 nginx 服务但不具备完全 root 能力的账号可以这样写规则deploy ALL(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx要注意sudoers 里的命令路径必须写绝对路径可以用 which systemctl 查清楚。这个粒度在生产环境非常实用既满足日常操作又不至于让账号拥有无边界的 root 能力。如果你是从 CentOS 迁移过来记得先确认命令路径因为两边工具链位置可能不一样配置好后再用 sudo -l 验证。6.3 定期梳理有管理权限的账号机器用久了总会堆积一些临时账号、离职员工的账号或者测试用的虚拟账号。我的习惯是定期列出所有具备 sudo 能力的账号grep -E sudo|admin /etc/group | awk -F: {print $4}再结合 /etc/sudoers 和 /etc/sudoers.d 里的规则逐条确认。长期不用的账号及时删除删除命令是sudo deluser --remove-home username它会移除用户并清理家目录。执行前要先确认这个用户没有正在运行的进程否则会有文件占用清理不干净残留一堆僵尸家目录。6.4 一条长期有效的黄金法则关于 sudo 配置我有几条十几年没变过的原则每次接手新机器都会对照执行。sudoers 文件永远用 visudo 改不用 vim 直接改。授权永远从最小权限开始缺什么再补什么而不是一开始就 ALL。多用户环境尽量使用 /etc/sudoers.d 拆分规则少动主文件。不轻易给普通用户添加 NOPASSWD除非你完全清楚后果。每次改完权限立刻新开一个终端验证不要拖到下次登录才发现问题。这些原则看起来很小但就是它们决定了运维事故是多还是少。跑过几年生产环境的人应该都会同意权限管理最怕的不是配置复杂而是无规则地瞎给。新建用户、给 sudo只是整套权限体系的起点真正值钱的是你愿不愿意花时间去看 auth.log、梳理 sudoers 规则、评估每个账号的最小权限。希望这篇基于 Ubuntu 22.04 的完整流程能帮你少踩我踩过的那些坑把账号权限管理做得既安全又顺手。