4、Linux用户与组管理：用户管理命令、组管理命令、用户配置文件、密码策略、sudo权限配置
说实话，Linux的用户和组管理，是运维的「地基活」。
我见过不少新手，一上来就喜欢用root干所有事。嗯，图省事嘛，我理解。但你要是在生产环境也这么干，那离「删库跑路」就不远了。我自己刚入行那会儿，就因为权限没分清楚，把一个测试环境的日志目录给清空了，还好只是测试环境，不然真得卷铺盖走人。
所以，这一章咱们把用户和组管理这块彻底捋清楚。你想想看，一个系统里几十上百个账号，谁该干什么，不该干什么，都得靠这些规则来约束。
4.1 用户管理命令：增删改查
用户管理，说白了就是四个字：增、删、改、查。Linux里对应的命令也很直观。
4.1.1 创建用户：useradd
useradd 是创建用户的命令。但我个人习惯，从来不用默认参数。为什么？因为默认创建的用户，家目录、shell、UID分配，都不一定符合你的预期。
我一般这么用：
# 创建一个指定家目录和shell的用户
useradd -m -d /home/devops -s /bin/bash devops
# 创建一个系统用户（UID小于1000，用于运行服务）
useradd -r -s /sbin/nologin myservice这里 -m 是创建家目录，-d 指定路径，-s 指定登录shell。对于跑服务的账号，我习惯用 -r 创建系统用户，并且不给它登录权限（/sbin/nologin）。
passwd devops 设置密码。不然用户没密码，等于白建。
4.1.2 修改用户：usermod
用户建好了，后面要改信息怎么办？用 usermod。这个命令的参数和 useradd 基本一致，只是动作变成了「修改」。
# 把用户加入附加组
usermod -aG wheel devops
# 锁定用户（不让登录）
usermod -L devops
# 解锁用户
usermod -U devops这里 -aG 是追加附加组，注意一定要带 -a，不然会覆盖用户原来的附加组。我曾经就犯过这个错，把一个用户的组给覆盖了，结果他连自己的文件都访问不了。
4.1.3 删除用户：userdel
删除用户很简单，但要注意清理痕迹。
# 删除用户，同时删除家目录和邮件池
userdel -r devops不加 -r 的话，用户虽然删了，但家目录还在磁盘上。时间长了，这些「僵尸目录」会越来越多。
4.1.4 查看用户：id、who、w
查用户信息，我常用这三个命令：
id devops：查看用户的UID、GID和所属组。who：查看当前谁登录了系统。w：比who更详细，还能看到他们在干什么。
4.2 组管理命令：groupadd、groupmod、groupdel
组管理比用户管理简单得多。记住一个原则：先建组，再建用户。这样在创建用户时就能直接指定主组。
# 创建组
groupadd devops_team
# 修改组名
groupmod -n devops_group devops_team
# 删除组（组内不能有用户作为主组）
groupdel devops_group4.3 用户配置文件：/etc/passwd 和 /etc/shadow
这两个文件，是用户管理的「命根子」。我建议你直接 cat 出来看看，比背命令参数管用多了。
4.3.1 /etc/passwd：用户账户信息
每一行代表一个用户，用冒号分隔成7个字段：
devops:x:1001:1001:DevOps Engineer:/home/devops:/bin/bash| 字段 | 含义 | 说明 |
|---|---|---|
| devops | 用户名 | 唯一标识 |
| x | 密码占位符 | 真正的密码在 /etc/shadow 里 |
| 1001 | UID | 用户ID，0是root，1-999是系统用户，1000+是普通用户 |
| 1001 | GID | 主组ID |
| DevOps Engineer | 描述信息 | 可以写全名或备注 |
| /home/devops | 家目录 | 用户登录后的默认目录 |
| /bin/bash | 登录Shell | /sbin/nologin 表示不能登录 |
4.3.2 /etc/shadow：密码与安全策略
这个文件只有root能读。它存储了加密后的密码和过期策略。
devops:$6$xyz...:18900:0:99999:7:30:19000:| 字段 | 含义 | 示例值 |
|---|---|---|
| devops | 用户名 | 与passwd对应 |
| $6$xyz... | 加密密码 | $6$ 表示SHA-512加密 |
| 18900 | 上次修改密码时间 | 从1970年1月1日算起的天数 |
| 0 | 最小修改间隔 | 0表示随时可改 |
| 99999 | 密码有效期 | 99999天，约273年，相当于永不过期 |
| 7 | 过期前警告天数 | 提前7天提醒用户改密码 |
| 30 | 宽限期 | 密码过期后30天内还能登录 |
| 19000 | 账户失效时间 | 到了这个时间，账户直接锁定 |
!! 或 *，表示该用户没有密码或被锁定，无法登录。
4.4 密码策略：chage 命令
光有密码还不够，你得让密码「过期」。不然员工离职了，密码还在，那就是安全隐患。
我一般用 chage 来设置密码策略：
# 查看用户的密码过期信息
chage -l devops
# 设置密码90天后过期
chage -M 90 devops
# 强制用户下次登录时修改密码
chage -d 0 devops-M 是最大有效期，-d 0 是把上次修改时间设为0，这样用户一登录就会被要求改密码。
chage -d 0，结果他当时正在用SSH连服务器，一执行完，他的连接直接断掉了。因为他下次登录必须改密码，但当前会话没给他改的机会。所以，千万别对远程连接中的用户执行 chage -d 0，除非你准备好去机房接显示器。
4.5 sudo权限配置：/etc/sudoers
sudo 是Linux里最实用的权限管理工具。它让普通用户能执行root命令，但又不用知道root密码。
配置文件是 /etc/sudoers，我建议你用 visudo 命令来编辑，因为它会帮你检查语法错误。要是直接 vi 改错了，sudo 就废了，那你就只能重启进单用户模式修复了。
4.5.1 基本语法
# 用户 主机名=(可切换的用户) 命令列表
devops ALL=(ALL) ALL
%wheel ALL=(ALL) ALLdevops：用户名，%wheel表示wheel组的所有成员。ALL：允许从任何主机执行。(ALL)：可以切换到任何用户。ALL：可以执行任何命令。
4.5.2 精细化授权
生产环境里，我从不给 ALL 权限。太危险了。我一般这样写：
# 允许devops用户执行systemctl管理服务，不需要密码
devops ALL=(root) NOPASSWD: /usr/bin/systemctl
# 允许ops组执行所有命令，但需要密码
%ops ALL=(ALL) ALL
# 允许backup用户只执行备份脚本
backup ALL=(root) /usr/local/bin/backup.shNOPASSWD: ALL。这等于把root密码告诉别人了。我见过有人图省事，给开发组配了免密sudo，结果有人手滑执行了 sudo rm -rf /，虽然现在系统有保护，但吓得够呛。
4.6 知识体系结构图
下面这张图，帮你把本章的知识点串起来：
嗯，这张图把用户管理、组管理、配置文件、密码策略和sudo权限串在了一起。你对照着图，再回头看上面的命令，思路会清晰很多。
公众号:蓝海资料掘金营，微信deep3321