★ FEATURED ARTICLE 1. 问题现场报错“passwd: Authentication token manipulation error”是怎么发生的1.1 普通用户改密失败的典型场景前几天我收到一个关于 Linux 云主机的排查求助情况非常简单粗暴某个普通用户在终端里执行passwd输入两次新密码后系统没有像平时那样提示“passwd: password updated successfully”而是直接丢出一行冷冰冰的英文错误passwd: Authentication token manipulation error把日志翻出来也没有更多细节。用户当时就懵了我是普通用户改自己的密码怎么就不让改我远程看了一眼机器状态确认这台主机用的是常见的 Linux 发行版root 还能正常登录磁盘也没有立刻报错问题就集中在这个普通用户的密码更新环节。这类问题在运维群里其实不算罕见。它最容易出现在三类场景里一是新创建的普通用户第一次尝试设置密码二是服务器从模板克隆或者快照恢复之后权限和文件属性发生了变化三是容器或者虚拟化环境里宿主机给文件系统加了额外限制。无论哪种表象都一样普通用户改不了密码报错信息是Authentication token manipulation error。很多第一次遇到的人会把这条报错理解成“密码太简单”或者“用户没有权限”。其实都不准确。密码强度问题会用Bad password之类的提示权限问题通常会直接是Permission denied。这条Authentication token manipulation error是另一套逻辑在报错它说的是用户身份验证通过了但系统在“更新认证令牌”这一步失败了。1.2 对这一条报错的直接理解“Authentication token”在 Linux 的 PAM 体系里指的就是用户的密码凭据更准确地说是你存在/etc/shadow里的那一串密码哈希。正常情况下普通用户执行passwd程序会带着 root 权限去改写/etc/shadow里对应用户的“令牌”字段。如果这个写入动作没有成功PAM 就会把这层失败包装成Authentication token manipulation error。所以看到这条报错时不要急着怀疑是密码策略问题。它在告诉你的是用户把想要修改的令牌给了系统但系统没能把它写进认证数据库。原因可以是文件权限坏了、文件被锁了、磁盘满了、文件系统挂了、特殊属性被设置了甚至是安全模块干预了写入。接下来要做的事就是一步步查清楚到底哪一环挡了路由。2. 排查思路从表象到根因逐层定位2.1 第一层确认是不是普通用户独有的问题我开始排查这类问题第一步永远是先看“换个人改密码会不会也这样”。这不是多余动作它能在 5 秒内隔离出问题范围。先用 root 对同一个用户执行一次密码重置passwd testuser如果 root 能正常修改成功说明/etc/shadow本身没有坏到完全不可写问题大概率出在普通用户发起密码修改的那条链路里可能涉及/usr/bin/passwd的 setuid 位、PAM 配置或者认证方式。如果 root 也报同样的错误那问题就更系统级了优先检查文件系统挂载状态、磁盘剩余空间、shadow 文件权限和特殊属性。还有一种常见情况是这台机器通过 LDAP、NIS 或者 Kerberos 做统一认证本地/etc/shadow并不是真正的认证数据源。此时普通用户执行passwd会尝试向中央认证服务器发起更新一旦本地配置权限不够也会报Authentication token manipulation error。这种环境里最直接的判断方式是查看/etc/nsswitch.conf里passwd那一行如果出现ldap、nis之类的外源就得去对应认证服务端排查。2.2 第二层检查 /etc/shadow 权限、锁文件和磁盘状态排除了外源认证后回到本地文件本身。先把最关键的三个信息一次打出来ls -l /etc/shadow ls -l /usr/bin/passwd df -h /正常情况下/etc/shadow的权限应该是-rw-r-----属主是root属组是shadow。/usr/bin/passwd的权限应该是-rwsr-xr-x那个s就是 setuid 位它决定了普通用户运行passwd时能否临时获得 root 身份去写 shadow。如果passwd的s位丢了普通用户执行时就是用自己的身份去写/etc/shadow那必然失败。恢复方法后面会写到。磁盘满也是很容易被忽略的原因。passwd在写入 shadow 时会先创建临时文件或锁文件如果根分区满了写入动作就会失败报的也是这条错。df -h /输出里Use%到 100% 就要先腾空间。还要注意一个文件/etc/.pwd.lock。这是passwd在更新密码时用的锁文件正常情况下它会在操作结束后被清理掉。如果因为断电、进程被杀或者其他原因残留下来后续更新就可能一直拿不到锁也会触发同样的报错。检查一下ls -l /etc/.pwd.lock /etc/shadow.lock 2/dev/null如果锁文件存在且明显属于残留确认当前没有passwd相关进程在跑之后可以手动删除rm -f /etc/.pwd.lock /etc/shadow.lock2.3 第三层文件系统挂载与安全模块的干扰再往下排查要看文件系统的挂载参数。比如/etc所在的根分区被以只读方式挂载了那所有写入都做不到。用mount查看挂载信息mount | grep -E / |/etc重点关注有没有ro、nosuid这两个参数。ro代表只读nosuid表示该分区上的 setuid 位不生效。后者最容易在容器环境里出现宿主机为了安全把某些目录以nosuid方式挂进去容器里的passwd即使二进制的 setuid 位还在可执行时也不会切换成 root最终就会报 token manipulation error。SELinux 也是容易踩的点。启用 SELinux 的系统里/etc/shadow有它自己的安全上下文如果被恢复备份、迁移或者错误修改导致上下文变成了普通文件类型policy 就会阻止 sshd、passwd 等进程去读它或写它。检查命令ls -Z /etc/shadow getenforce如果getenforce输出是Enforcing并且上下文看起来不对可以尝试恢复restorecon -v /etc/shadow如果是临时为了验证问题也可以先setenforce 0再做一次密码修改测试但生产环境不要长期这么干。3. 解决方法按风险从低到高的完整操作清单3.1 先用 root 重置密码快速解除业务故障如果你的目的是“让这个用户尽快能登录系统”最直接的办法是让 root 帮他把密码重置掉passwd testuser这个命令会以 root 身份直接写/etc/shadow通常不依赖用户侧的 PAM 校验所以即便普通用户之前改密码失败了root 重置往往都能成功。重置完以后让用户重新登录问题可能就到此为止。如果连 root 的passwd testuser都失败可以试试chpasswdecho testuser:NewPassword123 | chpasswdchpasswd是另一个修改密码的工具走的是标准输入和passwd交互流程不同。它能绕开一些交互式 PAM 问题排查时多用一种工具就多一条思路。另外要留意一种特殊情况用户密码字段如果是锁定状态比如/etc/shadow里密码以!或!!开头普通用户修改密码时也可能失败。用 root 查看用户状态passwd -S testuser如果显示L表示锁定先解锁再让用户改passwd -u testuser passwd testuser3.2 修复 setuid 位、锁文件和 /etc/shadow 权限如果 root 重置密码没问题而普通用户还是改不了重点怀疑/usr/bin/passwd的 setuid 位。检查命令ls -l /usr/bin/passwd正常输出应该是类似-rwsr-xr-x 1 root root 68208 ... /usr/bin/passwd如果看到的是-rwxr-xr-x说明 setuid 位丢了。恢复chmod us /usr/bin/passwd改完再让普通用户试一次。实际中这个位不是很容易无故丢失但如果系统被加固脚本处理过或者分区以nosuid方式重新挂载过就会出现。/etc/shadow的权限也顺手修一下chown root:shadow /etc/shadow chmod 640 /etc/shadow这里额外多说一句有的朋友看到“改不了密码”就立刻去chmod 666 /etc/shadow这是绝对不能做的。shadow 文件里存的是所有用户的密码哈希一旦任意用户可写就等于把整个系统账号数据库暴露了。改完以后一定会收到安全告警甚至被入侵我都见过不止一次。正确的权限就那么几个值属主 root属组 shadow权限 640。3.3 处理 immutable 属性、SELinux 上下文与容器限制还有一种比较隐蔽的坑是/etc/shadow被设置了 immutable 属性。用lsattr查看lsattr /etc/shadow /etc/passwd如果看到第二列有i表示文件不能修改、删除、重命名那不管是谁来写都会失败。这是因为某些安全软件或加固脚本会给关键文件加锁防止被篡改。解除方法chattr -i /etc/shadow再重新执行密码修改。如果确认是安全策略需要处理完密码后再把属性加回去chattr i /etc/shadowSELinux 上下文问题按照前面说的用restorecon -v /etc/shadow恢复。如果是容器环境还需要检查容器的卷挂载参数。以 Docker 为例如果/etc/shadow来自只读挂载那容器内无论如何改都没用更常见的是挂载时加了nosuid导致 setuid 位失效。这时需要在宿主机上调整挂载参数把nosuid去掉或者改用其他方式来管理密码比如宿主机直接对虚拟机或容器的文件系统进行操作。这类受限环境下与其硬改不如思考镜像模板本身是否该预置密码或使用密钥登录。3.4 特殊情况在 /etc/shadow 里手工处理密码字段前面所有办法都试过问题仍然存在时最后的手段是直接编辑/etc/shadow。这个操作风险极高我只建议在有完整备份、并且是在意外情况下的应急手段。先备份cp /etc/shadow /etc/shadow.bak.$(date %F)然后生成新密码哈希mkpasswd -m sha-512 YourNewPassword如果没有mkpasswd可以用 Pythonpython3 -c import crypt; print(crypt.crypt(YourNewPassword, crypt.mksalt(crypt.METHOD_SHA512)))拿到哈希后打开/etc/shadow找到目标用户那一行把第二列替换成生成的哈希vim /etc/shadow保存后立刻开一个新终端验证登录。手工编辑 shadow 最大的好处是不会走 PAM 那套复杂链路但也正因为绕过了正常校验一旦格式写错、权限被破坏可能导致全线用户无法登录。所以这条路径始终作为最后手段做完要马上测试并且不要留下备份文件在在线生产环境里太久。4. 问题背后的 Linux 认证机制4.1 普通用户凭什么能改自己的密码要彻底搞懂这个报错得先明白一个反直觉的点普通用户没有写/etc/shadow的权限但他的passwd却能凭自己的力量完成修改。原因在于/usr/bin/passwd有一个特殊权限位——setuid。setuid 位的作用是当普通用户执行这个程序时进程的有效用户 ID 会被临时切换成文件属主也就是 root。你可以把它理解为“定向授权的化身服务”。普通用户只是下命令的人真正动手写/etc/shadow的是以 root 身份运行的程序体。这是几十年前就设计好的机制既让普通用户能改自己的密码又不给普通用户任意写账号文件的权限。一旦这个机制被破坏比如 setuid 位被清掉或者所在文件系统带了nosuidpasswd就会以普通用户自己的身份运行。它拿到的新密码哈希还在但根本写不进 shadow于是 PAM 把这个失败翻译成了Authentication token manipulation error。4.2 PAM 在密码修改链路里做了什么PAMPluggable Authentication Modules是 Linux 账号认证的框架。普通用户执行passwd不只调用了改密码的二进制还会经过一串 PAM 模块的验证。简单说流程大概是用户输入旧密码 - unix_chkpwd 校验身份 - pam_unix 生成新密码哈希 - 尝试写入 /etc/shadow - 创建/获取锁文件 - 更新 token 字段 - 返回结果给 passwd这个链路里任何一个环节失败最终都会以 passwd 的退出码反馈到屏幕上。Authentication token manipulation error就是其中“第 3 步往后的写入更新环节”失败时PAM 给用户的统一提示。因此它不代表密码强度错误也不一定是权限问题而是“尝试维护认证令牌时系统层面没有成功”。理解这条链路有实际意义排查时不要再盯着一处看。锁文件、shadow 权限、磁盘空间、setuid 位、SELinux、挂载参数任何一环出问题都有可能是同一个报错。这也是为什么前面解决部分要按顺序排查而不是看到一个可能原因就急着改。4.3 “Authentication token”到底是什么口径PAM 语境里authentication token 通常就是指“用户密码”本身。它可能是你输入的明文密码也可能是密码哈希。在/etc/shadow的七个字段里第二个字段就是 token 的存储位置。所以账号:password_hash:最近修改时间:最小修改间隔:最大有效期:过期警告:不活跃天数:失效日期:保留字段当你执行passwd本质就是在做一件事重新生成 token并且更新第二列。知道这个字段结构有什么用排查时如果怀疑 shadow 被写坏用 root 打开看第二列是不是明显不是合法哈希或者权限标记异常就能很快判断。也能理解为什么手工改 shadow 要格外小心因为你改的不是普通文本而是整个系统认证链路的最终凭据。5. 避坑记录我从这类故障里总结的几条经验5.1 故障处理速查表把这次的排查过程整理成一张速查表下次碰到同报错可以照顺序过。表现可能原因快速验证处理方式普通用户改密失败root 正常/usr/bin/passwd丢失 setuid 位ls -l /usr/bin/passwdchmod us /usr/bin/passwd普通用户改密失败root 也失败磁盘满df -h /清理根分区空间普通用户改密失败root 也失败/etc/shadow被设为 immutablelsattr /etc/shadowchattr -i /etc/shadow普通用户改密失败root 也失败/etc以只读方式挂载mount | grep / 重新挂载为读写普通用户改密失败root 也失败锁文件残留ls -l /etc/.pwd.lock删除残留锁文件全链路异常SELinux 上下文错误ls -Z /etc/shadowrestorecon -v /etc/shadow容器内改密码失败挂载参数带nosuidmount调整宿主机挂载参数用户本身密码锁定/etc/shadow密码字段以!开头passwd -S testuserroot 执行passwd -u testuser这张表不是让你逐条抄而是帮你建立一个“先确认范围再逐层收窄”的思维习惯。5.2 我在处理这类故障时踩过的坑第一次遇到这个报错时我犯过一个很低级的错因为当时手头事多看到报错里有Authentication第一反应是检查 PAM 配置翻来覆去调pam_unix.so的参数折腾了半天没有用。后来一查磁盘根分区已经 100%。原因很简单日志把磁盘塞满了passwd连临时文件都写不进去自然改不了密码。那之后我给自己定了规矩碰到任何写操作报错先看磁盘再碰配置。还有一次是在某云主机上用户创建了好几个月没设置过密码某天走管理后台重置了系统文件之后普通用户就改不了密码。查下来是/etc/shadow属主变成了普通用户权限也成了0644。这类问题多半是恢复备份或迁移文件时用了cp -r之类只保留属主但没保留权限的命令导致的。手工恢复属主和权限后问题立刻消失。更隐蔽的情况出现在一台加固过的服务器上。安全基线脚本给/etc/passwd、/etc/shadow都加了chattr i普通用户改密码失败root 手动改也失败所有常规检查都正常。最后用lsattr看到那个i才找到真凶。所以现在我看 Linux 账号问题已经不只看权限位还要看文件属性。5.3 日常预防和恢复建议这种问题最怕在业务高峰期冒出来所以平时最好做两件事。第一定期备份/etc/shadow和/etc/passwd。备份时保留正确权限不要用普通文件复制的方式直接扔到网上或者塞进共享目录。建议备份到本地加密目录并限制访问权限。恢复时也要记得校验文件属主和权限不要恢复完就完事。第二普通用户第一次使用系统时尽量让 root 先给这个用户设置好密码并确认允许修改passwd testuser chage -d 0 testuserchage -d 0会让用户在下次登录时强制修改密码。这样可以避免用户第一次运行passwd时踩到各种权限和 lock 文件的边角问题。如果你已经收到普通用户改密失败的工单先用 root 帮他重置一次密码再让他在自己终端上主动改一次等于把“首次修改密码”这个最容易出问题的场景提前消化掉。从我的实际操作经验看Authentication token manipulation error并不可怕。它不是神秘的系统损坏而是 Linux 对“认证令牌更新失败”做的一层统一封装。只要记住先看磁盘、看看锁文件、看 setuid 位、看文件属性这四板斧绝大多数机器都能在十分钟内定位到根因。最后再提醒一句凡是动/etc/shadow前先备份凡是备份文件别留在/etc里。安全习惯比任何一条命令都重要这套流程也就真正闭环了。
阅读完成 · 觉得有帮助？
