用户与组管理服务器刚到手、新同事入职、老同事离职、测试环境需要开个新账号……作为开发或运维几乎每周都会跟用户与组管理打交道。这活儿看着简单但真要深究里面坑不少建了账号忘了加组、权限给多了被安全部门点名、批量处理时脚本写得不严谨把系统账号也改了。这些我都踩过。这篇文章就老老实实把我这几年在用户与组管理上的实操经验梳理一遍。没有教科书式的废话只有真实场景下怎么规划、怎么操作、出了问题怎么排查。适合刚接手服务器的新手也适合那些已经干过一阵子、想把自己的操作梳理得更规范的开发者。1. 先把用户与组的底层逻辑吃透1.1 用户分类与UID约定Linux系统里的用户不是铁板一块大致分成三类超级用户也就是rootUID固定为0。这个账号拥有系统上的一切权限能读任何文件、能删任何目录、能改任何配置。日常操作中我几乎不用root直接登录而是用sudo去执行需要临时提升权限的操作。这不只是习惯问题更是一条安全基线——直接以root身份敲命令一旦误操作比如把rm写错路径连反悔的余地都没有。系统用户UID通常落在1到999之间老一些的发行版是1到499。这类用户是给系统服务用的比如nginx运行会创建一个nginx用户sshd服务有sshd用户mysql有自己的mysql用户。服务以独立用户身份运行目的是隔离权限——某个服务被攻破攻击者拿到的只是一个受限用户的权限而不是整个系统的权限。普通用户UID从1000开始部分发行版从500开始。这才是真正给人类用的账号。每个普通用户有自己的家目录、自己的文件、自己的crontab相互之间默认看不到对方的私密文件。为什么要强调UID约定因为系统判断两个用户是否是同一个用户看的是UID而不是用户名。比如A用户名叫alice、UID为1001B用户名叫bob、UID也是1001虽然正常情况不会发生但误操作手动改文件时可能搞出来系统会认为这是同一个用户。所以手动编辑账户文件时UID冲突是绝对不能犯的错。我习惯在加入新用户前先看一下当前最大UID是多少避免覆盖冲突。1.2 四个核心账户文件逐一拆解用户与组管理的所有秘密都藏在四个纯文本文件里。很多人以为掌握了useradd、passwd这些命令就够了但真正到了排查问题、手工修复的时候还是得跟这些文件打交道。第一个是**/etc/passwd**存储所有用户的基本信息。每一行有七个字段alice:x:1001:1001:Alice Developer:/home/alice:/bin/bash从左到右依次是用户名、密码占位符真正的密码不在这、UID、主组GID、GECOS信息一般是用户全名或备注、家目录路径、登录Shell。注意这里的x表示密码已隐藏到shadow文件里如果看到某个用户这里不是x反而要警觉。第二个是**/etc/shadow**存储密码哈希和密码策略。这个文件只有root能看和改权限设置极其严格。字段包括上次修改密码时间、密码最短/最长有效期、密码过期前提醒天数、宽限期等。密码过期策略是很多公司安全合规里必须落实的一项后面我会单独讲。第三个是**/etc/group**存储组信息。字段同样有四个组名、组密码占位符组密码极少用到一般也是x、GID、附加成员列表逗号分隔的用户名。第四个是**/etc/gshadow**存储组密码和组管理员信息和shadow对应。实际工作中绝大多数项目的组密码都是锁定的不启用。组的管理员机制也几乎不用但知道有这个文件存在排查问题时至少不会一头雾水。这四个文件的对应关系简单说passwd和group描述有什么shadow和gshadow描述谁能进。1.3 组的作用与设计逻辑组解决的是一批人访问同一批资源的问题。你可以把组理解为现实中的部门——开发部的人能进开发机运维部的人能看监控后台。如果不用组就得逐个用户去授权新增一个用户就要给所有文件加一遍权限删除一个人还得全系统找它拥有过的文件这效率低到没法忍受。Linux的组分为主组初始组和附加组。主组在passwd里记录了GID一个用户只能有一个主组。用户创建文件时文件的所有组默认就是该用户的主组。附加组在group文件的最后字段里一个用户可以加入多个附加组以获得额外的资源访问权限。这里有个实践上的建议不要把两个重要项目放在同一个组里也不要让一个用户同时加入过多组。组越多权限重叠越复杂出问题时排查也越麻烦。我见过一台机器上用户加入了八九个组最后谁也说不清他到底能访问什么那已经到了必须治理的程度。2. 操练用户与组的增删改查全流程2.1 创建用户时那些容易忽略的参数很多人创建用户一个useradd加完可能就完事了。但实际生产中至少要考虑下面这些参数useradd -u 1500 -g dev -G docker,sudo -c Zhang Wei - Backend Developer -m -d /home/zhangwei -s /bin/bash zhangwei依次解释一下-u指定UID-g指定主组-G指定附加组-c写备注这个很有用以后排查时能一眼看出这个账号是谁的-m强制创建家目录-d指定家目录路径-s指定登录Shell。Shell的选择有个细节。如果这人只需要偶尔执行命令/bin/bash没问题如果只是为了跑服务或者只走跳板机登录/usr/sbin/nologin反而更安全——它会让该账号无法直接登录Shell避免被当作跳板进一步渗透。同理如果业务上需要这个账号能登录但不能交互式操作可以设置为/bin/false。-m这个参数很多人安装系统后会发现默认的useradd竟然不创建家目录取决于/etc/login.defs里的配置与发行版默认策略。所以我的习惯是显式指定-m不要依赖默认行为。没有家目录的用户尤其在它们需要自己安装软件或写脚本时会非常不方便。创建完用户后还要处理两件事设置初始密码、检查密码是否立即过期。echo InitialPassw0rd! | passwd --stdin zhangwei passwd -e zhangwei--stdin参数适合批量初始化场景第一次登录时强制改密码用-e这两行合起来能实现临时密码登录后必须自己修改的效果。2.2 修改和删除用户不留垃圾文件用户信息不是一成不变的。员工调岗了、改名了、换组了都需要动用户属性。usermod -g ops -G docker,dev zhangwei # 修改主组和附加组 usermod -d /data/newhome -m zhangwei # 搬家目录并迁移文件 usermod -L zhangwei # 锁定用户禁止登录 usermod -U zhangwei # 解锁用户这里最需要注意的是-G的语义。指定-G docker,dev时其实是把该用户的附加组替换成这组列表而不是追加进去。如果之前用户还在sudo组里没列进去就被悄悄移除了。正确做法是先看当前附加组groups zhangwei然后把需要保留的组一起写全。这个坑我曾见过不止一次——有人想给用户加个docker组结果一执行原来的sudo权限没了同事第二天发现自己连sudo都用不了。删除用户的命令是userdel但裸的userdel不会删除用户的家目录和邮件池至少在多数发行版上不会。务实的做法userdel -r zhangwei-r参数连带删除家目录和邮件池。但这里有个隐蔽问题如果用户在别处还有文件——比如/tmp下、共享目录里、或者其它以UID归属的文件——删除用户后这些文件会变成孤儿文件所有者显示为数字UID非常难清理。我的习惯是删用户之前先扫一遍归属find / -user zhangwei 2/dev/null确认没有需要保留的文件后再决定是归档还是直接删。离职人员的文件有时有审计价值直接删了后面查记录就麻烦了。2.3 组的管理与成员维护手段组的创建和删除相对简单但给组添加成员这个操作值得一提。很多教程会告诉你用usermod -G但还有一种更精细的方式针对单个组操作。groupadd ops groupmod -g 1501 ops groupdel ops # 前提该组不是任何用户的主组 gpasswd -a zhangwei ops # 往ops组里加人 gpasswd -d zhangwei ops # 从ops组里移除人 gpasswd -M zhangwei,lisi ops # 设置组成员列表覆盖式gpasswd -a和-d是细粒度操作不用像usermod那样把全部附加组列一遍。在批量治理组成员时我推荐在脚本里用gpasswd不容易误伤其它附加组。删除组的时候报错groupdel: cannot remove the primary group of user是最常见的。这意味着该组还是某用户的主组得先修改用户的-g切换到别的组再执行组删除。3. 实战场景批量创建、权限分配与账号治理3.1 批量创建用户的三种常见思路新系统上线或大批实习生入职时逐个敲useradd效率太低。批量创建用户通常有三种思路各有利弊。第一种是循环脚本适用于一次性初始化。#!/bin/bash # 批量创建用户每组用户名和备注放进users.txt # 格式用户名 全名 附加组 while read user fullname groups; do useradd -m -c $fullname -G $groups -s /bin/bash $user 2/dev/null echo Temp$(date %s) | passwd --stdin $user passwd -e $user done users.txt注意脚本里一定要做异常处理。比如用户名已存在、组不存在、磁盘空间不足导致家目录创建失败这些情况脚本默认会继续跑下去最后你得到一半成功一半失败的账还不好定位。加2/dev/null是因为useradd的报错信息不是每次都明确哪里出了问题但更严谨的做法是先检查再创建id $user /dev/null { echo 用户 $user 已存在; continue; }第二种是从模板文件复制。如果一堆用户的家目录都需要放同一个公共脚本、同一个bashrc配置可以先手动建好一个黄金模板家目录然后批量复制for user in $(cat users.txt); do useradd -m -k /etc/skel -s /bin/bash $user cp -r /data/template_home/. /home/$user/ chown -R $user:$user /home/$user done-k /etc/skel默认从骨架目录复制初始配置之后再用模板覆盖一遍能保证所有新用户有完全一致的初始环境。第三种是运维工具统一管理比如用Ansible等配置管理工具维护user模块。这种方式最规范所有账号、组、sudo规则都在配置仓库里改一处、同步全网。适合服务器数量多的团队比如几十台机器时要加一个新同事Ansible跑一遍playbook就能把该建的账号、该加的组、该配置的sudo统一完成不会出现某台机器漏掉的情况。3.2 sudo权限配置与最小权限账号建好之后下一步就是决定它能执行什么操作。直接给sudo权限太粗暴正确姿势是配置sudoers规则。sudoers文件的修改要用visudo命令它会做语法检查避免因为编辑错误导致sudo不可用。这是个很多人忽略的保命习惯——直接编辑/etc/sudoers一旦语法错误整个系统sudo功能全废要救回来非常麻烦。推荐的配置方式是新建一个独立文件放在/etc/sudoers.d/目录下# /etc/sudoers.d/ops-team %ops ALL(ALL) ALL %dev ALL(ALL) NOPASSWD:/usr/bin/systemctl zhangwei ALL(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx逐行解释%ops表示ops组里所有成员可以在一台机器上以任意用户身份执行任意命令%dev表示dev组能免密码执行systemctl但仅限这个命令本身不能切换到其他人执行任意命令最后一行是给具体用户授权只允许重启和查看nginx状态。minimal权限的原则就是给执行具体任务的权限不给人万能钥匙。实际工作中大量安全问题出在sudo权限过宽——给了ALL却不限定命令等同于把人变成了root。另外NOPASSWD要慎用。只有那些需要脚本自动化执行的、且本身权限已足够受限的命令才适合用免密。像systemctl restart某个服务这种操作脚本里经常用到但如果还允许NOPASSWD:ALL那就完全失控了。配置好之后测试一下权限sudo -l -U zhangwei这个命令能列出该用户在哪些机器上能以什么身份执行哪些命令。每次配置完都应该做一个校验。3.3 锁定、清理、离职账号处理的完整流程账号生命周期管理最容易被忽视的是离职账号处理。在真实企业里人的流动是常态如果离职账号不及时禁用和清理就是一个隐形的安全后门。一个完整的离职账号处理流程我通常是分四步走第一步锁定账号立即切断该用户的登录能力。usermod -L username注意usermod -L锁的是账号密码登录。如果该用户配置了SSH密钥登录锁定密码是挡不住密钥的。需要再检查一下它的authorized_keys把密钥也清掉rm -f /home/username/.ssh/authorized_keys或者更稳妥一点直接把家目录下的.ssh目录挪走做审计存档。第二步踢掉在线会话。账号就算锁了已登录的会话不会立刻断开。用pkill结束它的全部进程pkill -u username或者在需要保进程的场合把所有权转让给其他用户find /home/username -user username -exec chown newowner:newowner {} \;第三步审计归属文件。按前面说的扫描该用户所有文件区分哪些是重要业务数据、哪些是垃圾文件。重要数据交给部门负责人认领垃圾文件直接归档后统一清理。第四步批量自动化。服务器多了之后手动去每台机器锁账号、清密钥、删进程容易遗漏。写个脚本把离职人员列表作为输入遍历所有服务器的IP列表执行上面的操作。这台服务器上操作做完之后日志留一份后续审计有据可查。4. 常见故障与排错技巧实录4.1 用户和组管理中的典型错误与解法错误一创建用户提示useradd: user xxx exists这种情况不是坏了而是系统中已存在同名用户。先用id确认再用grep在passwd里查一下看是不是之前删用户没删干净。有些时候只是某个组名冲突提示的却是用户存在。两个都查一遍再继续操作。错误二用户无法登录报Users account has expired这是密码策略或账号有效期到期了。chage -l username # 查看账号有效期和密码策略如果确认账号不该过期用chage -E -1取消账号过期时间或者重新设置密码有效期。错误三执行sudo报xxx is not in the sudoers file90%的情况是用户不在sudo组里或者sudoers.d下的文件没加成功。先确认组成员groups username如果确实在sudo组里还报错看看/etc/sudoers里的sudo组权限行是否被注释掉。有些严格收敛的系统默认不带sudo组那条规则需要自己手动加。错误四用户创建文件后其他同组用户无法修改这涉及到umask和文件权限位。创建文件默认权限由umask决定root下通常是022普通用户是002或007取决于发行版设置和配置文件。如果希望同组用户默认可以写需要把用户的umask设置为002echo umask 002 /home/username/.bashrc实践中团队协作目录我一般不禁用ACL或setgid位来解决问题而是明确约定项目目录权限。错误五root密码忘了这是最经典的救援场景。单用户模式改密码的流程重启系统在grub启动界面按e编辑内核启动参数在linux开头那一行末尾加上single或init/bin/bash不同发行版略有差异然后按Ctrl-X或Ctrl-B引导进入单用户模式。在单用户模式下挂载根文件系统为可写状态mount -o remount,rw / passwd root然后重新启动。这个操作在物理机和虚拟机上都适用。但如果是云服务器建议先看服务商提供的一键重置密码功能避免误操作破坏系统启动。4.2 常见问题速查表现象可能原因快速诊断解决手段用户无法登录密码未设置或已过期passwd -S usernamepasswd username重设用户无法sudo不在sudo组或sudo规则缺失groups username、sudo -l -U usernameusermod -aG sudo username显示家目录不存在家目录被删或配置路径错误ls -l /home/username、grep username /etc/passwd重建或修改usermod -dUID冲突手动改passwd导致重复UIDawk -F: {print $3} /etc/passwd | sort -n | uniq -d改回唯一UID检查文件归属SSH登录公钥失效authorized_keys权限过宽或被替换ls -l ~/.ssh/authorized_keyschmod 600 ~/.ssh/authorized_keys批量脚本只成功一半用户已存在或组不存在tail /var/log/useradd.log脚本加前置检查分批重跑组删除失败仍是某用户主组awk -F: $4GID /etc/passwdusermod -g切换主组后删除4.3 安全加固与审计基线用户与组管理做得好不好最终要落在安全基线上。我在多台服务器上逐步沉淀出一套检查清单分享出来供参考。密码策略要落实在/etc/login.defs和shadow里。建议配置项密码最小长度12位以上密码最长使用周期90天最短修改间隔7天过期前7天开始提醒。# /etc/login.defs PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 7但这只是新创建用户时的默认值对存量用户可以用chage --maxdays 90 --mindays 7 --warndays 7 --all--all会应用到所有用户省去一个一个设置的麻烦。SSH方面建议直接关闭root密码登录。保留密钥登录即可这样即使密码泄露没有私钥也无法登录。做法是在/etc/ssh/sshd_config里设置PermitRootLogin prohibit-password此外禁用空密码用户awk -F: ($2){print $1} /etc/shadow如果这条命令有输出意味着存在不设密码的用户——正常业务下不应该出现这种情况。这类账号遇到没有限制的SSH配置就等于直接裸奔。用户定期审计也值得做。每个季度检查一次哪些账号超过30天没登录哪些账号没有设置密码哪些用户uid是0理论上只能有一个rootawk -F: ($30){print $1} /etc/passwd顺便检查一下sudoers文件里有没有可疑条目比如某个组被加了ALL(ALL) NOPASSWD:ALL这通常意味着特权被彻底放开了。最后一个小技巧如果担心批量操作出错先加一个bash -x执行一遍看输出再去掉-x正式跑。脚本上线的原则和改数据库前备份一样——先试跑、再小范围、最后全量。用户与组管理做得好的系统不声不响做得差的服务器处处埋雷。每次创建账号前多想一步这个账号将来要做什么、能做什么、不能做什么权限边界清晰了后面的安全省心很多。