接手一台新服务器作为运维或者团队的“兼职网管”第一件要做的事通常不是装数据库也不是部署业务代码而是先把这个服务器的多用户配置理清楚。尤其是团队里超过三个人要用同一台 Linux 服务器跑实验、部署服务、传文件的时候混乱的账号管理很快就会演变成一场灾难有人不知道自己的家目录在哪有人随手rm -rf清了别人一天的产出还有人因为共用 root 导致一不小心把生产环境弄崩了。Linux 服务器的多用户配置说白了就是用一套清晰的规则和命令让多个人安全、高效、互不干扰地共享一台机器。这篇博文我想从头到尾拆解一遍从底层概念讲起到实际建用户、配权限、做安全加固再到日常运维中我踩过的一些坑和排查思路。内容会比较干但每一个命令都是我实际在服务器上敲过、验证过的适合刚接触服务器运维的新手也适合想把手头“能用但混乱”的服务器重新规整一遍的小伙伴参考。1. 整体设计与思路拆解先把话说在前面Linux 多用户配置这件事最开始的规划决定了后面三个月你省不省心。很多新手拿到一台服务器第一反应是“我先用 root 把环境装好”然后让所有人共享 root 密码。这种做法短期看省事长期看就是在给自己埋雷。root 之间没有区分度出事之后你连是谁干的都查不出来而且任何一个人误操作整个系统都要跟着遭殃。1.1 先明确多用户体系的三个底层概念搞 Linux 多用户配置绕不开三个词UID/GID、家目录、登录 Shell。UID 是用户的唯一数字标识root 的 UID 永远是 0普通用户一般从 1000 开始分配。系统认的是 UID 而不是用户名这就是为什么你删除用户重建同名用户时原来那个用户遗留的文件可能会变成“无主”状态。GID 是用户所属组的标识用户至少属于一个主组还可以加入若干个附加组。组的核心作用是让权限管理有“批次”的概念不用一个用户一个用户地设权限。家目录是用户登录后的默认工作目录比如/home/zhangsan。不同用户的家目录互相隔离这是 Linux 多用户最基本的“地盘”划分。登录 Shell 决定用户进入系统后能使用哪些命令环境通常用/bin/bash但如果是给一个只需要跑脚本的服务账号完全可以设置成/usr/sbin/nologin让它根本没有登录能力。理解了这三个概念再来看多用户配置其实就是一个“分地盘 立规矩”的过程。1.2 为什么推荐“最小权限 按角色建组”而不是共用 root我在实际项目中试过两种路线。一种是把 root 密码告诉所有人谁要用就su -切过去另一种是每个人有自己的账号需要管理员权限时用sudo临时提权。前者的体验确实“省事”但代价是审计日志形同虚设所有操作都显示 root出问题无法回溯到具体的人误操作会直接作用到全局删一个目录、改一个配置就是整个系统的故障root 密码的传播范围越大被碰撞、被泄露的概率就越高。而走“每人一个账号 sudo 授权”的路线每个操作都能在/var/log/secure或auth.log里找到对应的用户记录谁执行了哪个命令一清二楚。授权范围也完全可以控制到“只允许重启某个服务、只允许编辑某个配置文件”这个粒度。这就是我在规划多用户方案时坚持的第一原则账号是人人的权限按需给root 禁止直登。1.3 按项目分组的适用场景与典型拓扑我经手过的一个典型场景一台 16 核 64G 内存的云服务器跑着两个测试环境和一个内部工具站。团队里有后端开发 4 人、前端 2 人、测试 2 人。这种情况下做多用户规划我会这样分用户组成员家目录路径权限范围dev后端开发/home/dev/下按用户名分子目录有部署目录、日志目录的读写权限frontend前端人员/home/front/下按用户名分子目录只允许访问构建产物目录test测试人员/home/test/下按用户名分子目录可以读日志、启动测试用例无写配置权限ops运维管理员/home/ops/下拥有 sudo 权限负责系统级维护这个拓扑的核心思想是人和人之间隔离组和组之间有明确的权限边界公共资源放在单独的共享目录里统一管理。这个设计不是拍脑袋想出来的而是从一次线上事故倒逼出来的——之前有人把测试环境的大目录误删了里面恰好有别人缓存的模型数据整个组一下午没法干活。2. 动手前的规划用户命名、目录结构与权限模型说实话大部分人在给服务器配多用户时根本不会想到写一段规划文档。但如果你是认真长期运营一台机器这步值得做。我说的“规划”不需要多复杂一张表格、几条约定就够了。2.1 账号命名和家目录规范账号命名我建议统一用小写拼音或英文名不要混用大小写也不要带特殊字符。比如zhangsan、lisi、wangwu。为什么因为 Linux 的命令行环境下大小写敏感一旦有人把ZhangSan和zhangsan当成两个账号后期脚本匹配会乱套。我见过有人用小写全名当用户名没什么问题就是敲命令时会多按几下 Tab。家目录我一般不会都放/home/下堆着而是按项目或按组分开。比如/home/deploy/ # 部署相关的用户目录 /home/project_a/ # 项目A的成员目录 /home/project_b/ # 项目B的成员目录这样做的直接好处是备份和迁移时按目录粒度处理非常方便。我给项目A做快照时tar打包/home/project_a就行不会牵扯到别的项目。2.2 共享目录和项目目录的权限设计服务器上多少都会有几个“大家都要用”的目录比如/data/shared、/opt/software、/srv/logs。对于这类公共目录最合适的权限方案是设置一个专门的共享用户组然后把需要访问的人都加入这个组。举个例子groupadd shared # 假设服务器 IP 是 10.10.8.149一般会在 /data 下建共享目录 mkdir -p /data/shared chown root:shared /data/shared chmod 2775 /data/shared重点在这个2775。数字 2 是设置 setgid 位意思是这个目录下新建的文件自动继承目录的属组shared而不是创建者自己的主组。没有这个 2用户 A 在共享目录下创建的文件组权限就可能变成 A 的私有组其他人就进不去了。这个细节是我实际运维中吃过亏的地方一开始没加 setgid结果组里每个人建完文件都要手动chgrp shared特别容易漏。2.3 明确用户权限的三个维度在真正敲命令之前我习惯把权限模型想成三个维度文件权限读、写、执行用rwx表示对应chmod目录权限目录的读、写、执行含义完全不同。读是能列出目录内容写是能新建/删除条目注意删除目录里的文件需要目录的写权限而不是文件的写权限执行是能进入目录sudo 权限能执行哪些管理员命令可以细分到命令级别。这三个维度在实操中会交叉出现。比如某个开发同事抱怨“文件删不掉”检查了半天发现他是文件 owner 没有删除权限但其实是因为所在目录没有写权限。对新手来说chmod、chown这两个命令的语义要吃透。3. 实操从零开始搭建多用户环境规划做完了下面进入正题怎么在服务器上一步步把多用户配置落地。我以下面这台 Ubuntu 22.04 服务器为例CentOS/RHEL 系命令略有差异但思路一致。3.1 环境检查与基础准备登录服务器后先看一下当前用户和系统版本whoami cat /etc/os-release这几条命令帮我确认当前是不是 root、系统是什么发行版。接下来顺手把系统的用户列表看一眼cat /etc/passwd | grep -v nologin这个命令会列出所有能登录的用户。如果你发现里面有一些你不认识的账号比如games:x:5:60、lp:x:7:7这类不用太紧张它们大多是安装软件包时自动创建的系统账号并没有登录权限。真正需要留意的是带/bin/bash或/bin/sh的普通用户。注意/etc/passwd里的每个用户记录格式是用户名:x:UID:GID:描述信息:家目录:登录Shell。x 表示密码被加密存储到/etc/shadow实际内容不会明文出现在这里这是 Linux 标准做法。3.2 创建用户的标准流程创建用户最简单的方式是useradd -m -s /bin/bash -d /home/zhangsan zhangsan拆开解释一下-m自动创建家目录-s /bin/bash指定登录 Shell保证用户能正常交互-d /home/zhangsan手动指定家目录路径不写的话默认就是/home/zhangsan所以这个参数其实可省。创建好了用户名接着设置密码passwd zhangsan然后按提示输入两次密码。这里我要强调一个习惯第一次运维接手时务必把新用户的密码策略指出来——不要用纯数字、不要用生日、不要复用管理员的密码。虽然 Linux 不会强制检查密码复杂度除非你装libpam-pwquality但密码安全这件事属于你不管就会出事的部分。如果是要给服务创建专用账号不需要登录权限那就这样useradd -M -s /usr/sbin/nologin git-service-M表示不创建家目录-s指定为 nologin这表示任何人都没法通过 SSH 或控制台登录成这个用户。它只会作为服务进程的运行身份存在。3.3 建立用户组并批量分配成员用户组的管理同样简单。创建组groupadd dev groupadd ops创建好用户之后把用户加到对应的附加组usermod -aG dev zhangsan这里的-aG是“追加到附加组列表”的意思。如果不带-ausermod -G会把用户原有所有附加组全部清掉然后只保留你指定的组。我最初学的时候就在这里栽过跟头执行完usermod -G dev zhangsan发现该用户原来所在的shared组没了导致访问不了共享目录。所以记住加附加组永远带-a。批量处理多个用户时直接用循环for user in zhangsan lisi wangwu; do useradd -m -s /bin/bash $user echo 创建用户 ${user} 完成 初始密码设置为 2024Temp首次登录请修改 echo $user:2024Temp | chpasswd usermod -aG dev $user done使用chpasswd的好处是可以一次性从标准输入读取用户名:密码这样写进脚本里很干净。但要注意脚本里出现的明文密码建议用完之后立刻改掉或者在注释中标注“临时密码”避免后期变成安全隐患。3.4 配置 sudo 提权与免密限制多用户环境下sudo 配置是敏感区。推荐用独立配置文件来管理某个组的权限而不是直接改/etc/sudoersvisudo -f /etc/sudoers.d/dev-team在文件里写%dev ALL(ALL) ALL这表示dev组的所有用户都能执行任意命令但需要输入自己的密码。这样比直接给 root 密码可控得多——每一次提权都会记录到日志里。更精细一点的写法比如只允许重启特定服务%dev ALL(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx如果希望某些运维脚本在无人值守时不提示密码可以加NOPASSWD但要限制命令范围。我个人的建议是不需要 NOPASSWD 的场景尽量别加因为免密 sudo 等于在你的账号密码泄露的那一刻攻击者直接拿到 root 权限。提示visudo一定要用命令而不是vim /etc/sudoers直接改因为visudo会做语法校验写错格式的话会提示你修改后才保存避免把 sudoers 弄坏导致所有用户都无法提权。3.5 SSH 多用户配置与密钥管理多用户和 SSH 天然绑定在一起——绝大多数人登录服务器都是走 SSH而不是坐在主机前。SSH 的多用户配置最关键的有两块公钥登录和登录限制。先给用户创建密钥对这一步在用户自己的电脑上执行ssh-keygen -t ed25519 -C zhangsancompany然后把公钥上传到服务器并追加到对应用户的authorized_keysssh-copy-id zhangsan服务器IP如果没有ssh-copy-id也可以手动创建.ssh目录并追加公钥mkdir -p /home/zhangsan/.ssh echo ssh-ed25519 TODO公钥内容 /home/zhangsan/.ssh/authorized_keys chmod 700 /home/zhangsan/.ssh chmod 600 /home/zhangsan/.ssh/authorized_keys chown -R zhangsan:zhangsan /home/zhangsan/.ssh.ssh目录权限必须是 700authorized_keys必须是 600权限放太宽SSH 服务会直接忽略这个文件导致公钥登录不生效。这个细节我至少帮三个人排查过都是权限问题。在/etc/ssh/sshd_config里建议做这几项配置PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no AllowUsers zhangsan lisi wangwu MaxAuthTries 3AllowUsers这个参数特别适合多用户服务器——它像一份“白名单”只有名单里的用户名才能通过 SSH 登录。这样即使某个系统账号存在也不会暴露在 SSH 端口上。改完配置后执行systemctl restart sshd但要先确认当前会话连接正常再重启别把自己锁在门外。4. 权限精细化与资源管控账号建好了下一步就是权限和资源的精细化控制。很多人以为多用户配置到“每人一个账号”就结束了其实这只是开始。4.1 用 chmod/chown 控制文件读写执行服务器上经常要共享代码目录、数据集目录。比较典型的一种场景开发组在/data/project下维护代码测试组只需要读。先建目录并设置属组mkdir -p /data/project chown root:dev /data/project chmod 750 /data/project750分解为属主可读写执行7、属组可读执行5、其他人无任何权限0。这样dev组的人能正常进入目录读写其他组的人完全看不见。如果某个目录需要组内成员互相能看到对方新生成的文件就按前面提到的 setgid 思路配置chmod 2770 /data/project4.2 ACL 实现“给某个用户单独开某个目录权限”有些场景下组权限不够用。比如某目录属组是dev但我想额外给测试人员wangwu一个只读权限又不想把wangwu加进dev组。这时用 ACLsetfacl -m u:wangwu:r /data/project查看 ACL 设置getfacl /data/projectACL 生效后目录的权限位会多出一个比如drwxr-x---。这个加的权限会记录在文件系统的扩展属性里。备份时要注意有些备份工具不会自动保留 ACL导致恢复后 ACL 丢失我实际遇到过这个问题所以提醒一下。4.3 磁盘配额避免一个用户把磁盘塞满多用户服务器最大的问题之一就是“一个用户写了个死循环日志把磁盘打满了所有人一起宕机”。磁盘配额是 Linux 自带的限制机制但很多发行版默认没启用。要启用的话首先在/etc/fstab里给需要限制的分区加usrquota和grpquota挂载参数。比如挂载点是/home/dev/sdb1 /home ext4 defaults,usrquota,grpquota 0 0重新挂载并做配额检查mount -o remount /home quotacheck -cmug /home quotaon /home给用户zhangsan设置 10GB 软限制、12GB 硬限制edquota -u zhangsan进入编辑界面后按和 Tab 调整soft和hard列Disk quotas for user zhangsan (uid 1001): Filesystem blocks quota limit grace files quota limit grace /dev/sdb1 0 10485760 12582912 0 0 50000软限制可以让用户临时超过超过后有 grace 期限硬限制到了直接拒绝写入。配额体系的配置确实有点繁琐但放在生产服务器上非常值得。如果你不想折腾 quota还有一个轻量级替代方案——用systemd的 tmpfs 限制或者直接通过定时脚本监控磁盘占用超过阈值的用户单独提醒。但严格来说配额才是治本手段。4.4 限制进程数和 CPU 占用多用户服务器上另一个常见现象是某个用户的代码 fork 了一堆线程直接把整台服务器的 CPU 打满其他用户的请求全都卡住。Linux 的ulimit可以限制单用户的进程数。在/etc/security/limits.conf里加zhangsan soft nproc 512 zhangsan hard nproc 1024nproc是进程数process count。如果你用 systemd 管理用户会话也可以用systemd-system.conf里的UserTasksMax。同时配合nice命令把编译任务降低优先级nice -n 19 make -j8这样即使编译程序再猛也不会把交互性请求完全饿死。这些资源限制策略长期以来被不少运维认为是“可选配置”但真正经历过一次 CPU 被打挂、所有人 SSH 卡到连不上之后你会发现这就是刚需。5. 安全加固、审计与用户生命周期管理多用户配置不只是“能登录”安全加固和日常管理才是真正的考验。这部分内容比较杂我按“进来前、进来后、离开后”三个时间线来讲。5.1 密码过期与修改提醒用户长期不改密码是个大问题。Linux 里可以用chage来设置密码有效期chage -M 90 -W 7 zhangsan含义是90 天后密码必须修改提前 7 天提醒。查看用户的过期信息chage -l zhangsan如果想让用户首次登录时必须改密码可以这样passwd -e zhangsan执行后zhangsan下次 SSH 登录会被强制要求先修改密码。这个操作特别适合批量创建账号后发给同事用避免你把临时密码告诉他又忘了收回来。注意chage的很多信息记录在/etc/shadow的日期字段中直接编辑 shadow 文件风险很高最好不要手改用chage工具更安全。5.2 登录会话的超时与强制下线多用户服务器上一个用户 SSH 不断开挂在那里占着会话也算一种资源浪费。可以在用户的家目录.bashrc里加入export TMOUT1800表示 30 分钟无操作自动注销。系统级设置则在/etc/profile.d/下新建一个脚本比如timeout.sh内容同上。还有一些情况是管理员需要强制移除某个用户的登录会话可以这样做pkill -u zhangsan这个命令会杀掉该用户的所有进程副作用的程度很大最好确认没有人正在跑重要任务时再用。5.3 登录日志与操作审计多用户环境里的“背锅”矛盾最终要靠日志来解决。Linux 登录相关日志CentOS / RHEL/var/log/secureUbuntu / Debian/var/log/auth.log查看最近登录记录last -a查看所有用户的登录失败尝试grep Failed password /var/log/auth.log | tail -20更高效的做法是直接分析 SSH 登录失败的 IP 和次数。下面是我常用的一段命令grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -rn | head额外再推荐装一个auditd来做文件级别审计。配置/etc/audit/rules.d/audit.rules-w /etc/passwd -p wa -k identity -w /data/project -p wa -k project_modify然后重启服务。这样谁动过/etc/passwd、谁在/data/project目录里修改过文件都会被记录到审计日志里。虽然日常用不到但出了问题做回溯时这套东西能保命。5.4 用户离职或者交接时的处置流程用户离开团队后切忌直接userdel -r 用户名。因为这个用户的文件可能是其他人还在用的资源盲删等于一起清理。我建议的顺序是先禁用登录usermod -L zhangsan锁定密码。改 SSH 权限从/etc/ssh/sshd_config的AllowUsers里移除或者直接移出相关组。归档数据检查/home/zhangsan以及他所属项目目录下是否有还需要保留的文件有的话先转移到公共账号如backup名下。最终清理确认无损后userdel -r zhangsan。部分团队会有专门的交接检查单但哪怕没有这四步走一遍也足够了。6. 常见问题与排查技巧实录最后这部分我把自己这些年做 Linux 多用户配置时碰到过的高频问题整理成了一份速查手册每个问题都附上排查思路和解决方法。根据实际经验这些问题远比你想象的更常见。6.1 用户登录后提示Permission deniedpublickey这是公钥配置问题。排查顺序确认公钥是不是真的写进了authorized_keys确认家目录、.ssh目录、authorized_keys文件属主是不是该用户确认权限是否符合要求.ssh700文件 600查看服务端日志/var/log/auth.log或secure看 SSH 服务实际报的什么错。最常见的原因是权限过宽SSH 出于安全考虑直接拒绝加载公钥。6.2 sudo 提示xxx is not in the sudoers file这个提示是因为用户不在任何有 sudo 权限的组里或者你修改 sudoers 时把组写错了。解决方法usermod -aG sudo zhangsan # Ubuntu 的 sudo 组 usermod -aG wheel zhangsan # CentOS/RHEL 的 wheel 组改完让用户重新登录一下。如果连 root 的 sudoers 都有问题可以进单用户模式或者用另一台机器的 root 修复visudo。6.3 用户执行ls一片权限报错但明明在共享目录的组里这类问题的原因通常是用户在创建时已经属于这个组但当前登录会话没有刷新附加组信息。用户执行newgrp dev或者重新登录即可。如果刚把用户加进组但用户不重新登录就访问共享目录有大概率遇到权限不生效的情况——这不是服务器坏了是会话没更新。6.4 磁盘明明还有空间但用户写不进去可能的原因有三个方向目录权限不够、配额硬限制到达、inode 用尽。检查顺序df -h /home df -i /home quota -u zhangsandf -i查看 inode 使用率经常有人忽略这点。如果 inode 满了即使 df -h 显示还有几百 G你也写不进任何文件。6.5 用户创建了但 SSH 登录直接被拒这种情况看AllowUsers是否漏加了这个用户。SSH 服务配置里没有加入白名单哪怕密码正确也会在认证前被拒绝。另外也可以检查/etc/ssh/sshd_config中有没有DenyUsers之类参数和AllowUsers冲突。6.6 用户家目录权限问题导致的诡异现象比如用户登录后找不到之前的文件或者程序报错无法写入缓存。常见原因是家目录的属主并非该用户。检查并修复chown -R zhangsan:zhangsan /home/zhangsan chmod 700 /home/zhangsan如果家目录权限是 755其他用户虽然没有写权限但可以读配合一些场景也算安全隐患。大多数发行版默认创建家目录权限是 755建议改成 700 或 750。7. 多用户环境后续可以做哪些扩展写到这里该说的重点都说了。基于实际运维体验再顺手铺垫几个更进阶的方向如果你想把这套多用户体系再往上拔一层可以从这几个角度入手。配置LDAP 或 FreeIPA统一账号认证所有服务器共享一份用户数据库用户名密码一处维护、多处通用省去每台机器单独建账号的重复劳动。引入sudo 规则中心化将 sudoers 集中到配置管理工具比如 Ansible里统一分发避免每台服务器上规则不一致。对共享目录增加定时备份任务比如每天tar增量打包关键目录到独立磁盘或对象存储。如果你开始管理多台服务器配置管理工具几乎是必然选择。但即便是单台服务器把用户、权限、目录的设计文档化也会让后来接手的人少走很多弯路。我个人在实际操作中的体会是Linux 多用户配置这件事难的不是命令本身而是有没有一套让人“能预期”的规则。规则越清晰后期维护成本越低。上面这些经验是我在踩了不少坑之后沉淀下来的如果你正在规划自己团队服务器的账号体系不妨从用户分组和权限边界先下手把最基本的 root 直登禁掉你就已经比大多数混乱状态的服务器前进一大步了。最后再分享一个小技巧每次给新用户开完账号我都习惯把chage -l 用户名的输出截个图留底同时把历史登录记录last也随手看一眼。这花不了十秒但能帮你在隔了很久之后复盘时快速回忆起“这个账号是谁、什么时候开的、什么时候应该到期”。多用户配置看起来是个小项目认真对待之后它会成为整个服务器运维体系里最稳的一块基石。