企业官网建设流程全解析

我自己用 passwd 这个命令的时间，算下来超过十年了。在 Linux 日常管理里，它大概是出镜率最高、也最容易被低估的一个命令。很多人以为它就是“改个密码”，但实际上 passwd 背后牵动的是一整套账户与密码管理机制：/etc/shadow 里的密码哈希、账号锁定标志、密码过期策略，全都跟它有关。这篇就把 passwd 命令从用法、原理到常见坑位完整过一遍，适合刚入门 Linux 的同学，也适合写脚本、做运维的朋友拿来当排查手册。

我为什么想写这个主题？因为工作里见太多人栽在 passwd 的细节上。有人批量建号后用户第一次登录就被要求改密，不知道怎么配置；有人发现账户被锁定想解开，结果 passwd -u 解完还是登录不了；还有人把密码直接写在命令行里，当天就被同事提醒“你密码全公司都看得见”。这些都不是大故障，但每一个都够折腾一阵。所以这篇我按“先讲原理、再讲实操、最后讲排查”的顺序来写。

1. passwd 到底改的是什么：shadow 文件与密码哈希机制

要真正会用 passwd，第一步不是记参数，而是搞清楚它到底在哪个文件里动刀子。很多人对用户管理的理解停留在 useradd 建用户、passwd 改密码，但其实用户信息存在哪、密码存在哪、为什么普通用户也能改自己的密码，这三件事搞明白，后面所有坑都能少踩一半。

1.1 /etc/passwd 管身份信息，/etc/shadow 才是密码的保险柜

Linux 里用户信息分两个文件存：/etc/passwd 和 /etc/shadow。前者是几乎所有程序都能读的公开文件，里面每一行代表一个账户，字段用冒号分隔：用户名、密码占位符、UID、GID、注释信息、家目录、登录 Shell。这里要强调一点：/etc/passwd 第二列的x并不是密码，只是一个占位符，真正密码哈希全部挪到 /etc/shadow 里了。

早期 Unix 系统确实是把密码哈希直接放在 /etc/passwd 里的，但后来发现这条路走不通——这个文件需要被各种程序读取，等于把密码哈希公开给了所有能登录系统的用户，暴力破解的门槛太低。于是才有了 /etc/shadow，它的权限通常只有 root 和 shadow 组能读，普通用户根本没机会看到别人的哈希。一句话总结：/etc/passwd 是用户信息的“名片夹”，/etc/shadow 才是真正上锁的“密码保险柜”。

1.2 shadow 里密码字段的一串字符到底在说什么

再看 /etc/shadow，每一行同样用冒号分隔，核心字段包括：用户名、密码哈希、最后一次修改时间、最短使用天数、最长有效期、警告天数、宽限期、保留字段。密码哈希那一列就是 passwd 命令主要折腾的对象。

标准格式长这样：

$算法id$盐值$真正的哈希

比如$6$KxQ9...$fTG...，开头的$6$说明用的是 SHA-512。把这个结构拆开后，很多命令输出就好解释了。常见算法标识对应关系如下：

为什么不用明文或者可逆加密？因为密码一旦可逆，文件泄露等于全盘送出。哈希是单向的，你只能拿候选密码一次次计算哈希然后比对。盐值则是用来对抗彩虹表攻击的，同一密码在不同用户身上算出来的哈希也不一样。所以以后看到两个用户 shadow 里的哈希不同，别急着断定密码不同，有可能只是盐值不同。这是很多人容易误解的一个点。

1.3 为什么普通用户也能用 passwd 改自己的密码

回到 passwd 命令本身。你可以执行ls -l /usr/bin/passwd看一眼，会发现它的权限位是-rwsr-xr-x，中间那个s就是 setuid 位。普通用户执行 passwd 时，进程会以文件属主 root 的身份运行，于是就有权限去写只有 root 能写的 /etc/shadow，改完自己的密码后进程退出，root 权限随之释放。

这其实是经典面试考点：为什么 /usr/bin/passwd 要带 setuid 位？答案就是它需要在不给普通用户完整 root 权限的前提下，让用户能修改自己的密码哈希。当然，setuid 程序一直是安全攻击面，历史上 passwd 也出过缓冲区溢出一类的问题，所以现在内核和发行版在这个位置的防护都非常谨慎。

2. 五个高频实战场景：从自己改密码到批量脚本重置

原理讲完，进入实战。下面这几种场景覆盖了我日常工作中 90% 以上的 passwd 用法，也是在面试、考证里最常出现的操作命令。

2.1 普通用户修改自己的密码：交互流程别跳过

终端直接敲passwd，不带任何参数，就是修改当前登录用户的密码。系统会先要求输入原密码，再让你输入两次新密码。这里有两个细节容易被忽略。

第一，为什么要先验证原密码？如果你以普通用户身份执行 passwd，系统必须确认操作者确实是账号本人，这是最基本的身份校验，防止别人趁你离开终端时把你的密码改掉。

第二，新密码输入时终端不会回显，也不显示输入位数，很多新手以为键盘坏了，其实这是密码输入的正常设计。输完两次新密码一致，命令返回 success，/etc/shadow 里的哈希就更新了。如果你设的密码太简单，比如六个 1，PAM 策略会弹一个BAD PASSWORD警告。在多数发行版上这仅仅是个警告，密码依然会设置成功；但在启用了严格 pwquality 策略的系统上，会直接拒绝，错误信息一般是“密码未通过字典检查”。这个后面排查部分再细讲。

2.2 root 强制重置指定用户密码：别忘了强制过期

root 管理员给其他用户重置密码的语法是passwd 用户名。root 改别人密码不会要求输入旧密码，设置完成后直接覆盖 shadow 里的哈希。这个场景在运维中很常见：用户忘记密码、新人入职分配临时密码、离职交接账号。

我平时给测试部门的同事重置完密码，一般还会顺手敲一句chage -d 0 用户名，让他们下次登录时强制修改密码，初始密码只在工单里通知一次。别省这一步，不然初始密码会被一直沿用，时间长了部门里人人都知道这个密码是什么，账号安全就等于筛子。这个做法原理上等价于 passwd -e，后面章节会展开。

2.3 脚本里非交互式改密码：--stdin 和 chpasswd 的取舍

脚本里批量重置密码，是最容易写错的地方。很多人看到网上教程用echo password | passwd --stdin user，这个写法在 RHEL/CentOS/Fedora 这一系是能跑的，因为 passwd 自带 --stdin 参数：

echo 'Tmp@2026' | passwd --stdin alice

但同样的命令拿到 Debian/Ubuntu 上会直接报错，提示 unrecognized option，因为 Debian 系的 passwd 默认不支持这个选项。Debian 系更通用的方案是 chpasswd：

echo 'alice:Tmp@2026' | chpasswd

chpasswd 专门为批量更新密码设计，可以一次喂多行用户名:密码数据。所以我的习惯是跨发行版环境一律用 chpasswd，少给自己挖坑。

不管是 --stdin 还是 chpasswd，明文密码出现在命令行里都有泄露风险。echo '密码'这句话会进 shell 历史，如果你是在共享终端或录屏的服务器上操作，等于把密码当众念了一遍。更稳的做法是用变量：

read -s -p '输入新密码: ' NEWPASS echo "alice:$NEWPASS" | chpasswd unset NEWPASS

让密码只存在于内存变量里，中转之后立即清除。如果非要在一次性脚本里硬编码，记得把脚本文件权限设成 600，并且用完后删除。

2.4 用 passwd -S 快速判断账户状态：P、L、NP 的含义

判断一个账户能不能正常登录，比改密码更常用的命令是passwd -S 用户名。比如输出：

alice P 08/10/2026 0 90 7 5

第一个字段是用户名，第二个字母就是账号密码状态，后面跟的是上次修改日期、最短天数、最长天数、警告天数、宽限天数。看一眼这一列，账户当前能不能登录就心里有数了。

如果状态是 L，直接passwd -u解锁就能恢复；如果是 NP，说明 shadow 里密码字段是空的，这个账户已经处于无密码状态，相当危险，正常应该补一个密码或直接锁定。root 可以用passwd -a查看所有账户的状态，用于定期巡检。

3. 账号锁定、解锁与密码生命周期管理

账号管理里，比改密码更让人头疼的是锁账号和密码过期。我处理过不止一次“用户突然登不上服务器”的工单，排查到最后都是 passwd 相关参数被之前的同事误配。这里单独开一章讲清楚。

3.1 锁定和解锁账号：passwd -l / -u 的内部机制

passwd -l 用户名用来锁定账号，本质是在 /etc/shadow 的密码哈希前面加一个感叹号!。别小看这个字符，它会让整段哈希永久失去匹配能力，无论输什么密码都验证失败。对应的解锁是passwd -u 用户名，会把开头的!移除，恢复原哈希。

这里有个真实踩过的坑：如果之前连续的锁定操作产生了!!两个感叹号，passwd -u 只会移除一个，剩下的!还在，账户依然处于锁定状态。所以解锁完记得回头用passwd -S看一眼状态，确认从 L 变回 P 再收工。

还要注意区分两种锁定：passwd -l 是改 shadow 哈希，属于硬锁定；而有些系统配置了 pam_faillock 登录失败锁定，那是把失败记录写在 /var/run/faillock 下，不会动 shadow。这种情况下 passwd -u 根本解不了，必须用faillock --reset来清。有一次我远程实验环境里故意输错 root 密码三次被锁，折腾半天才意识到要清 faillock，教训深刻。另外远程会话里锁定 root 要极度谨慎，锁完直接退出的话，你就把自己关在门外了。

3.2 强制用户下次登录改密：passwd -e 的正确用法

passwd -e 用户名又叫强制密码过期，效果是让 shadow 里“最后一次修改时间”字段变成 0。用户下一次登录时，系统发现密码已经“超期”太久，会强制要求先设置新密码再进入 shell。它和chage -d 0 用户名完全等价。

我在创建账号、重置密码后的固定套路就是这样：先给一个临时密码，再passwd -e，保证用户第一次登录就把密码换掉。这样即使临时密码在传输过程中泄露，没过多久也作废了。新员工入职时我还会在邮件里明确写“第一次登录必须改密码”，有效减少初始密码被长期沿用的问题。

3.3 密码老化参数：最短天数、最长天数、警告期与宽限期

除了一次性强制过期，更多场景需要给密码设一个生命周期。passwd 相关的几个参数分别是：

• -n：最短使用天数，密码设置后多久内不允许再次修改
• -x：最长有效期，密码多少天后过期
• -w：过期前警告天数，提前多少天提醒用户
• -i：到期后宽限天数，过期后还能登录多少天

比如要求密码 90 天必须换一次，提前 7 天提醒，到期后宽限 5 天还能登录：

passwd -n 0 -x 90 -w 7 -i 5 alice

其中-n 0意思是密码可以立即修改。这条写完之后，可以用chage -l alice查看当前策略，能看到 Maximum age、Warning 这些行。顺便提一句：这组参数最终是否生效，还取决于 PAM 配置。比如有的系统 pam_unix 里没开密码过期检查，那即使到期了也不会自动锁，只是登录时提示警告。实际项目里最好把系统自带的密码策略告警也接上，等用户被卡在外面才去处理就很被动了。

4. 常见故障排查与实操经验

最后这部分是真正的排查实录。下面几种情况都是我在生产环境真遇到过的，分别带上原因和处置方式，建议收藏起来当速查表。

4.1 忘记 root 密码后的恢复思路

自己的实验机，或者拥有物理机/云控制台权限的机器，root 密码忘了不用重装系统。最常用的思路是重启时进 GRUB，在要启动的内核行末尾追加参数进入单用户或紧急模式：追加single进单用户，或追加rd.break进入 initramfs 的 shell，也可以用init=/bin/bash绕过 systemd。进入 shell 后先以 rw 方式重新挂载根分区，然后直接passwd root重置，SELinux 环境下记得touch /.autorelabel，避免文件上下文写错导致启动异常。

云服务器一般不需要这么折腾，控制台基本都提供“重置密码”入口，原理类似，都是离线改 shadow。这套操作我只建议在自己管理和授权的机器上用，生产环境先走变更流程和备份，别半夜手痒直接重启。

4.2 改密码报错排障：从 PAM 策略到 shadow 被锁

改密码最常见的报错是Authentication token manipulation error，原因挺多，我遇到的典型情况有两类。第一类是 /etc/shadow 被chattr +i加了不可修改属性，此时即使 root 也照样改不了，先lsattr /etc/shadow确认，再chattr -i /etc/shadow解除后重试。第二类是根分区或 /var 分区满了，passwd 写新哈希时落不了盘，df -h看一眼就明白。

如果是普通用户遇到类似You may not view or modify password information for username的提示，那就是权限不足，老老实实切 root 或让管理员处理。另外还有两个容易被忽略的场景：“用户密码明明刚改过，却提示密码已使用”，说明系统开了密码历史记录；用户密码过期后登录提示“密码已过期，请更改”，但 ssh 终端里改密一直失败，那大概率是 PAM 里 password 模块链路有问题。

下面做个速查表：

4.3 批量创建用户时密码设置的稳妥姿势

批量创建用户的场景里，passwd 一般不会单独用，而是 useradd 和 chpasswd 搭配。我常用的做法：

for user in alice bob carol; do useradd -m -s /bin/bash "$user" echo "${user}:Tmp@2026!" | chpasswd chage -d 0 "$user" done

先建用户，再写入密码，最后把密码设为过期。这样用户第一次登录就必须改密码，临时密码只过渡一次。有几个细节值得说：初始密码里尽量带大小写、数字、特殊符号，免得和系统密码复杂度策略正面冲突；脚本中明文密码要谨慎，脚本文件本身要设置 600 权限，跑完顺手删除。如果是大规模导用户，可以把用户名:密码的清单做成文件，chpasswd < userlist一次性处理，效率更高也更可控。

4.4 顺带盘一下 passwd 相关的几个面试考点

最后盘点几个面试常问点。第一，为什么 /usr/bin/passwd 带 setuid 位？因为普通用户要以 root 身份更新 shadow，又不能给完整 root 权限。第二，shadow 里密码哈希前的感叹号表示什么？表示该账户被锁定。第三，怎么让用户下次登录强制改密？passwd -e 或 chage -d 0。第四，passwd -S 输出 P/L/NP 分别代表什么？可用的密码、被锁定、无密码。第五，为什么不能在命令行直接带密码？shell history、ps 瞬时参数、日志记录都可能泄露。

这些都是很基础的题，但能把原理讲明白的人不多。顺带一提，现在不少单位面试会考“如何批量给已有用户设置随机密码”，这个场景用 chpasswd 生成随机串再导入，比逐个交互式 passwd 靠谱得多。

我这些年用 passwd 踩过的坑，最有代表性的有两个：一是给 root 做了锁定后直接退出了远程会话，结果把自己关在门外，最后只能走控制台恢复；二是改了密码却忘了在定时任务或服务配置里更新部署账号的密码，导致半夜任务全线失败被叫起来。现在我的习惯是：所有涉及账户密码的操作前后，都先备份 shadow 文件，或者至少先passwd -S看一眼状态；所有脚本里的明文密码，一律用变量配合 read -s 来传，并且跑完清理历史。这个命令虽然小，但连接着整个账户体系的完整性，值得每个 Linux 使用者认真对待。

如果你在实操中遇到这篇文章里没提到的报错，建议把现场输出贴出来一起讨论。排查这类问题最忌讳只盯 passwd 本身，把 PAM、权限、磁盘、文件属性都过一遍，基本都能找到答案。