最近在给一台 Ubuntu 22.04 的新机器做初始化装完系统后的第一件事就是新建用户并赋予管理权限。这件事在很多人看来属于基础操作但我帮同事和客户搭环境时发现不少人对于 adduser、usermod、sudo 组这一套的理解停留在“复制粘贴命令能用就行”的程度甚至有人直接用 useradd 建完用户忘了设密码结果账号根本登不进去还有人在赋予管理权限时不小心把用户原有的附加组全踢掉了。这篇就把 Ubuntu 22.04 下新建用户、赋予管理权限这件事从原理到实操完整走一遍适合刚接手 Linux 服务器的新手也适合想把自己账号管理流程规范化的老手。1. 动手前先弄明白adduser 和 useradd 到底用哪个1.1 两条命令的区别不是名字长短很多教程里都出现过这两个命令但它们根本不是同一种东西。useradd 是 Linux 系统自带的底层工具几乎所有发行版都有它做的事情非常“朴素”在 /etc/passwd、/etc/shadow、/etc/group 里各加一行记录仅此而已。它不会帮你建家目录不会帮你设置密码也不会从 /etc/skel 目录复制任何配置模板过来。如果你只执行一句 useradd zhangsan得到的只是一个存在但完全不可用的账号没有 /home/zhangsan没有密码shell 可能也不是你想要的 /bin/bash。adduser 则是 Ubuntu/Debian 系基于 useradd 封装的一个 Perl 脚本它的定位是“交互式向导”。你执行 sudo adduser zhangsan它会一步步提醒你设置密码、填写用户信息自动帮你创建同名组、创建家目录、从 /etc/skel 复制默认配置文件一条龙搞定。这也是为什么 Ubuntu 官方文档里推荐的是 adduser 而不是 useradd。我见过最典型的问题场景是有人照着 CentOS 的习惯在 Ubuntu 上用 useradd 建用户然后又手动 mkdir、cp、chown、passwd 补一大堆操作费时费力还容易漏。在 Ubuntu 22.04 上非特殊场景直接用 adduser 就好。1.2 Ubuntu 为什么主推 adduseradduser 的优势核心是三点自动从 /etc/skel 复制配置模板。/etc/skel 目录里存放着 .bashrc、.profile、.bash_logout 等文件adduser 会把它们复制到新用户的家目录。如果自己用 useradd这些都得手动补。自动创建同名用户组。adduser 会创建一个与用户名同名的私有组比如用户 devops 建好以后系统里会多一个叫 devops 的组默认只有 devops 自己在这个组里。这样新用户家目录的默认属组是私有的便于权限隔离不至于和其他用户共享一个主组。交互式确认可以减少误操作。adduser 在设置密码时会让你输两次在创建前还会展示一次信息让你确认。虽然啰嗦一点但对手误的容忍度更高。如果你坚持要用 useradd那至少要写成这样才算完整sudo useradd -m -s /bin/bash -U zhangsan sudo passwd zhangsan-m 表示创建家目录-s 指定默认 shell-U 创建同名私有组。这一步同样能达到 adduser 的效果但你会发现代码远没有 adduser 来得直观。还有一个关键点为什么赋予管理权限时建议用 sudo 而不是直接把用户切到 root甚至把 root 密码告诉开发人员逻辑很简单。sudo 会把每一次提权操作都记录到日志里出了问题可以查是谁在什么时间执行了什么命令长期用 root 干活所有操作都混在一起排查事故时根本没法定位到人。而且 sudo 提权有密码有效期默认 5 分钟超时这 5 分钟内你可以连续执行超过后要重新输密码这个机制天然限制了“提权窗口”的暴露时间。2. 新建用户完整操作从检查环境到登录验证2.1 建用户前先确认这几件事在真正执行 adduser 之前我习惯先做几项确认避免建到一半才发现问题。首先看自己当前有没有 sudo 权限。执行 sudo whoami如果能输出 root说明当前账号具备提权条件。如果连当前账号都是普通用户且不在 sudo 组那得先联系管理员处理否则后面什么都做不了。其次检查用户名是否规范。Linux 用户名尽量使用小写字母可以包含数字但不要有空格不要以-开头也不要用root、admin、system这类容易和系统用户混淆的名字。比如给运维同事建账号我通常用 devops、deploy、op-xxx 这种格式简单好记。还要检查一下目标用户名是否已经存在getent passwd devops如果没有输出说明这个名字还没被用过可以继续。如果想看系统当前所有用户用cut -d: -f1 /etc/passwd最后顺手看一下家目录所在分区的剩余空间。家目录会占用磁盘虽然单个用户占用不大但养成习惯没坏处df -h /home2.2 adduser 创建用户的实际输出长什么样确认完环境之后执行创建命令sudo adduser devops如果 shell 语言是中文你会看到类似的输出正在添加用户devops... 正在添加新组devops (1001)... 正在添加新用户devops (1001) 到组devops... 创建主目录/home/devops... 正在从/etc/skel复制文件... 新的密码 重新输入新的密码 passwd密码已成功更新 正在改变 devops 的用户信息 请输入新值或直接敲回车键以使用默认值 全名 []: 房间号码 []: 工作电话 []: 家庭电话 []: 其它 []: 此信息是否正确 [Y/n]中间设置密码时终端不会显示任何字符输入两次一致即可。后面那一串全名、房间号、电话之类的是可选信息可以直接一路回车跳过最后输入 Y 确认。这一步创建完成之后验证一下结果id devops getent passwd devops ls -la /home/devopsid 命令能直观看到用户的 uid、gid 和所属组正常情况输出类似uid1001(devops) gid1001(devops) groups1001(devops)注意这里现在还没有 sudo 权限groups 里只有 devops 这一个私有组。ls 列出 /home/devops 时如果能看到 .bashrc、.profile 这些隐藏文件说明 /etc/skel 的复制已经生效。2.3 远程登录场景下的补充配置如果这台机器是远程服务器且开通了 SSH 密码登录新用户可以直接用密码登录。但我会强烈建议顺手把 SSH 密钥登录配好理由后面第 5 章细说这里先给个速通方案。在本地机器比如你自己的电脑上生成密钥对如果已经有密钥了可以跳过ssh-keygen -t ed25519 -C devopscompany然后把公钥推送到服务器的目标用户家目录ssh-copy-id devops服务器IP如果 ssh-copy-id 不可用也可以手动操作在服务器上用 devops 账号登录后创建 .ssh 目录并把公钥写入 authorized_keys注意权限必须设置正确mkdir -p ~/.ssh chmod 700 ~/.ssh echo ssh-ed25519 AAAA... 你的公钥内容 ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys.ssh 目录权限设为 700、authorized_keys 文件权限设为 600 是 SSH 的硬性要求权限过松会导致服务器拒绝使用该密钥这是很多人踩过的坑。3. 赋予管理权限sudo 组、sudoers 与提权原理3.1 推荐做法把用户加进 sudo 组Ubuntu 22.04 默认安装好之后/etc/sudoers 文件里已经预置了这样一行%sudo ALL(ALL:ALL) ALL意思是sudo 组里的所有成员可以从任何终端登录以任何用户身份执行任何命令。所以要把一个用户变成管理员最直接的做法就是把它加进 sudo 组。命令很简单sudo usermod -aG sudo devops这里我必须强调 -a 参数。a 是 append 的意思表示“追加”。如果你写成下面的写法sudo usermod -G sudo devops就糟糕了。-G 会覆盖用户现有的附加组列表。假设 devops 之前已经在 docker 组、www-data 组里这条命令执行完它会被彻底移出其他组只剩 sudo 组。这个坑我在生产环境见过不止一次有人加 sudo 权限顺手把同事的 docker 组权限弄丢了服务起不来才排查到原因。所以规则很简单给用户增加附加组时永远用 -aG 组合不要单独用 -G。除了 usermodadduser 也支持直接把用户加到指定组效果完全一样sudo adduser devops sudo使用 adduser 命令添加用户的输出会提示“正在将用户 devops 加入到 sudo 组中”。3.2 更精细的做法直接编辑 /etc/sudoers有些场景下你不想给用户完整的 root 权限只想让它能执行某几条管理命令比如重启服务、装软件包、管理 Docker。这时候就需要在 /etc/sudoers 里写更精确的规则。注意编辑 /etc/sudoers 有一个铁律必须使用 visudo不要直接用 vim 或 nano 去改。visudo 会在保存时检查语法如果语法不正确它会拒绝保存避免把整个 sudo 系统搞坏。一旦你把 /etc/sudoers 改成语法错误的状态所有用户包括 root 都无法再使用 sudo修复起来会很麻烦。用 visudo 打开后在文件末尾追加规则。一行规则的完整格式是用户名 来源主机(可以切换成的用户:可以切换成的组) 可执行的命令几个典型例子# 完整管理员权限 devops ALL(ALL:ALL) ALL # 只能以 root 身份执行 systemctl 和 apt 两个命令 devops ALL(ALL:ALL) /usr/bin/systemctl, /usr/bin/apt # 不需要输入密码即可执行 systemctl不推荐轻易使用 devops ALL(ALL:ALL) NOPASSWD: /usr/bin/systemctl第一条的含义拆解如下devops 可以在任意主机上使用 sudo身份可以切换到任意用户和任意组可以执行的命令不设限制。如果某用户只需要在特定机器上有权限可以把第一个 ALL 换成主机名。关于 NOPASSWD我个人的建议是能不用就不用。免密 sudo 虽然方便但等于只要有人拿到了你的登录凭据root 权限就是裸奔的连一道密码门槛都没有。除非是 CI/CD 机器、自动化脚本执行场景否则别图省事。3.3 三种授权方式对比与历史坑给用户授予管理权限常见的还有另一种做法直接把 root 密码告诉用户让它 su - 切 root。这种做法非常不推荐原因前面说过没有日志、不好审计、密码泄露范围不可控。所以我只推荐 sudo 组和 sudoers 自定义规则两种方式对比如下方式操作复杂度权限粒度适用场景加入 sudo 组低一条命令完整 root 权限管理员、运维同事、需要全权操作的人编辑 sudoers 指定命令中需要理解语法可精确到命令级开发人员只管服务重启、日志查看等直接告知 root 密码低但危险完整 root 权限不推荐任何常规场景都不要用这里还有个很容易被旧资料误导的点。Ubuntu 早期版本12.04 之前使用 admin 组来管理管理员组名是 admin 而不是 sudo。如果你翻到老教程让你执行 usermod -G admin 用户名在 Ubuntu 22.04 上是无效的因为默认根本没有 admin 组除非系统里有人手动创建过。现在的 Ubuntu 统一用 sudo 组看到旧教程要会分辨别盲目照搬。4. 权限验证与踩坑排查为什么明明加了组还是没权限4.1 验证权限的正确姿势执行完 usermod -aG sudo 之后很多人会立刻在当前终端里试 sudo发现提示没有权限就以为操作失败了。其实这里有个很容易忽略的细节已登录的会话不会自动刷新附加组信息。用户只有在新登录或者重新切换会话之后系统才会重新读取它的组信息。所以你操作完至少要 exit 再重新登录一次或者执行 newgrp sudo 来切换到新的组上下文。如果是在 SSH 会话里直接断开重连是最省事的办法。然后按顺序验证id devops此时输出应该包含 sudo 组uid1001(devops) gid1001(devops) groups1001(devops),27(sudo)再切换到 devops 用户运行sudo whoami如果输出 root说明提权已经生效。还可以用 sudo -l 查看当前用户被允许执行的命令列表它会把 /etc/sudoers 里匹配到当前用户的规则解析出来展示。4.2 最常见的几个坑坑一提示 user is not in the sudoers file. This incident will be reported.这个提示是新手最容易懵的。它出现在一个普通用户尝试 sudo但该用户既不在 sudo 组也不在 /etc/sudoers 里。很多在虚拟机、云主机上折腾的同学经常会遇到因为系统初始登录的是 cloud-init 创建的默认用户这个默认用户在 sudo 组里但你自己新建的用户如果没有用 -aG 加进 sudo 组就会触发这个提示。修复办法很简单用 root 或另一个 sudo 用户执行 sudo usermod -aG sudo 目标用户名。这里要注意cloud 镜像上可能该用户已经不在 sudo 组需要检查一下系统里到底有哪些 sudo 用户别把自己锁定在系统外。坑二usermod -G 误操作导致用户丢失原有附加组。这个前面已经讲了这里再给一个检查方法。发现用户权限不对时先用 id 用户 看看它的 groups 列表再对照 /etc/group 里的情况。如果发现用户少了某个组用 -aG 把原有组重新加回来即可。坑三sudoers 文件语法错误导致 sudo 全面瘫痪。如果 visudo 没有挡住错误或者有人绕过 visudo 直接改文件后果很严重。修复方法如果还能以 root 身份登录物理终端或管理控制台直接用 visudo 修正如果 root 也切不进去在 GRUB 引导界面进入 single 模式单用户模式修复或者依赖云控制台的密码重置功能。总之代价很大老老实实用 visudo。坑四sudo: unable to resolve host xxx。这个提示通常出现在修改过主机名之后。系统在解析主机名时/etc/hosts 里没有对应记录。解决办法是编辑 /etc/hosts加一行127.0.1.1 你的主机名在 Debian/Ubuntu 系系统上本机名映射一般写在 127.0.1.1 而不是 127.0.0.1这个细节经常被忽略。坑五新用户 SSH 登录直接被拒绝。新用户建好后用密码登录却报 Permission denied。排查顺序是先确认密码没错、账号没锁定再确认用户的 shell 是否合法。可以用以下命令看getent passwd devops如果最后一列是 /bin/false 或 /usr/sbin/nologin说明这个账号被设计成不能登录系统这是系统用户的通用配置普通用户不该有这种 shell。修复方法sudo chsh -s /bin/bash devops另一个可能原因是家目录权限不对。SSH 要求家目录和 .ssh 目录不能被其他用户写入权限最好按我第 2 章说的设置。遇到 SSH 问题可以看服务端日志sudo tail -f /var/log/auth.log里面会明确告诉你被拒绝的具体原因比盲猜快得多。5. 顺手的初始化操作一个新管理员账号的安全基线5.1 家目录和默认 shell 检查adduser 建出来的用户默认 shell 是 /bin/bash但如果你或者之前的脚本用了 useradd 或从别的地方复制来的用户模板shell 可能需要修正。检查方式getent passwd devops最后一列就是登录 shell。如果不是 /bin/bash用 chsh 修改sudo chsh -s /bin/bash devops家目录权限也值得确认。adduser 创建的家目录权限默认是 700这个设置很合理——家目录里的东西默认只有自己和 root 能看到。如果不小心变成了 755其他用户就能浏览你的家目录文件存在隐私泄露风险。直接检查ls -ld /home/devops输出中权限位是 drwx------ 就正常如果是 drwxr-xr-x用 chmod 修正sudo chmod 700 /home/devops还有一点容易被忽略新用户的环境变量模板来自 /etc/skel而这个目录里的配置可能是几年前的 Git 版本留下来的。如果你想给所有新用户预设统一的 alias、环境变量可以直接编辑 /etc/skel/.bashrc后续新建的用户会自动继承。5.2 SSH 密钥登录与安全加固远程管理的服务器我强烈建议把 SSH 登录方式从密码改成密钥。理由很现实密码登录本身就暴露在暴力破解的风险里而且当你给多个同事开账号时一旦有一个人密码泄露攻击者就能进来乱搞。密钥登录的私钥只存在于个人设备上风险面小得多。配好密钥之后可以考虑把密码登录关掉。编辑 /etc/ssh/sshd_configPasswordAuthentication no PermitRootLogin no然后重启 SSH 服务sudo systemctl restart sshd这里有个重要提醒千万不要在还没有验证新用户能正常密钥登录之前就关掉密码登录。我在生产环境看到过有人直接给服务器加上密码登录禁用结果自己的公钥没配好当场被关在门外只能通过云服务商的后台控制台或者机房物理访问恢复。正确的操作顺序是把自己和同事的密钥都配置好用新用户、新密钥完整测试一遍登录确认没问题后再修改 sshd_config重启 SSH 后保持当前连接不要关另开一个会话测试一次如果新开会话能连上再放心关掉旧的连接。这套操作下来基本不会出问题。5.3 账号生命周期管理账号建完、权限给了不意味着这件事就结束了。我见过不少公司的服务器上躺着五六个几年前离职员工的账号依然保持着 sudo 权限这是很大的安全隐患。出于管理习惯我会定期做几件事用下面命令查看谁在 sudo 组里getent group sudo快速检查所有用户及其 shell 属性区分正常登录用户和系统服务用户awk -F: $31000 {print $1, $3, $7} /etc/passwd遇到离职或者不再需要访问的账号不要直接删尤其是它的家目录里可能还有项目文件。常规做法是先禁止登录sudo usermod -L 用户名-L 是锁定密码锁了之后该用户无法通过密码登录。如果登录方式是纯密钥锁密码还不够需要配合把它的 authorized_keys 清掉或禁用账号。等确认数据备份完成后再彻底删除sudo userdel -r 用户名-r 参数会同时删除家目录和邮件 spool执行前务必确认里面的数据已经没用了。如果在操作过程中需要临时查看某用户最近一次 sudo 记录可以查日志sudo grep sudo /var/log/auth.log | tail -50这里能看到谁在什么时候用了 sudo 执行什么命令是排查操作事故的第一手资料。最后再分享一个我自己的习惯新建账号时先建用户、加 sudo 组、配密钥完整验证能登录且能提权最后才考虑关掉 root 密码登录。这套顺序能保证整个过程都有一条安全的退路不至于把自己锁在外面。而账号管理的重心其实不是“建”的这一步而是“管”的长期动作——定期清理闲置账号、检查 sudo 组成员、确认密钥没有被随意扩散。Ubuntu 22.04 的命令本身不复杂把这条链路由始至终理顺了后续管理才能省心。