1. 初识Linux的多用户体系为什么每个文件都得有个主人1.1 用宿舍公用电脑理解Linux的多人协作模型很多零基础的朋友第一次接触Linux印象最深的就是那个黑底白字的终端敲几条命令就能操控一切于是天然地以为Linux就是一台单机系统只有一个超级管理员在操作。但真实场景往往完全相反——你公司那台跑着业务系统的Linux服务器同时可能有七八个人在上面工作运维在改Nginx配置开发在跑测试脚本DBA在查数据库日志还有一台监控机器每天定时登进来拉取指标。这就产生了一个核心问题这么多人都在同一台机器上怎么区分文件是谁创建的谁有权限改什么谁误删了重要配置能追责Windows那种一个管理员若干标准用户的粗放模型在这里不够用Linux从一开始就设计成了多用户、多任务系统并且把一切皆文件的思想贯彻得很彻底——每个文件都有自己的属主owner和属组group而属主是谁、属组是什么、权限位怎么设置这三个信息直接决定了谁能读、谁能写、谁能执行。我在刚开始带新人时最爱打一个比方Linux服务器就像一间公用宿舍文件是你的行李箱用户是你本人组是同一宿舍楼层的集合。行李箱上贴着你的名字属主也标着你是几楼的人属组门卫看这两个标签决定放不放你进。你修改自己行李箱里的东西没问题但想去翻别人的箱子或者想走进别的楼层区域就得看权限位给不给你开门。理解了这个模型后面所有关于用户和组管理的命令就都顺理成章了。1.2 身份三件套用户名、UID、家目录在Linux系统里一个用户除了名字之外还有三个绕不开的身份标识UID用户ID、GID主组ID和家目录home directory。先说UID这是系统内部真正用来识别用户的数字编号。你在命令行敲的一切命令最终提交给内核时内核认识的不是zhangsan这个字符串而是对应的UID。用户名只是给人看的标签UID才是内核的身份证号。系统里有个约定俗称的分段规则0是超级管理员root1-999部分发行版是1-499保留给系统服务使用比如sshd、nginx、mysql等进程运行时的身份普通用户则从1000开始分配。这个约定非常重要排错时你常会看到某个进程跑着跑着就成了nobody用户那个nobody的UID通常是个很大的数这就是系统刻意为之——让没有特权的进程以低权限身份运行出了安全问题也影响有限。GID则代表用户所属的主组。每个用户必须属于至少一个组这个组就是他的主组。当你新建一个文件并设置默认属组时用的就是主组。Linux还允许一个用户同时加入多个附加组用来获得额外访问权限。家目录则是用户登录后的默认工作目录通常位于/home/用户名里面存放个人配置和文件。家目录的设计让多用户共用一台机器时每个人都有自己的私人空间互不干扰。这三者共同构成一个用户的完整身份。理解了这个三件套后面再操作useradd -u、useradd -g、useradd -d这些参数时就不会觉得是一堆随机的Flag了。1.3 查看自己是谁、别人是谁id与whoami实战在动手创建用户之前先掌握几个超高频的查看命令这些命令在笔试和面试题里出现的频率也不低。whoami只输出当前用户名简单粗暴。id输出完整身份信息包括UID、GID和附加组列表。cat /etc/passwd查看系统所有用户的注册信息。我强烈建议任何零基础学习者养成登录服务器后先敲一遍id的习惯。它会直接告诉你目前自己是以什么身份在操作这决定了你下一步命令敢不敢执行。比如下面这个输出$ id uid1000(zhangsan) gid1000(zhangsan) groups1000(zhangsan),10(wheel),1001(devops)看到uid1000说明zhangsan是个普通用户groups里既有自己的主组zhangsan也有附加组wheel和devops——wheel这个组在很多发行版里意味着可以sudo提权而devops则可能是某个项目目录的共享组。一条命令你的权限全貌就摊开了。再配合/etc/passwd文件来看每一行代表一个用户。初次接触这个文件内容会比较懵但别急下一章我会逐字段拆解这四个核心文件那是整个用户管理的地基。2. 用户和组到底是怎么登记造册的四大核心文件逐字段拆解2.1 /etc/passwd用户的主档案但密码不在这儿/etc/passwd是系统中最重要的用户信息文件之一每行对应一个用户用冒号分隔成七个字段。看到一个典型的行zhangsan:x:1000:1000:张三:/home/zhangsan:/bin/bash字段从左到右依次是用户名、密码占位符、UID、GID、注释信息GECOS、家目录、登录Shell。新手最容易产生误解的就是第二个字段那个x。这个x不是密码而是表示真正的密码存放在/etc/shadow文件里。这是历史演进的结果——早期Unix真的把加密后的密码放在这个文件里但该文件必须被所有程序读取因为要解析用户名和UID导致密码哈希对全场可读安全风险极大。后来才把密码挪到只有root能读的/etc/shadow中原来的位置用x占位。你在面试时如果能讲出这段演进逻辑会比单纯背字段名高一个段位。最后一个字段/bin/bash表示该用户可用的登录Shell。如果被改成/sbin/nologin或者/usr/sbin/nologin那么这个用户就无法通过SSH或终端登录系统。很多系统账号比如mysql、nginx的Shell都是nologin目的就是让服务以该身份运行但禁止人直接登录进去这是常见的安全加固手段。2.2 /etc/shadow真正的密码保险箱/etc/shadow是权限管理中的另一个核心普通用户完全无权读取只有root和shadow组可以。里面一行对应一个用户字段同样以冒号分隔我截取一个典型行来说明zhangsan:$6$c5Qr.../Uw2H$L0Jv...:19058:0:99999:7:30::这么多字段但常用的关键项其实就几个第一个字段用户名。第二个字段加密后的密码哈希。注意开头有$6$前缀这表示使用SHA-512算法加密$6$是SHA-512$1$是MD5$5$是SHA-256$y$是yescrypt。如果这个字段是!或*说明该用户没有可用密码或账户被锁定无法正常登录。第三个字段最后一次修改密码的时间单位是从1970年1月1日起的天数。第四个字段密码允许被修改的最小天数0表示随时可以改。第五个字段密码有效期天数99999表示默认不过期。第六个字段密码过期前多少天开始警告。第七个字段密码过期后的宽限天数超期后账户会被锁定。这个文件在实战中的用途很大。比如你接手一台老服务器用户反映密码是对的但就是登不上打开/etc/shadow一看第七个字段是0或者密码过期天数已经过去了问题立刻清楚。chage命令的所有操作本质上都是在改这些字段后面我会专门讲。2.3 /etc/group与/etc/gshadow组也有自己的档案组信息记录在/etc/group中行的格式比用户文件简单devops:x:1001:zhangsan,lisi四个字段分别是组名、组密码占位符、GID、组成员列表逗号分隔的附加成员。而/etc/gshadow则存放组的密码和组管理员信息一般很少直接编辑日常操作更多通过gpasswd命令进行。很多人会混淆主组和附加组的概念我这里用一个实际场景说透你创建用户时指定的组是主组通常与用户名同名后来你把zhangsan加进了devops组这个就是附加组。zhangsan创建新文件时文件的属组默认是主组但他如果想访问某个目录而该目录的属组恰好是devops且权限组可读那他就能以devops成员身份访问。一个用户可以属于多个组但主组只有一个。2.4 一次看懂属主、属组和rwx权限位用户和组的最终归宿都会落到文件权限上。用ls -l看任意文件时开头的那一串字符像-rw-r--r--前10个字符的含义是第1个字符文件类型-普通文件d目录l符号链接等第2~4个字符属主owner的读、写、执行权限第5~7个字符属组group的读、写、执行权限第8~10个字符其他用户others的读、写、执行权限。读用r表示值为4写用w表示值为2执行用x表示值为1。所以rwx对应数字7r-x对应数字5。这就是chmod 755、chmod 640之类命令的由来。零基础朋友常在这里卡壳为什么我把自己创建的脚本设置成755别人还是说不能执行多半是脚本所在目录的权限不对或者文件属主、属组认错了。目录的x权限代表能否进入该目录r权限代表能否列出目录内容w代表能否在该目录内创建删除文件。如果目录没给x就算文件本身是755其他人也进不去更谈不上执行。这个细节在项目部署时特别容易踩坑。3. useradd创建一整个用户生态参数背后的诞生流程3.1 创建用户的完整默认行为当你执行useradd zhangsan时系统到底做了什么很多人以为只是往/etc/passwd里加了一行但实际远不止如此。拆开来看至少包括在/etc/passwd末尾追加一条用户记录自动分配下一个可用的普通UID在/etc/group中创建同名组取决于发行版策略并把该用户的主组设为这个组在/etc/shadow中添加对应条目但此时密码字段是!意味着账户尚未激活不能登录复制/etc/skel目录下的所有隐藏文件到新家目录前提是创建了家目录。这里有个关键点不同发行版的useradd默认行为不一样。在CentOS/RHEL上执行useradd zhangsan会自动创建/home/zhangsan而在Debian/Ubuntu上同样的命令可能不会创建家目录必须加上-m参数才会生成。我在工作中见过太多跨发行版操作翻车的案例——在CentOS上习惯了直接useradd换到Ubuntu上创建完用户发现没有家目录SSH登录直接报错。所以如果你不确定当前系统的默认策略最稳妥的写法是显式带上参数。3.2 最常用参数组合新手记不住一堆参数没关系先掌握下面这几个最核心的基本能覆盖90%的日常需求参数含义示例-m创建家目录默认复制/etc/skel内容useradd -m zhangsan-d指定家目录路径useradd -m -d /data/www zhangsan-s指定登录Shelluseradd -m -s /bin/bash zhangsan-u指定UIDuseradd -m -u 2000 zhangsan-g指定主组useradd -m -g devops zhangsan-G指定附加组多个用逗号分隔useradd -m -G devops,wheel zhangsan-c添加注释信息一般写姓名或用途useradd -m -c 张三-测试账号 zhangsan-e指定账户过期日期格式YYYY-MM-DDuseradd -m -e 2025-12-31 zhangsan一个完整且规范的创建命令大概长这样useradd -m -d /home/zhangsan -s /bin/bash -u 1005 -G devops,wheel -c 张三 研发部 zhangsan然后马上设置密码passwd zhangsan为什么我建议显式写-m和-d因为可重复、可预期。团队协作时别人看你的命令就能反推用户配置而不是靠猜发行版的默认策略。生产环境里最怕看起来差不多的操作一旦行为与预期不符排查成本极高。3.3 命令执行成功之后一定要检查什么useradd执行完并不会打印太多信息失败也不会有明显提示所以养成检查习惯特别重要。我自己的检查清单是# 1. 查看用户是否创建成功、UID/GID是否正确 id zhangsan # 2. 查看家目录中的初始文件是否生成 ls -la /home/zhangsan/ # 3. 确认能否正常切换用户并进入家目录 su - zhangsan # 4. 检查/etc/passwd、/etc/shadow、/etc/group三处记录 grep zhangsan /etc/passwd /etc/shadow /etc/group这里尤其要提一下第2步。只有/home/zhangsan中存在.bashrc、.bash_profile这类文件用户登录后的Shell环境才完整。如果发现家目录空空如也要么是/etc/skel被清过了要么是创建时没有加-m。遇到后者可以用一条命令补齐cp -r /etc/skel/ /home/zhangsan/ chown -R zhangsan:zhangsan /home/zhangsan/ chmod 700 /home/zhangsan/很多老运维对家目录权限有强迫症就是因为目录权限过松比如755其他用户就能直接进入并读取里面的配置文件这是比较初级但很常见的信息泄露点。3.4 新用户默认环境/etc/skel的妙用/etc/skel目录是创建用户时的模板目录里面放的隐藏文件会被复制到每个新用户的家目录中。它除了包含.bashrc、.bash_profile这些Shell配置外你还可以自定义。例如你们公司的开发规范要求所有人登录后自动加载某个环境变量就可以在/etc/skel/.bashrc末尾追加一行source /etc/profile.d/myenv.sh那么此后创建的所有用户都会自动继承。这个思路特别适合批量创建测试账号或给新入职同事开账号的场景——一次配置、永久生效比挨个改家目录高效得多。但要注意一个坑/etc/skel只对之后创建的新用户生效对已经存在的用户没有任何影响。如果想把配置推送给存量用户还得另外写脚本批量处理。4. 密码策略与身份切换passwd、chage与sudo配置4.1 passwd命令的几种用法与常见报错创建用户后的第一件事通常是设置密码。passwd命令的使用场景很丰富# 交互式设置密码最常用 passwd zhangsan # 用管道方式批量设置密码脚本里好用 echo NewPassw0rd! | passwd --stdin zhangsan # 锁定密码禁止用户登录 passwd -l zhangsan # 解锁密码 passwd -u zhangsan # 查看用户的密码状态 passwd -S zhangsan这里有个小细节--stdin参数在CentOS上可用但在Debian/Ubuntu上并不支持会提示选项不存在。跨发行版写自动化脚本时要么用chpasswd命令要么写成这样echo zhangsan:NewPassw0rd! | chpasswd这个命令在各大发行版上表现一致是我在写用户初始化脚本时的首选。另外要提醒的是普通用户修改自己的密码时必须先输入旧密码而且新密码通常要满足一定复杂度最短长度、包含字符类型等。如果你在配置密码策略时把要求调得过高用户就会频繁遇到Bad password报错。实际项目里我一般建议密码最少12位并包含大小写字母和数字passwd默认的复杂度和长度限制在某些发行版上并不够强需要配合chage和PAM统一控制。4.2 chage管理密码过期和账户有效期chage是很多人容易忽略但极其重要的命令它直接操控/etc/shadow里的密码时间字段。几个高频用法# 查看密码策略 chage -l zhangsan # 设置密码90天后过期 chage -M 90 zhangsan # 密码最少使用7天才能修改 chage -m 7 zhangsan # 密码过期前7天开始警告 chage -W 7 zhangsan # 设置账户在某个日期后过期 chage -E 2025-12-31 zhangsan # 强制用户下次登录时修改密码 chage -d 0 zhangsan最后一个chage -d 0在创建临时账号时非常好用管理员设置一个初始密码用户首次登录就被强制要求改掉改完之前什么都干不了。这避免了初始密码可能被中途看到的风险。根据我的经验很多团队管用户密码的策略是定了但没落地密码永不过期、账号从不清理。直到某天内部审计时发现半年前离职的同事账号还能正常登录才一阵后怕。所以建议在给运维同事开账号时顺手就执行一条chage -M 90把密码过期机制先定好。这个习惯能省掉后面大量安全整改的麻烦。4.3 将普通用户放进sudo白名单visudo与wheel组用户创建好了密码也设好了但绝大多数情况下他并不能直接执行管理命令因为普通用户执行systemctl restart nginx会得到一堆Permission denied。怎么办两种思路。第一种是切换到root用户再操作即su -。第二种更推荐也是现代运维的主流做法——用sudo给普通用户授权让他以自己的身份执行特定管理命令。sudo的好处是不需要把root密码告诉任何人可以精确到只允许运行某几条命令并且所有操作都会记录在/var/log/secure或/var/log/auth.log中审计链路完整。在CentOS/RHEL中一般把用户加进wheel组usermod -aG wheel zhangsan在Debian/Ubuntu中则是sudo组usermod -aG sudo zhangsan如果想更精细地控制比如只允许他重启Nginx而不允许其他操作就编辑/etc/sudoers必须用visudo命令打开因为这个文件语法一旦写错sudo将全部瘫痪修复极其痛苦visudo在文件底部追加zhangsan ALL(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx语法含义是zhangsan可以在任何主机上(ALL)以任何用户身份(ALL)执行后面列出的命令。注意命令必须写绝对路径可以用which systemctl查看。有的同事会问能不能让他执行restart nginx而不需要密码可以加一个NOPASSWD关键字zhangsan ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx但生产环境我不建议随便给NOPASSWD尤其是权限范围覆盖系统所有命令的时候。比较稳妥的做法是让用户用sudo时输入自己的密码确认一次既防呆也留痕。4.4 su和sudo的边界感这两个命令经常被放在一起比较也是面试高频题。简单来说su是切换用户它会彻底切换成目标用户身份需要输入目标用户的密码sudo是以其他用户身份执行某条命令需要输入当前用户自己的密码前提是有授权。企业里最忌讳的就是把root密码到处发然后让大家用su -切过去操作。只要一个人手滑整个系统的安全边界就崩了。我见过一次翻车现场某同事用su -登上root后忘记退出直接在终端里误敲了一个清空日志目录的命令等发现时已经晚了。理论上sudo也有误操作的风险但它的审计日志至少能帮你定位是谁干的。从这个角度说sudo不只是权限工具更是一道安全防线。5. 组管理的实用操作groupadd、gpasswd与用户信息修改5.1 用组来组织权限groupadd与gpasswd组管理并不复杂几个高频命令就能应对绝大多数场景# 创建新组 groupadd devops # 指定GID创建组 groupadd -g 2000 devops # 把用户加入组-a表示追加-G指定组 gpasswd -a zhangsan devops # 把多个用户一次性加入组 gpasswd -M zhangsan,lisi,wangwu devops # 从组中移除用户 gpasswd -d zhangsan devops # 删除空组 groupdel devops使用gpasswd -a把用户加入附加组后有一个细节很多人会踩坑该用户当前已经登录的会话并不会立即获得新组权限。他必须重新登录或者执行newgrp devops重新加载组信息否则依然打不开那些组可读的文件。我当年第一次实操时加完组就在当前终端里反复测试权限一直不通还以为是组配置坏了直到退出重登才恍然大悟。5.2 newgrp临时切换主组的保底方案某些场景下你希望用户创建一个文件时文件的属组是某一个特定组而不是他的主组。最简单的方法是newgrpnewgrp devops这个命令会开启一个新的Shell并把你的有效GID临时切换为devops此后创建的文件的属组就变成devops了。退出后恢复原状。它本质上是重新登录的一种轻量替代方案。为什么会有这种需求举个真实例子项目组有一个共享目录/data/backend属组是devops权限27502是setgid位750是属主rwx、属组r-x、其他无权限。组内成员都希望在这个目录下新建文件能自动继承devops组而不必每次都手动chgrp。只要目录设置了setgid位新文件的属组默认就归到目录的属组。这就是典型的组管理目录权限配合场景。你如果再看不懂这类为什么我创建的文件自动属于XX组了的问题回头看这个机制就明白了。5.3 usermod修改用户的综合入口用户创建后经常要调整信息。usermod就是为此而生的大全套# 修改注释信息 usermod -c 张三-项目临时账号 zhangsan # 修改家目录注意需要配合移动旧家目录 usermod -d /data/zhangsan -m zhangsan # 修改登录Shell usermod -s /sbin/nologin zhangsan # 修改UID usermod -u 2000 zhangsan # 修改主组 usermod -g devops zhangsan # 追加附加组不加-a会覆盖之前的附加组务必小心 usermod -aG wheel zhangsan # 锁定账户等价于在/etc/shadow密码前加! usermod -L zhangsan # 解锁账户 usermod -U zhangsan这里最危险的是usermod -G不带-a的情况。比如我之前由于疏忽执行了usermod -G wheel zhangsan本意是把zhangsan加进wheel组结果他原本的devops组被覆盖掉了而他对共享目录的访问突然全断了。这类问题不报错、不提示看起来一切正常只有实际权限测试时才会暴露。所以不管在文档还是在文章里我都反复强调追加附加组务必写-aG。5.4 删除用户userdel -r是首选删除用户的命令是userdel。它默认只是删除/etc/passwd中的记录不会动家目录和邮件文件。通常建议带走家目录和邮件一起删userdel -r zhangsan如果你不打算删家目录比如用户离职了但项目数据还要留又担心这个用户以后被重新创建可以只做锁定操作。我个人主张能锁就不删、要删加-r——锁定一个账号成本极低恢复也方便一旦userdel -r下去用户文件和家目录彻底没了想找回就难了。顺带提醒一个安全点删除用户时如果该用户组成了某个文件/目录的属主且这个文件不在他的家目录里比如他往/data/里写过东西userdel -r并不会顺带处理这些文件。删除后会看到这类目录的属主变成了一个数字UID类似1005而不是具体用户名。如果这些文件不重要可以不用管如果很重要建议先把文件chown给其他用户再删。6. 面试高频题与运维现场的避坑清单6.1 六个高频笔试/面试问题的答题思路基于标题场景和实际面试情况我把最常出现的六个问题整理成一个速查表每个问题都附上结合项目怎么答的思路问题答题要点Linux用户创建后如何设置密码passwd 用户名或echo 密码 | passwd --stdin 用户名跨发行版可用chpasswd如何查看一个用户属于哪些组id 用户名、groups 用户名、grep 用户名 /etc/group如何禁止某用户登录系统锁密码passwd -l、改Shell为/sbin/nologin、设账户过期usermod -e如何强制用户下次登录时修改密码chage -d 0 用户名su和sudo的区别su需要目标用户密码且完全切换身份sudo需要当前用户密码并有授权配置操作留审计如何批量创建100个用户写脚本循环执行useradd、chpasswd配合/etc/skel做统一环境这里特别提醒一点回答禁止用户登录时最好把锁定密码和更换Shell的区别讲清楚passwd -l只是让密码失效但用户如果之前配置了SSH公钥认证他依然可以直接用密钥登录而usermod -s /sbin/nologin从Shell层面封死了登录通道更彻底。大多数情况下要双管齐下。6.2 新手最容易踩的四个坑**坑一创建用户后忘记设密码或者设了密码但账户被锁定。**新用户无法SSH登录排查时先看/etc/shadow里密码字段是否还是!。**坑二家目录权限不对。**家目录权限被设成755或者777系统会拒绝使用该家目录很多SSH服务配置了StrictModes检查日志里明确提示bad ownership or modes。标准做法是chmod 700 ~。**坑三用户已存在但重新执行useradd。**会提示useradd: user zhangsan already exists。要么改用usermod要么用userdel删除后重建。**坑四改完Shell后用户无法登录。**比如把某个用户的Shell改成了/bin/false或/sbin/nologin后该用户确实登录不了了但如果这个用户是某个服务账号比如运行中的进程服务就可能因此起不来。改之前要想清楚这个用户是否承担着服务运行职责。6.3 运维日常的检查清单建议收藏在实际管理多台Linux服务器多年后我总结了一套用户和组管理的例行检查清单不一定全面但覆盖了90%的日常需求每季度审计一次服务器上是否存在陈旧账号无登录记录超过90天的账户重点排查。所有运维同事的账号必须加入sudo审计范围禁止共享root密码。离职员工的账号应在24小时内锁定定期批量执行usermod -L处理长期闲置账号。配置SSH禁止root直接登录PermitRootLogin no改用普通用户sudo。新用户创建统一走脚本模板并强制要求首登改密chage -d 0。共享项目目录设置setgid位chmod 2775保证新建文件自动继承组权限。这套清单的价值在于它不是某一条命令的速查而是一整套围绕用户和组管理的工作习惯。零基础朋友刚接触时可能觉得知道命令就够了实际上把用户管理嵌入日常巡检流程才是从会用命令到能管系统的分水岭。我见过太多初级运维整天忙着救火根源就是缺少这样一套预防性机制。写到这里我又想起早年间在一台生产服务器上排查问题的经历业务反馈某目录下的文件突然无法上传了第一反应是看磁盘空间结果没满再看权限发现上传脚本所用的www用户早已不在www-data组里——原来有人误操作usermod覆盖了附加组。那次之后我在所有涉及usermod -G的命令前都养成了先备份/etc/group的习惯。所以这篇文章最后想多说一句用户和组管理的核心并不在于记住多少参数而在于每次操作前想清楚这个用户/这个组到底承担着什么职责我的改动会影响谁然后动手前多做一步检查和备份。Linux给了你强大的权限控制能力但也要求你用足够的敬畏去使用它。