鄂奎阿1. 从“创建一条命令”到“理解一套机制”
很多运维新手第一次接触 Linux 用户管理，都是这样上手的：useradd testuser，然后 passwd testuser，完事。最多再补一个 usermod -aG wheel testuser 提个权，就觉得自己会了。直到有一天生产环境出了问题——用户明明创建成功了，却登录不上；加了 sudo 权限，却提示不在 sudoers 中；删了一个用户，结果发现该用户创建的一堆文件变成了一个莫名数字的属主。这时候你才会意识到：Linux 的“用户和组”，根本不只是一条命令、一个配置文件，而是一整套由 UID/GID 分配、认证数据存储、组权限继承机制共同组成的系统。
这篇文章我想系统梳理一下 Linux 用户和组的创建机制，不是罗列 useradd 的参数表，而是把“创建用户时系统到底做了什么”这件事讲透。你会看到 /etc/passwd、/etc/shadow、/etc/group 这三个文件如何协同工作，UID/GID 是怎么分配的，为什么说“组”是 Linux 权限管理里最核心的抽象，以及当 SSH 登录、sudo 授权、文件属主这些实际场景叠加进来时，用户和组的创建机制是如何影响你后续所有操作的。
不管你是刚接触 Linux 的在校学生，还是在生产环境摸爬滚打的运维，这篇文章都值得你从头读到尾。前 2000 字讲机制和原理，中间 3000 字给实操步骤和参数选择逻辑，最后 1500 字分享我在真实服务器上踩过的问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 创建用户时系统到底做了什么
useradd 看起来只是往系统里加了一条记录，但如果你把整个流程拆开看，它涉及至少七个环节的联动。这也是为什么很多人在“创建用户”这件事上出错，因为只盯着命令本身，没看到背后完整的处理流程。
2.1 三个核心文件的工作机制
Linux 系统中用户和组的持久化信息主要存在三个文件里：
/etc/passwd：用户账户的基础信息，包括用户名、UID、GID、家目录、登录 shell。/etc/shadow：用户的密码哈希和密码策略（有效期、最短修改间隔、过期警告等），普通用户不可读。/etc/group：组的信息，包括组名、GID、组成员列表。
这三个文件以冒号分隔字段，每一行代表一条记录。/etc/passwd 的一行长这样：
code复制testuser:x:1001:1001::/home/testuser:/bin/bash
字段依次是：用户名、密码占位符（x 表示真实密码在 shadow 中）、UID、主组 GID、注释信息、家目录、登录 shell。
/etc/shadow 对应行则是：
code复制testuser:$6$randomSalt$hashValue:19000:0:99999:7:::
这里存的是加密后的密码哈希、最后一次修改密码的日期、最短修改间隔、最长有效期、过期前警告天数等。注意一个在运维里很关键的细节：如果 shadow 文件中密码字段为 ! 或 !!，表示该账户没有设置密码或被锁定，这时候哪怕你创建了用户，他也没办法通过密码登录。
/etc/group 的一行是这样：
code复制testuser:x:1001:
对应：组名、组密码占位符、GID、组成员列表（可以为空，表示只有同名用户是该组成员）。
很多初学者会忽略这三者的一致性。实际上，用户管理出问题，大部分时候都是这三个文件之间的对应关系被破坏了。所以我给新人的第一个建议就是：在手动编辑这些文件之前，务必先备份，或者尽量使用 useradd、usermod、groupadd 这些官方命令来操作，而不是直接 vi /etc/passwd。
2.2 创建用户的完整流程拆解
当我们执行 useradd -m -G wheel -s /bin/bash testuser 时，系统按顺序做了这些事情：
- 读取
/etc/login.defs和/etc/default/useradd，获取默认配置（UID 范围、密码过期策略、默认 shell、默认家目录路径等）。 - 在
/etc/passwd末尾追加一行新用户记录，分配一个未使用的 UID 和主组 GID。 - 在
/etc/shadow中创建对应条目，初始密码字段为!，表示账户暂时被锁定，直到passwd设置密码后才可用。 - 在
/etc/group中创建一个与用户名同名的组（如果不指定-g），GID 与 UID 相等。 - 如果指定了
-m，在/home下创建家目录，并复制/etc/skel下的隐藏文件（.bashrc、.bash_profile、.profile等）进去。 - 设置家目录的属主和权限，默认是
testuser:testuser，目录权限为 700。这就是为什么其他用户无法查看你 home 目录下文件的原因。 - 如果指定了
-G，将用户添加到附加组列表中，这一步实际修改的是/etc/group中对应组的成员字段。
第七步有一个容易踩坑的地方：-G wheel 表示将用户加入 wheel 组作为“附加组”，而 -g 指定的是“主组”。主组决定用户创建文件时默认的属组，附加组决定用户还能访问哪些额外权限资源。这两者的区别，在实际运维中经常被人混淆。
2.3 UID/GID 分配的底层逻辑
Linux 内核并不关心你的用户名是什么，它只认识 UID（用户 ID）和 GID（组 ID）。内核在进行权限检查时，比较的是进程的有效 UID 和文件系统对象的属主 UID。也就是说，用户名只是给人看的映射表。
useradd 分配 UID 时遵循一套规则：
- 默认从
/etc/login.defs中UID_MIN和UID_MAX之间找空闲值，常见的发行版配置是 1000-60000 或 1000-65534。 - 分配时会优先选择当前已有最大的 UID 加 1，而不是去“补空位”。这样可以避免 UID 被重复使用引发的安全问题。
- UID 0 是 root，1-999 系统保留给服务账户（如
sshd、nginx、mysql等），普通用户从 1000 开始。
GID 的分配逻辑类似，groupadd 会从 GID_MIN 到 GID_MAX 之间找一个空闲值。
为什么说 UID 不能随便改？因为文件系统里记录的不是用户名，而是 UID。当你把某个用户的 UID 从 1001 改成 2001 时，系统里所有原本属主为 1001 的文件并不会自动更新，它们仍然显示为 UID 1001 的数字。这时候在 ls -l 里你会看到一串数字，而不是用户名，这就是经典的“文件属主变成数字”问题。如果不小心把 UID 改成了 root 的 0，那后果会更严重——这个用户就变成了超级用户，拥有全系统的控制权。
3. 组机制是权限管理的核心抽象
如果说用户解决的是“我是谁”的问题，那么组解决的就是“我们是谁一起共享哪些资源”的问题。理解组机制，你的 Linux 权限管理能力会上一个台阶。
3.1 为什么需要组而不是只靠用户
假设一个项目团队有 8 个人，需要共享 /data/project 这个目录。如果不使用组，你可能会给每个用户单独设 ACL，或者干脆把目录权限设成 777——前者管理繁琐，后者安全隐患巨大。
有了组之后，方案变得非常清晰：
- 创建一个
project组：groupadd project - 把 8 个用户都加入这个组：
usermod -aG project user1、usermod -aG project user2等 - 设置目录属组和权限：
chown root:project /data/project && chmod 2770 /data/project
这样核心目录归 root:project 所有，组内成员可读可写，其他人完全无权限，并且有 setgid 位（2 前缀）确保新创建的文件自动归属 project 组。整个过程干净利落。
组本质上是一种“权限集合”的抽象，它让我们可以把人按角色分组，再给角色赋予权限，而不是给每个具体的人直接赋权。这在服务器数量多、人员流动频繁的场景下尤其重要：有人离职时，只需把他从组里移除，不用去改所有服务器上的目录权限。
3.2 主组与附加组的区别
每个用户有且仅有一个主组（primary group），但同时可以属于多个附加组（supplementary groups）。
主组决定两件事：一是用户登录后默认的组身份（id 命令显示的 gid），二是用户创建新文件时，文件的属组默认是当前主组（除非所在目录有 setgid 位）。
附加组则可以理解为“额外通行证”。文件权限检查时，内核不仅比较文件的属组和用户主组，还会检查用户所有附加组中是否有匹配项。这一机制让我们无需修改用户的主组，就能让他访问多个共享资源。
我见过一个典型的错误用法：使用 usermod -g newgroup user 来改用户的“主组”，结果发现该用户原来的主组被替换了，他创建的文件属组全变了，其他依赖旧组权限的访问就断了。正确做法是：如果想保留原主组并加入新组，应该用 usermod -aG newgroup user，其中 -a 表示 append（追加），-G 表示附加组。不加 -a 时，usermod -G 会先清空用户原来的附加组列表，再设置新组。
3.3 特殊组别与安全加固
在 Linux 系统中，有一些特殊组值得特别注意：
wheel：传统上是“可以切换成 root”的管理员组。配置好 sudo 或 su 后，只有该组成员能执行特权操作。这在很多发行版中默认启用，CentOS/RHEL 系尤甚。sudo：Debian/Ubuntu 系的管理员组，等效于 CentOS 下的 wheel。systemd-journal：可以读取系统日志，在安全审计时这个组很重要。docker：加入该组的用户可以不通过 sudo 直接执行docker命令，等价于间接拿到 root 权限（因为 docker daemon 以 root 权限运行容器）。给用户加入 docker 组时必须非常谨慎，这是安全边界问题。adm：部分发行版中拥有查看某些系统日志文件的权限。
以 wheel 组为例，它本身并不提供任何权限，真正的权限控制是在 /etc/sudoers 或 PAM 配置中完成的。sudoers 里通常有一段配置：
code复制%wheel ALL=(ALL) ALL
意思是允许 wheel 组的所有成员在所有主机上以所有用户身份执行所有命令。想限制某用户只能执行特定命令，可以单独配置，比如：
code复制testuser ALL=(ALL) /bin/systemctl, /usr/bin/uptime
这就是基于组的权限控制最常见的落地方式。
4. SSH 实战：从创建用户到限制登录
下面进入实例环节。这个例子综合了用户创建、组管理、SSH 登录控制这几个最常见的运维需求，可以说是生产环境里最典型的场景之一。
4.1 场景需求描述
我的服务器上有三个运维人员和一个外部合作人员。需求如下：
- 所有运维人员可以 SSH 登录服务器，并可以切换到 root。
- 外部合作人员只能 SSH 登录，不能使用 sudo。
- root 用户不允许通过 SSH 直接登录。
- 服务器只能由特定组用户通过 SSH 登录。
这类需求几乎在每个企业服务器上都会出现，核心就是通过用户组来控制 SSH 访问边界。
4.2 实施步骤与参数解释
第一步，创建运维人员用户并加入 wheel 组：
bash复制useradd -m -G wheel -s /bin/bash alice
useradd -m -G wheel -s /bin/bash bob
passwd alice
passwd bob
这里 -m 创建家目录，-G wheel 将用户加入附加组 wheel，-s /bin/bash 设置 shell。如果省略 -m，有些发行版（如 Ubuntu 新版）不会自动创建 /home/alice，用户登录后可能没有家目录可用。
第二步，创建外部合作人员用户，不加入任何特权组：
bash复制useradd -m -s /bin/bash carol
passwd carol
第三步，编辑 sudoers 文件，允许 wheel 组成员使用 sudo：
bash复制visudo
在文件中确认或添加：
code复制%wheel ALL=(ALL) ALL
之所以用 visudo 而不是直接编辑 /etc/sudoers，是因为 visudo 会做语法校验，防止你写错导致 sudo 完全无法使用。这是 Linux 运维里一个非常经典的“安全网”。
第四步，配置 sshd 限制登录：
bash复制vim /etc/ssh/sshd_config
修改或添加以下配置：
code复制PermitRootLogin no
AllowGroups wheel sshusers
这里解释一下：PermitRootLogin no 禁止 root 直接登录。AllowGroups 指定允许通过 SSH 登录的组，多个组用空格分隔。如果服务端配置了 AllowGroups wheel sshusers，而外部合作人员不在任何被允许的组里，那么他即使账户存在、密码正确，也会被拒绝。
不过这样外部合作人员就登录不了了，因为他不在 wheel 组也不在 sshusers 组。所以实际部署时应该先创建 sshusers 组，把需要 SSH 登录的人全加进去：
bash复制groupadd sshusers
usermod -aG sshusers alice
usermod -aG sshusers bob
usermod -aG sshusers carol
或者更严格一点，把外部合作人员单独放到一个限制组，然后配置 AllowGroups 只包含他所在的组。具体怎么选，取决于你对安全的容忍度。
第五步，重启 sshd 服务，使配置生效：
bash复制systemctl restart sshd
注意：重启 sshd 前建议先开一个临时会话窗口，不要关掉当前连接。如果配置有误，至少还有一条退路。一旦 sshd 配置导致无法连接，你就只能通过控制台（如云厂商的 VNC）或物理机上去了。
4.3 SSH Key 登录与关闭密码认证
在实际生产环境中，我强烈建议在用户创建之后立即配置 SSH 公钥认证，然后关闭密码认证。具体流程是：
- 在客户端生成密钥对：
ssh-keygen -t ed25519 -C "alice@work"。 - 将公钥放到服务器上对应用户的
~/.ssh/authorized_keys中。 - 在 sshd_config 中设置
PasswordAuthentication no，重启服务。
使用 ed25519 而不是 RSA 2048/4096，是因为 ed25519 密钥更短、生成更快、安全性更高。如果你需要兼容老系统（比如某些只支持 RSA 的嵌入式设备），再用 RSA。
关闭密码认证后，用户只能通过密钥登录，密码爆破攻击基本直接失效。这是目前 SSH 安全加固里性价比最高的操作之一。
4.4 用户创建后的权限校验
上述所有配置完成后，你需要做几件事来验证：
bash复制# 查看用户的 uid、gid、附加组
id alice
# 测试 sudo 权限
su - alice
sudo whoami
# 在另一个终端尝试 ssh
ssh alice@server_ip
id alice 的输出格式是：
code复制uid=1001(alice) gid=1001(alice) groups=1001(alice),10(wheel),100(sshusers)
groups 列表里能看到主组 alice、附加组 wheel 和 sshusers，说明组配置生效了。如果 sudo whoami 返回 root，说明 sudoers 配置正确。如果 SSH 能正常登录，说明 AllowGroups 没有配置错。
还要注意：刚创建的用户，如果没有设置密码，/etc/shadow 中的密码字段是 !，SSH 无论密码还是密钥都会登录失败。设置密码用 passwd，或者如果你后续打算完全用密钥登录，也可以跳过设置密码，但此时用户将无法通过密码登录任何地方。
5. 用户管理的常见坑与排查实录
相信很多运维都经历过半夜被叫醒，说哪个用户登不上服务器了，结果排查半天发现是用户管理层面的低级错误。下面这些坑我基本都踩过，整理出来希望能帮你省掉几小时排查时间。
5.1 用户创建后无法 SSH 登录
症状：用户明明创建成功了，shell 用 su - username 也能登录，但 SSH 连不上。
排查步骤：
- 确认 sshd 配置是否有限制：
grep -E "AllowGroups|AllowUsers|DenyGroups|DenyUsers" /etc/ssh/sshd_config。 - 确认用户所属组是否匹配 AllowGroups。
- 确认用户 shell 是否在
/etc/shells中。如果 shell 不在这个列表里，sshd 会拒绝登录。把/bin/bash加到/etc/shells，或者给用户设置合法 shell。 - 查看日志：
tail -100 /var/log/secure（CentOS/RHEL）或journalctl -u sshd --no-pager -n 50（Debian/Ubuntu）。
根据我的经验，80% 的“创建用户后无法 SSH”都是这三个原因：AllowGroups 没包含该用户组、密码锁定期未解除、shell 路径不合法。日志里一般会写明拒绝原因，比如 User alice not allowed because not listed in AllowGroups。
5.2 误删用户导致文件属主变数字
我见过有人这样操作：userdel testuser，然后发现系统的 /tmp 下全是 UID 1001 属主的文件。
userdel 默认不会删除用户的家目录和用户所拥有的文件。当你删除用户后，系统里就没有 UID 1001 这个条目了，但文件系统里属主为 1001 的普通文件仍然存在。这些文件会显示为数字属主，而且完全无法通过用户名来识别。
如果确认该用户确实不再需要，文件也都不需要了，再删干净一点：
bash复制userdel -r testuser
-r 参数表示同时删除用户家目录和邮件池（mail spool）。但要谨慎使用，如果家目录里有重要数据，一定要先备份。
如果不小心删除了用户但文件还需要，有两个补救方案：
- 新建一个同名用户，但指定相同的 UID：
useradd -u 1001 testuser，这样新用户自动拥有旧文件。 - 用
find / -uid 1001找出所有文件，再用chown把它们批改归给新用户。
我倾向于方案一，因为改 UID 比改一大批文件的属主风险小得多。
5.3 主组被误改导致共享目录访问失败
这个案例很典型。某个项目组共享一个 /data/project 目录，之前一直正常。某天 DevOps 想给其中一个成员开一个新项目组的权限，执行了：
bash复制usermod -g newproject alice
然后 alice 就突然无法往 /data/project 里写文件了。
原因：-g 修改的是 alice 的主组，从原来的 project 组变成了 newproject。她创建新文件时默认属组会变成 newproject，但由于 /data/project 的权限是 root:project 2770，只有 project 组成员能写。alice 的主组已经改了，而附加组列表里如果之前没有 project，她自然就失去写权限了。
正确做法是保留原主组，用追加的方式增加附加组：
bash复制usermod -aG newproject alice
如果你已经执行了 -g 把主组改了，补救办法是：
bash复制usermod -g project alice
usermod -aG newproject alice
这是组管理里最常见的“一次性把事情搞坏”的操作。记住：主组尽量少改，加组用 -aG，改主组前务必确认影响范围。
5.4 普通用户无法 sudo
用户加入了 wheel 组，但执行 sudo 仍然提示 alice is not in the sudoers file. This incident will be reported.
这个错误很迷惑，因为用户明明在 wheel 组里。排查思路：
- 确认用户确实在 wheel 组：
id alice，看输出里是否有 wheel。 - 确认
/etc/sudoers中是否真的有%wheel ALL=(ALL) ALL这一行配置，很多精简安装的系统默认没有配置这一行，需要自己加。 - 确认 sudoers 文件语法是否正确：执行
visudo -c。 - 如果是 Debian/Ubuntu 系，确认是
sudo组而不是wheel组。
其中一个非常容易被忽略的细节：刚把用户加入 wheel 组，如果用户已经有一个登录会话，那么这个会话里的组信息不会自动刷新。你需要让他退出重新登录，或者执行 newgrp wheel 手动切换组上下文。新股信息只在新会话中生效，这也是很多新手困惑的地方。
5.5 密码策略相关坑
创建用户时如果不对密码策略做规划，容易遇到这类问题：用户设置了一个简单的密码，系统提示密码太短；或者密码过期后远程登录被拒绝。
这些行为受两个层面的控制：
/etc/login.defs中的PASS_MAX_DAYS、PASS_MIN_DAYS、PASS_WARN_AGE等参数，影响默认密码有效期。- PAM 模块（如
pam_pwquality.so）控制密码强度。
如果你要创建一个长期有效的服务账户，可以设置密码永不过期：
bash复制chage -M -1 service_account
如果你需要用户下次登录时立即修改密码，可以设置密码过期时间为 0：
bash复制chage -d 0 newuser
这个命令会让用户第一次登录时强制修改密码，非常适合给临时员工开账号。
5.6 用户管理命令速查
我把日常运维中最常用的命令整理成一个速查表，按使用频率排序，方便直接复制使用：
| 操作场景 | 命令 | 说明 |
|---|---|---|
| 创建用户 | useradd -m -s /bin/bash username |
创建用户并创建家目录 |
| 创建用户并加组 | useradd -m -G wheel -s /bin/bash username |
-G 为附加组 |
| 设置密码 | passwd username |
交互式设置 |
| 修改用户附加组 | usermod -aG devgroup username |
追加组，必须带 -a |
| 修改用户主组 | usermod -g newgroup username |
谨慎使用 |
| 锁定用户 | usermod -L username |
禁止登录 |
| 解锁用户 | usermod -U username |
恢复登录 |
| 删除用户 | userdel -r username |
-r 同时删除家目录 |
| 创建组 | groupadd devgroup |
|
| 查看用户信息 | id username |
显示 uid/gid/所有组 |
| 查看用户上次登录 | lastlog -u username |
|
| 设置密码有效期 | chage -M 90 username |
密码 90 天后过期 |
| 强制下次登录改密码 | chage -d 0 username |
有一个小技巧分享给大家：创建大量用户时，不要一条条手动执行，可以写一个简单的 for 循环脚本。比如批量创建 10 个开发用户并加入 dev 组：
bash复制for u in dev01 dev02 dev03 dev04 dev05 dev06 dev07 dev08 dev09 dev10; do
useradd -m -G dev -s /bin/bash "$u"
echo "${u}:initialPass123" | chpasswd
chage -d 0 "$u" # 下次登录强制改密
done
chpasswd 可以非交互式批量设置密码，chage -d 0 强制用户首次登录修改，避免初始密码长期暴露。
6. 结合 PAM 与 sudo 的更深层应用
当你理解了用户和组的创建机制，下一步自然要接触 PAM 和 sudoers 这两个关联最紧密的子系统。
6.1 PAM 如何影响用户登录
PAM（Pluggable Authentication Modules，可插拔认证模块）是 Linux 登录认证的框架。它本身不处理用户创建，但在用户登录时决定“你允不允许这个进程获取这个用户的身份”。
一个常见的需求：禁止某类用户从 SSH 登录，但允许从 console 登录。你可以在 /etc/ssh/sshd_config 中设置 AllowGroups sshusers，实现 SSH 层面的过滤；也可以在 /etc/pam.d/sshd 中配置 pam_access.so 做访问控制。
用 PAM 的好处是控制粒度更细。比如你可以这样配置 /etc/security/access.conf：
code复制- : ALL EXCEPT root wheel : tty1 tty2
意思是不允许除 root 和 wheel 组之外的所有用户从 tty1、tty2 登录。这样即使有人创建了一个新用户，也没法从物理终端登录，因为 PAM 层直接拦掉了。
在配置 PAM 时，我只说一条铁律：改任何 /etc/pam.d/ 下的文件，先备份，且不要在正在使用的 SSH 会话里改 /etc/pam.d/sshd。因为 PAM 配置语法极其苛刻，一个符号错了，可能导致所有人无法通过 SSH 登录。我身边至少有两个同事因为这件事，最后不得不去机房重启服务器、挂载救援盘才能恢复。
6.2 sudoers 中如何更好利用组
sudoers 文件中，用户列表可以是用户名、组名（% 开头）或用户 ID（# 开头）。我们前面已经见过 %wheel ALL=(ALL) ALL 这种写法。
更精细的授权场景，比如只允许某个组执行指定命令：
code复制%devs ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx
这样 devs 组的成员只能重启和查看 nginx 状态，无法执行其他特权命令。
sudoers 还有一个常用的别名机制，比如先定义命令别名，再授权给组：
code复制Cmnd_Alias SERVICES = /usr/bin/systemctl restart nginx, /usr/bin/systemctl restart php-fpm
%devs ALL=(ALL) SERVICES
这种写法在生产环境里维护起来非常顺手，权限调整只需要改别名定义或组名，不需要逐条修改每个用户的授权。
sudo 授权的最小化原则同样适用：能指定具体命令的，就不要给 ALL=(ALL) ALL。给每一行授权打上注释，写清楚这条规则是给谁、为什么加的。这个习惯在你半年后回看 sudoers 文件时会救你一命。
6.3 用户管理的审计与日志
用户和组的管理常常涉及安全审计。至少需要保证三件事：
-
开启命令历史审计：在
/etc/bashrc或/etc/profile中设置HISTSIZE=10000，并且配置记录时间戳（export HISTTIMEFORMAT="%F %T "），这样你能看到用户何时执行了什么命令。 -
关注认证日志：CentOS/RHEL 系看
/var/log/secure，Debian/Ubuntu 系看/var/log/auth.log。这两个日志记录着所有 SSH 登录尝试、sudo 使用、su 切换等关键事件。 -
使用
auditd对关键文件做审计：比如对/etc/passwd、/etc/shadow、/etc/group的写入操作都记录到审计日志：
bash复制auditctl -w /etc/passwd -p wa -k user-file
auditctl -w /etc/shadow -p wa -k user-file
auditctl -w /etc/group -p wa -k user-file
如果哪天用户文件出了问题，ausearch -k user-file 能直接告诉你谁在什么时候改过这些文件。在没有统一配置管理工具（如 Ansible、Puppet）的小规模服务器集群里，这套方案足够实用。
7. 最后的实操心得
回到文章开头的问题——创建用户到底是一项技能，还是对一套机制的理解？我的体会是，只要创建过几台服务器的账户，useradd 的参数你早晚能背下来，但真正拉开差距的，是你是否理解创建时系统触碰了哪些配置、这些配置之间如何关联，以及出问题时该去哪一层查。
我在实际生产中一直坚持几个原则：
第一，所有用户创建的初始密码必须强制首次登录修改。用 chage -d 0 加 chpasswd 批量处理，比手工通知“你的密码是 xxx，赶紧改”要安全得多。
第二，用户主组尽量保持默认（同名组），不多改不乱改。如果需要让用户访问多个资源场景，用附加组而不是改主组。这条规则能避免大量文件属组混乱的问题。
第三，能通过组控制权限的，就不要逐用户设置权限。团队规模一大，逐用户授权等于给自己挖坑。哪怕是临时工、外包人员，也先建组再加人，职责清晰，离职移除也方便。
第四，生产环境 sshd 配置改动必须留退路。要么开多一个 root 会话，要么确认允许密钥登录的另一个用户或组可用。等出问题再想修复，往往已经来不及了。
用户和组的创建机制说难不难，说简单也不简单。它像是 Linux 权限世界的入口，跨过这扇门，你后面接触的 sudoers 精细化授权、PAM 多因子认证、ACL 扩展权限、SELinux 强制访问控制都会更容易理解。希望这篇梳理能帮你在“创建用户”这条常见操作上，建立起更系统的认知。