Linux 用户与用户组管理：从建账号到 sudo 授权的完整操作

在一台 Linux 服务器上，你和机器之间不是"直接对话"，而是通过"用户身份"对话的。root 是超级管理员，权力大到能删光整个系统；普通用户则被关在权限笼子里。学会正确地创建用户、分配组、授予 sudo 权限，并禁用 root 直接登录，是每台新服务器上线前的必修课。这篇文章把最常用的用户组管理命令串成一条清晰的操作线，让你既能干活，又不会一脚踩翻系统。

一、先搞懂：系统用户、普通用户、root

Linux 里用户分两类：系统用户（UID 通常小于 1000，专门给服务进程用，比如 nginx、mysql）和常规用户（UID 从 1000 起，给人用）。root 的 UID 是 0，拥有绝对权力。设计哲学是：日常操作绝不用 root，而是用一个普通用户 + sudo 临时提权。这样即使你敲错命令，影响也被限制在用户权限内，不至于一击致命。理解这套身份模型，后面所有命令才有意义。

二、创建用户：adduser 还是 useradd

Debian/Ubuntu 有交互式的 adduser，一条命令就帮你建好家目录、设好 shell、还能顺便设密码，对新手最友好。RHEL 系习惯用更底层的 useradd，它默认不建家目录，必须加 -m 才建，加 -s 指定 shell。跨发行版写脚本时，统一用 useradd -m -s /bin/bash 最稳妥。建完别忘 sudo passwd 用户名 设置密码——空密码的账户在很多系统上无法登录 SSH。

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

三、修改用户：usermod 是主力

改用户属性几乎都靠 usermod。最常用的是把用户加进附加组：-aG 两个字母缺一不可，-a 表示"追加"，G 表示"附加组"；如果漏掉 -a，写成 -G sudo deploy，系统会直接用 sudo 组覆盖掉用户原有的所有附加组，导致他丢失 docker、www-data 等其它组成员身份。改登录 shell 用 -s，改家目录并迁移内容用 -d 加 -m，临时锁账户用 -L，设过期日期用 -e。这些开关组合起来，几乎能调整用户的全部属性。

sudo usermod -aG sudo deploy
sudo usermod -aG docker deploy
sudo usermod -s /bin/zsh deploy
sudo usermod -L deploy

四、组管理：groupadd / gpasswd

组是批量赋权的单位。新建组用 groupadd，删组用 groupdel。把用户加进组有两种写法：usermod -aG 或 gpasswd -a。查看某人属于哪些组，用 groups 用户名 或 id 用户名。当你要给一拨人相同的目录权限或 sudo 权限时，正确的做法不是逐个改人，而是建一个组、把人加进去、对组授权——这才是可维护的权限管理。

sudo groupadd devteam
sudo gpasswd -a deploy devteam
groups deploy
id deploy

五、sudo 授权：千万别直接改 sudoers

给普通用户提权，正统方式是 sudo。但绝对不要用 vim 直接改 /etc/sudoers——一旦语法写错，可能让所有管理员失去 sudo，甚至把自己锁死。正确姿势是用 visudo，它会先校验语法再保存。更优雅的是把规则拆到 /etc/sudoers.d/ 下的独立文件，比如 /etc/sudoers.d/deploy，里面写 deploy ALL=(ALL) ALL 表示全权。模块化文件互不干扰，哪条规则出问题就改哪条，不碰全局。

sudo visudo -f /etc/sudoers.d/deploy

六、安全加固：禁用 root 直登

互联网上每秒都有脚本在扫 22 端口试 root 密码。最基础的防御是在 /etc/ssh/sshd_config 里设 PermitRootLogin no，并配合密钥登录后设 PasswordAuthentication no。改之前务必先确认你那个普通用户已经能用密钥登录、且 sudo 正常——否则改完重启 sshd，你会发现自己被关在门外。记住一条铁律：保留一个已登录的会话，开新窗口测通了，再退出旧会话。安全是一步步叠出来的，不是赌出来的。

sudo ssh-copy-id deploy@server
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

七、锁账户与删账户

同事离职或账号异常时，先锁再删。passwd -l 给密码加锁标记，用户暂时无法密码登录；chage -E 0 直接让账户过期失效。确认无误后 userdel -r 连家目录一起删，避免留下一堆无人认领的文件占空间。注意：删账户不会自动删掉他创建的其他位置的文件，重要数据要先备份再操作。权限回收这种事，慢一点比错一点好。

sudo passwd -l olduser
sudo chage -E 0 olduser
sudo userdel -r olduser

八、日常自查清单

把上面串成习惯：新服务器到手，先建普通用户、加 sudo、推密钥、禁 root 密码登录；需要批量权限就建组授权；人员变动就锁账户再清理。每隔一阵用 id 和 groups 复查一下关键账户的组成员，防止权限悄悄膨胀。用户组管理看着琐碎，却是服务器安全的地基——地基稳，上面的应用才稳。

补充与延伸：用户组其实是权限的边界

很多人把用户和用户组当成"建账号"这种小事，真正上线跑业务后才发现，权限设计直接决定了一台机器被攻破时的影响半径。一个 Web 应用如果以 root 身份运行，一旦被注入代码，攻击者就拿到了整台机器的控制权；而如果它跑在专用的 www 用户下、只对自己目录有写权限，爆炸半径就被锁死在那个目录里。所以"最小权限原则"不是一句口号，而是把每个进程、每个人员都关进合适的笼子里。用户组正是给这些笼子贴标签的工具：把人归到 dev 组、把应用归到 app 组、把管理员归到 sudo 组，权限就跟着组走，而不是跟着每个人反复配置。

实际运维里还有几个容易忽略的点。第一，不要用 root 直接干日常活，永远用普通用户加 sudo，这样每条提权命令都会留下日志，出了问题能回溯是谁、什么时候做的。第二，临时离开工位要锁屏，但更重要的是服务器层面：人员离职时先 usermod -L 锁账户，再归档家目录，最后才删用户，顺序反了可能误删还在用的文件。第三，/etc/sudoers 千万别手改出错，一定要用 visudo，它会做语法校验，一个拼写错误就可能让你失去所有 sudo 权限、连修复入口都没了。

再补一句最容易被坑的细节：家目录权限默认 700，意味着其他用户进不去你的目录，这很好；但如果你图方便把某些目录 chmod 777 共享，等于对同机所有用户敞开，别人误删或读走你的密钥都可能发生。所以共享文件优先用"新建一个组 + 把相关人加进去 + chgrp 改组 + 设 770"的方式，而不是粗暴地 777。权限的细腻程度，直接体现了你对这台机器掌控的专业度。

最后说一个进阶思路：当机器多了，靠手工 useradd 会乱，可以引入集中式身份（LDAP/SSSD）或者配置管理工具（Ansible 的 user/group 模块）来统一管理。但在只有一两台 VPS 的阶段，把本文的命令整理成一份自己的初始化脚本，每次新机到手就跑一遍，比临时百度要稳得多。用户组管理看着朴素，却是你从"会用 Linux"走向"会管 Linux"的第一道门槛。

顺带一提，排查权限问题时最常问的一句是"为什么我不能写这个文件"。答案几乎都在 ls -l 的权限位和属主属组里：你是谁（whoami）、你在哪些组（groups）、文件属于谁、组有没有写权限。把这三者对上，九成的权限报错都能当场说清。把这条链路在脑子里走顺，你就不会再被 Permission denied 吓住，而是能冷静地用 chown 或 chmod 把它摆平。

说到底，用户与组管理是 Linux 多用户哲学的体现：它假设机器上会有很多人、很多程序共存，于是用账号和组把彼此隔开、各司其职。你越早把这种"分隔思维"内化成习惯，后面遇到权限、安全、协作的问题就越顺。本文的命令不多，但每一条都对应一种运维姿势，值得你在新机器上亲手跑一遍、记牢。