企业官网建设流程全解析

接手一台新服务器，作为运维或者团队的“兼职网管”，第一件要做的事通常不是装数据库，也不是部署业务代码，而是先把这个服务器的多用户配置理清楚。尤其是团队里超过三个人要用同一台 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 人。这种情况下做多用户规划，我会这样分：

这个拓扑的核心思想是：人和人之间隔离，组和组之间有明确的权限边界，公共资源放在单独的共享目录里统一管理。这个设计不是拍脑袋想出来的，而是从一次线上事故倒逼出来的——之前有人把测试环境的大目录误删了，里面恰好有别人缓存的模型数据，整个组一下午没法干活。

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是“追加到附加组列表”的意思。如果不带-a，usermod -G会把用户原有所有附加组全部清掉，然后只保留你指定的组。我最初学的时候就在这里栽过跟头：执行完usermod -G dev zhangsan，发现该用户原来所在的shared组没了，导致访问不了共享目录。所以记住：加附加组，永远带-a。

批量处理多个用户时，直接用循环：

for user in zhangsan lisi wangwu; do useradd -m -s /bin/bash "$user" echo "创建用户 ${user} 完成： 初始密码设置为 2024@Temp，首次登录请修改" echo "$user:2024@Temp" | chpasswd usermod -aG dev "$user" done

使用chpasswd的好处是可以一次性从标准输入读取用户名:密码，这样写进脚本里很干净。但要注意：脚本里出现的明文密码，建议用完之后立刻改掉或者在注释中标注“临时密码”，避免后期变成安全隐患。

3.4 配置 sudo 提权与免密限制

多用户环境下，sudo 配置是敏感区。推荐用独立配置文件来管理某个组的权限，而不是直接改/etc/sudoers：

visudo -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 "zhangsan@company"

然后把公钥上传到服务器并追加到对应用户的authorized_keys：

ssh-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目录权限必须是 700，authorized_keys必须是 600，权限放太宽，SSH 服务会直接忽略这个文件，导致公钥登录不生效。这个细节我至少帮三个人排查过，都是权限问题。

在/etc/ssh/sshd_config里建议做这几项配置：

PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no AllowUsers zhangsan lisi wangwu MaxAuthTries 3

AllowUsers这个参数特别适合多用户服务器——它像一份“白名单”，只有名单里的用户名才能通过 SSH 登录。这样即使某个系统账号存在，也不会暴露在 SSH 端口上。改完配置后执行systemctl restart sshd，但要先确认当前会话连接正常再重启，别把自己锁在门外。

4. 权限精细化与资源管控

账号建好了，下一步就是权限和资源的精细化控制。很多人以为多用户配置到“每人一个账号”就结束了，其实这只是开始。

4.1 用 chmod/chown 控制文件读写执行

服务器上经常要共享代码目录、数据集目录。比较典型的一种场景：开发组在/data/project下维护代码，测试组只需要读。先建目录并设置属组：

mkdir -p /data/project chown root:dev /data/project chmod 750 /data/project

750分解为：属主可读写执行（7）、属组可读执行（5）、其他人无任何权限（0）。这样dev组的人能正常进入目录读写，其他组的人完全看不见。如果某个目录需要组内成员互相能看到对方新生成的文件，就按前面提到的 setgid 思路配置：

chmod 2770 /data/project

4.2 ACL 实现“给某个用户单独开某个目录权限”

有些场景下，组权限不够用。比如某目录属组是dev，但我想额外给测试人员wangwu一个只读权限，又不想把wangwu加进dev组。这时用 ACL：

setfacl -m u:wangwu:r /data/project

查看 ACL 设置：

getfacl /data/project

ACL 生效后，目录的权限位会多出一个+，比如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 1024

nproc是进程数（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 TMOUT=1800

表示 30 分钟无操作自动注销。系统级设置则在/etc/profile.d/下新建一个脚本，比如timeout.sh，内容同上。还有一些情况是管理员需要强制移除某个用户的登录会话，可以这样做：

pkill -u zhangsan

这个命令会杀掉该用户的所有进程，副作用的程度很大，最好确认没有人正在跑重要任务时再用。

5.3 登录日志与操作审计

多用户环境里的“背锅”矛盾，最终要靠日志来解决。Linux 登录相关日志：

• CentOS / RHEL：/var/log/secure
• Ubuntu / 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 用户名。因为这个用户的文件可能是其他人还在用的资源，盲删等于一起清理。我建议的顺序是：

1. 先禁用登录：usermod -L zhangsan锁定密码。
2. 改 SSH 权限：从/etc/ssh/sshd_config的AllowUsers里移除，或者直接移出相关组。
3. 归档数据：检查/home/zhangsan以及他所属项目目录下是否有还需要保留的文件，有的话先转移到公共账号（如backup）名下。
4. 最终清理：确认无损后，userdel -r zhangsan。

部分团队会有专门的交接检查单，但哪怕没有，这四步走一遍也足够了。

6. 常见问题与排查技巧实录

最后这部分，我把自己这些年做 Linux 多用户配置时碰到过的高频问题整理成了一份速查手册，每个问题都附上排查思路和解决方法。根据实际经验，这些问题远比你想象的更常见。

6.1 用户登录后提示：Permission denied（publickey）

这是公钥配置问题。排查顺序：

1. 确认公钥是不是真的写进了authorized_keys；
2. 确认家目录、.ssh目录、authorized_keys文件属主是不是该用户；
3. 确认权限是否符合要求（.ssh700，文件 600）；
4. 查看服务端日志（/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 zhangsan

df -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也随手看一眼。这花不了十秒，但能帮你在隔了很久之后复盘时，快速回忆起“这个账号是谁、什么时候开的、什么时候应该到期”。多用户配置看起来是个小项目，认真对待之后，它会成为整个服务器运维体系里最稳的一块基石。