企业官网建设流程全解析

刚接手一台 Linux 服务器，或者正在准备运维面试的人，几乎都会撞上同一个场景：团队里有人离职了，需要把他在服务器上的账号清掉；或者你自己在本地虚拟机里建了一堆测试用户，现在想把环境还原干净。这时候你敲下userdel，系统却提示userdel: user xxx is currently used by process；你切管理员账号执行su，又碰到su: authentication failure。问题看似小事，真正处理时却涉及用户删除的清理范围、密码策略、切换用户的各种细节，牵扯出来的知识点并不少。

这篇文章想讲透三件事：Linux 删除用户时到底删了什么、没删什么；用户密码如何安全地设置、修改和锁定；su切换用户和直接登录之间有什么区别，以及什么场景下更推荐用sudo。如果你之前只是背过userdel -r user1、passwd user1、su - root这几个命令，却不太清楚每条命令背后的行为边界，这篇文章值得读完再动手。

1. 这篇文章真正要解决的问题

Linux 用户管理是系统管理员的基本功，也是面试里出现频率很高的一个模块。很多初学者对用户管理的理解停留在“会敲命令”这个层面，但实际维护服务器时，真正的难点往往出现在命令的副作用上。

先说一个最常见的例子。执行userdel删除用户时，如果你只是简单敲了userdel zhangsan，那么这个用户的主目录、邮件池、临时文件可能仍然残留在系统里。第一次处理生产环境的人，很容易因为“命令执行成功”就认为清理完毕，结果是磁盘空间被历史文件慢慢占满，或者后续新建同名用户时，意外读到了上一个用户遗留的敏感文件。

再看密码管理。passwd命令看起来简单，但密码策略怎么设置、多久改一次、哪些用户不能登录但账号又必须保留，这些问题如果没想清楚，就会陷入“账号被锁，自己也进不去”的尴尬局面。很多线上事故，不是命令不会敲，而是对密码过期、账号锁定这些状态缺乏预判。

最后是切换用户。su和su -只差一个连字符，行为却完全不同。前者切换用户后保留当前环境变量，后者会加载目标用户的完整登录环境。如果你在一个脚本里用su切到别的用户执行任务，却发现自己拿到的 PATH 还是原来的，大概率就是少了这个连字符。

这篇文章适合三类读者：

• 正在学 Linux 基础、准备考证或找运维岗的初学者。
• 已经会在实体机或云服务器上建用户，但不确定删除和清理边界的人。
• 写自动化脚本时需要切换用户、设置密码、控制权限的开发者。

读完这篇文章，你应该能回答：删除一个用户时，哪些文件该删、哪些不该动；忘记密码时如何用 root 重置；su切换用户时环境变量发生了什么变化；以及怎么设计一个相对安全的用户管理流程。

2. 核心概念：用户、主目录、密码状态与切换机制

在写具体命令之前，先把概念理清楚。Linux 里所谓的“用户”，并不只是/etc/passwd文件里的一行记录。它至少包含几层数据：

很多面试题喜欢问：“/etc/passwd和/etc/shadow有什么区别？”其实简单说就是，/etc/passwd是所有用户可见的公开信息，里面不存真正的密码，而是放一个x占位；真正的密码哈希和密码策略放在只有 root 和 shadow 组可读的/etc/shadow里。理解这一点，你就明白为什么删除用户时不只要看某个文件，而要看用户涉及的全部数据。

2.1 用户的密码状态

passwd命令修改的不只是“密码字符串”，还包括密码的过期时间、最短修改间隔、警告时间、失效时间等信息。这些字段存在/etc/shadow中，冒号分隔。

Linux 密码状态有一个容易混淆的地方：/etc/shadow密码字段里，如果密码以!开头，通常表示账号被锁定；如果里是*，通常表示该用户不能直接密码登录，比如系统服务账号。很多初学者以为锁定账号是“改一下密码”，其实usermod -L或passwd -l才是标准做法。

2.2 su 与登录 Shell 的区别

su是“切换用户”的缩写（substitute user），它允许你从当前用户切换到另一个用户，前提是你知道目标用户的密码，或者当前你是 root 不需要密码。

su zhangsan的意思是“切换到 zhangsan，但保留当前 Shell 的大部分环境变量”；su - zhangsan的意思是“模拟 zhangsan 登录系统”，会重新加载/etc/profile、~/.bash_profile、~/.bashrc等登录环境文件。

从运维实践来看，绝大多数场景下应该优先使用su -，因为环境变量干净，能避免很多“命令找不到”或“执行环境不对”的问题。这个细节后面会专门演示。

3. 环境准备与前置条件

本文所有命令都在 Linux 系统上验证，操作系统发行版不限制。实际验证时，不推荐直接在只有一份环境的服务器上反复练习删除用户和切换用户，最容易出问题。

安全提醒：所有命令都应在自己有管理权限的测试环境或云服务器测试机上执行。不要在没有授权的情况下对他人系统执行用户操作。

我的建议是准备一台最小化的虚拟机，或者使用普通数据盘上的临时目录做演示，保证操作前有快照或备份。如果使用云服务器，可以提前创建快照。开一台 2C4G 的临时云主机，装 CentOS Stream 9 或 Ubuntu 22.04 LTS 都行，这套思路和命令在两套系统上的差异并不大。

需要准备的权限：

测试时建议使用 Trainee 账号，不要用 root 直接反复测试删除操作，避免误操作后系统状态不可逆。

4. 用户密码管理：从修改到策略控制

4.1 使用 passwd 修改用户密码

Linux 里修改用户密码最常用的是passwd命令。

# 修改当前登录用户自己的密码 passwd # 修改指定用户的密码，需要 root 权限 sudo passwd zhangsan

修改指定用户密码时，系统会提示输入新密码两次，默认要求密码有一定强度，比如不能太短、不能与用户名过于相似。若在脚本里需要非交互式设置密码，可以用chpasswd或管道方式。

# 非交互设置用户密码，适用脚本场景 echo "zhangsan:NewPass@123" | sudo chpasswd

执行chpasswd时，它的输入格式是用户名:密码，密码会经过加密处理后写入/etc/shadow。这种方式要注意的是，命令本身可能出现在 Shell 历史记录中，生产环境不建议直接在历史里暴露密码，更好的方法是把密码写入权限受限的文件中，再用重定向读取。

4.2 查看密码状态

查看用户密码的详细状态，可以执行：

sudo passwd -S zhangsan

输出结果类似于：

zhangsan P 01/01/2027 0 99999 7 -1

字段含义分别为：用户名、密码状态（P 表示有可用密码，L 表示锁定，NP 表示无密码）、最近修改日期、最少修改天数、最大修改天数、警告天数、不活跃天数。

如果想看/etc/shadow文件中的原始结构，可以执行：

sudo cat /etc/shadow | grep zhangsan

shadow 文件每一行由 9 个字段组成：

用户名:密码哈希:最近修改时间:最小修改天数:最大修改天数:警告天数:失效宽限天数:账号过期时间:保留字段

4.3 锁定与解锁用户

有些时候，用户密码不需要删除，只需要临时禁止登录。这种情况适合用锁定，而不是删除用户。

# 锁定用户 sudo passwd -l zhangsan # 解锁用户 sudo passwd -u zhangsan

锁定用户也会修改/etc/shadow中密码字段的结构，通常是在原有密码哈希前加!。这意味着锁定的本质不是把密码删除，而是让密码无法匹配。

4.4 强制用户下次登录时修改密码

新员工入职时，管理员可以先设置一个初始密码，然后强制员工首次登录后修改：

sudo chage -d 0 zhangsan

chage -d 0的意思是“将最近一次修改密码的时间设置为 1970 年”，这样系统会认为密码已经过期，强制用户下次登录时修改密码。

查看密码有效期：

sudo chage -l zhangsan

输出内容里会看到“密码过期时间”“密码失效时间”“帐户过期时间”等字段。管理密码不能只靠记命令，更要结合公司安全策略设置合理密码周期。

5. 删除用户：userdel 的完整行为边界

删除用户看起来是一个命令的事，但它清理数据的方式对系统后续影响很大。

5.1 基础删除：仅删除用户记录

sudo userdel zhangsan

这个命令会删除：

• /etc/passwd中的用户记录
• /etc/shadow中的密码记录
• /etc/group中只包含该用户的主组记录

但它不会删除：

• 用户的主目录/home/zhangsan
• 用户的邮件池/var/mail/zhangsan
• 用户的 crontab 定时任务
• 用户在其他目录下拥有的文件

这里就是很多初学者最容易踩的坑。命令执行成功后，你觉得用户没了，但/home/zhangsan目录可能还带着大量项目文件，如果后续有新人入职并被赋予zhangsan这个用户名，就会直接看到上一任用户遗留的数据。

5.2 删除用户并清理主目录和邮件池

sudo userdel -r zhangsan

-r参数会同时删除用户的主目录和邮件池。这个参数在测试环境很方便，但在生产环境必须非常谨慎。如果用户主目录下存在未备份的资料，删除后基本无法找回。

从稳健性考虑，推荐使用以下流程：

1. 先备份用户主目录和重要数据。
2. 再检查该用户是否还有进程在运行。
3. 确认无风险后，执行userdel -r。

5.3 处理“用户正在使用中”的错误

删除用户时，如果该用户有进程仍在运行，系统会提示：

userdel: user zhangsan is currently used by process 1234

这种情况不能强制删除后不管，正确的做法是先查看该用户的进程：

ps -u zhangsan

或者：

pgrep -u zhangsan

如果确认这些进程确实需要终止，可以执行kill，然后重新尝试userdel。

sudo pkill -u zhangsan sudo userdel -r zhangsan

注意：pkill -u zhangsan会杀掉该用户的所有进程，操作前必须先确认这些进程不是核心业务进程，否则可能造成服务中断。

5.4 删除用户前需要检查的几项

这些检查听起来繁琐，但真实线上操作比这更麻烦的情况很常见。比如一个用户因为写了个守护进程，即使执行了userdel，进程还在后台继续运行，直到重启系统后才发现文件被再次写入异常路径。提前检查总比事后排查更划算。

5.5 扩展对比：userdel 与 deluser

Debian/Ubuntu 系提供了deluser命令，它是一个更面向用户的命令，相比userdel有更友好的交互提示。如果服务器是 Ubuntu，可以用：

sudo deluser --remove-home zhangsan

--remove-home等价于userdel -r中的清理主目录行为。CentOS/RHEL 系默认不带deluser，建议把userdel和deluser的区别记清楚，面试时也经常被问到。

6. 完整示例：从创建到删除的用户生命周期管理

前面的知识点比较分散，这一节用一个完整的场景串起来，展示一个用户从创建、设密码、临时禁用、到最终删除的完整流程。这也是很多运维面试里“如何下线一台服务器上的员工账号”的标准回答模板。

6.1 场景设计

假设团队来了一名新同事，操作系统是 CentOS Stream，我们需要为它创建账号、初始化密码，并强制首次登录修改密码。三个月后该同事离职，我们需要安全地删除这个账号。

6.2 创建用户并设置密码

示例账号zhangsan。

# 创建用户并创建主目录 sudo useradd -m zhangsan # 初始化密码，密码先写在 pwd.txt 中，避免直接暴露在历史记录 echo 'Init@Pass123' > /tmp/pwd.txt sudo passwd --stdin zhangsan < /tmp/pwd.txt

passwd --stdin可以从不标准输入中读取密码，适合脚本环境。CentOS 自带支持，Ubuntu 默认不带，需要手动扩展或用chpasswd。所以更通用的写法是：

echo 'zhangsan:Init@Pass123' | sudo chpasswd

强制首次登录修改密码：

sudo chage -d 0 zhangsan

验证用户可正常登录：

su - zhangsan

此时系统会提示You are required to change your password immediately，输入新密码后切换到正常环境。

6.3 临时禁用与恢复

员工休假或账号被怀疑异常时，不删用户，直接锁定：

sudo usermod -L zhangsan

验证锁定效果：

su - zhangsan

执行后，即使输入正确密码，也会提示认证失败。

恢复账号：

sudo usermod -U zhangsan

6.4 安全删除账号

员工离职确认后，先检查进程和文件，再删除。

# 检查用户运行中的进程 ps -u zhangsan # 检查用户主目录大小 du -sh /home/zhangsan # 备份主目录到指定备份路径 sudo tar -czf /backup/zhangsan_home_$(date +%F).tar.gz /home/zhangsan # 终止该用户所有进程，确认业务影响后执行 sudo pkill -u zhangsan # 删除用户并清理主目录 sudo userdel -r zhangsan

删除后建议再确认一下系统中没有残留的 zhangsan 相关文件：

find / -user zhangsan 2>/dev/null

如果没有任何输出，说明该用户的数据基本清理干净。

6.5 deluser 路径的做法

如果运行的是 Ubuntu，可以把删除步骤写成：

sudo deluser --remove-home --backup-to /backup zhangsan

--backup-to参数会在删除前把主目录备份到指定目录。这个设计比裸敲userdel -r安全得多。

7. su 切换用户：环境差异与实战细节

很多人一开始接触 Linux 就觉得su只是“切换 root”的工具，实际上它也可以切换到任意用户。真正需要注意的是环境变量的变化。

7.1 su 与 su - 的区别

# 切换到 root，但保留当前用户的环境变量 su # 切换到 root，并重新加载 root 的登录环境 su -

听起来有点抽象，我们用实际场景来验证。

假设当前是普通用户zhangsan，PATH 变量是普通用户路径。执行su切换到 root 后，运行which systemctl，可能还会找到普通用户目录下的命令。执行su -后，系统会加载 root 的/root/.bash_profile，PATH 变成 root 环境的完整路径。

从实际经验看，在脚本中或临时执行管理命令时，优先使用su -而不是su。否则你可能会遇到“明明切到 root 了，为什么 systemctl 找不到”这种奇怪问题。

7.2 su 切换指定用户

# 切换到指定用户，不加载完整环境 su zhangsan # 切换到指定用户，加载完整环境 su - zhangsan

切换普通用户时需要输入目标用户的密码；如果当前用户是 root，切换时不需要密码。

7.3 su 的执行与错误分析

执行su - zhangsan时常见的错误：

7.4 从 su 到 sudo 的选择

再补充一个运维场景中常遇到的问题：什么时候用su，什么时候用sudo？

su的问题是：普通用户一旦知道了 root 密码，就可以直接用 root 身份执行全部操作，这种方式权限边界模糊，不利于审计。sudo则允许管理员为不同用户配置精确的命令白名单。

# 允许 zhangsan 只执行系统服务管理命令 echo 'zhangsan ALL=(root) /usr/bin/systemctl' | sudo tee /etc/sudoers.d/zhangsan

相比之下，多管理员服务器更推荐配置sudo而不是把 root 密码告诉所有人。su作为临时手动切换、救援环境、脚本内切换用户等场景仍然很有价值，但权限控制上需要谨慎。

8. 运行结果与效果验证

命令执行后，怎么判断结果是否符合预期？简单列几个验证方法。

8.1 验证用户是否已删除

# 查看用户是否还存在 id zhangsan

如果输出id: ‘zhangsan’: no such user，说明用户记录已经删除。

再检查 shadow 文件：

sudo getent shadow zhangsan

无输出说明密码记录也已清理。

8.2 验证密码修改是否生效

# 查看密码状态 sudo passwd -S zhangsan

执行后出现P表示密码可用，出现L表示锁定，NP表示无密码。

也可以实际测试登录：

su - zhangsan

输入新密码能登录，说明密码修改成功；提示认证失败，说明锁定生效或密码错误。

8.3 验证 su 切换是否加载了目标用户环境

su - zhangsan echo $HOME whoami

如果输出：

/home/zhangsan zhangsan

说明切换成功，且环境变量正确加载。如果$HOME没有变化，说明没有使用su -，或者目标用户的主目录配置有问题。

9. 常见问题与排查思路

10. 最佳实践与工程建议

Linux 用户管理做得好不好，不在于会不会背命令，而在于有没有一套可重复、可回滚、可审计的操作流程。

10.1 删除用户之前先做数据备份

在任何生产环境执行userdel -r前，先把用户主目录打包备份。备份不仅仅是为了防止误删，也是为了后续审计时可以追查离职员工负责的数据和配置。

建议备份命令：

sudo tar -czf /backup/users/zhangsan_$(date +%Y%m%d_%H%M%S).tar.gz /home/zhangsan

备份文件和删除操作的时间点最好能够对上，方便事后追溯。

10.2 密码策略要结合安全基线

创建用户时，别只设置一个临时密码，还要用chage设置密码有效期。常见做法是：

• 初始密码必须立即修改。
• 普通用户密码最长有效期 90 天。
• 连续失败登录超过 5 次锁定账号。

这些配置可以通过/etc/login.defs和/etc/security/pwquality.conf调整。

10.3 不要把 root 密码到处传播

多管理员协作时，优先使用sudo而不是su。具体做法是：在/etc/sudoers.d/目录下创建独立配置文件，为不同管理员分配不同命令权限。这样即使某管理员的操作出了问题，审计日志也能清晰记录是谁执行的。

10.4 用户命名与回收周期要有规范

团队内部可以约定：

• 用户名统一使用拼音全称，比如zhangsan、lisi。
• 离职账号在 3 天内完成备份和回收。
• 删除用户前必须在工单系统记录确认信息。
• 同一用户名在回收后的一段时间内不得重新分配，防止历史数据残留引发权限混淆。

10.5 注意用户资源占用

一个用户可能持有大量文件、进程和定时任务。删除用户之前，建议用脚本统计一下用户拥有的文件数量、总大小和进程占用，避免删除后才发现还有数据残留。这个检查步骤在云服务器磁盘空间管理上尤其重要。

10.6 使用 PAM 控制本地登录

如果服务器有多个普通用户，可以通过 PAM 配置限制哪些用户能通过 SSH 登录、哪些只能本地登录。比如设置/etc/security/access.conf，控制用户来源，能在账号阶段就减少一部分安全风险。

11. 适合放脚本里的自动化处理思路

如果在多台服务器上同时处理一批离职账号，手动逐台敲命令效率太低，可以写一个清理脚本。下面是一个精简示例，仅供参考。

#!/bin/bash # 文件路径：/usr/local/sbin/cleanup_user.sh # 用法：sudo ./cleanup_user.sh 用户名 USER_NAME="$1" BACKUP_DIR="/backup/users" if [ -z "$USER_NAME" ]; then echo "Usage: $0 <username>" exit 1 fi if ! id "$USER_NAME" &>/dev/null; then echo "User $USER_NAME does not exist" exit 1 fi mkdir -p "$BACKUP_DIR" tar -czf "$BACKUP_DIR/${USER_NAME}_$(date +%F).tar.gz" "/home/$USER_NAME" 2>/dev/null pkill -u "$USER_NAME" 2>/dev/null userdel -r "$USER_NAME" echo "Cleanup $USER_NAME completed."

这个脚本没有做非常复杂的确认，实际使用时应该再增加二次确认和日志记录。

12. 总结与后续学习方向

Linux 用户管理的核心不在于单个命令，而在于理解每个操作背后的边界。删除用户时要考虑主目录、进程、定时任务、邮件池和散落的文件；设置密码时要掌握密码状态、有效期和锁定机制；切换用户时要清楚su与su -的环境差异。这三个操作看似独立，实际上构成了一个完整的账号生命周期管理闭环。

建议下一步动手做什么呢？拿起一台测试机器，按顺序练一遍：用useradd -m创建用户，用chpasswd设置初始密码，用chage -d 0强制首次登录改密，用su -切换验证，再练习锁定、解锁、最终安全删除整个流程。把这一套流程跑熟之后，再去看/etc/passwd、/etc/shadow、/etc/group的文件内容，很多疑问会自然解开。

再深入一点，可以学习用户权限管理中的sudo规则、PAM 认证流程、ACL 访问控制列表。用户管理只是入口，权限体系才是 Linux 安全的核心。后续遇到“普通用户执行特定命令”或“某用户不能登录但服务正常使用”这类需求，就会意识到这些基础操作背后的坑到底有多深。建议把本文提到的命令和排查思路收藏备用，实际服务器操作时，先备份、再验证、最后清理的顺序一定不要乱。