1. Ubuntu 下 su 认证失败到底卡在哪你在 Ubuntu 终端敲下su回车后输入密码结果屏幕上冷冰冰地弹出一句su: Authentication failure反复试几次都一样。这个提示在 Ubuntu 上出现频率极高尤其是刚从 CentOS 或其它发行版转过来的朋友第一反应往往是「我密码记错了」其实绝大多数情况下密码没错而是 Ubuntu 默认把 root 账户锁住了同时 PAM 模块对su的准入做了额外限制。su是 switch user 的缩写用来切换到另一个用户身份默认切到 root。它和sudo最大的区别是sudo走的是当前用户的密码加 sudoers 授权而su走的是目标用户的密码加 PAM 认证栈。Ubuntu 安装时只让你设置普通用户密码root 密码是「锁定」状态密码字段为!或*所以任何密码都过不了认证。这就是为什么你输安装时的用户密码没用输空密码也没用。这篇内容面向三类人刚装完 Ubuntu 想用 root 的新手、被 PAM 配置坑过的运维、以及手上有一堆工具凭据需要统一管理的开发者。我会从 PAM 配置、root 密码状态、sudoers 骨架三条线把原因拆开给出可直接复制的/etc/pam.d/su与 sudoers 片段、验证命令和回滚步骤。最后再讲一个容易被忽略的点当你在多台机器、多个 AI 工具之间切换时凭据散落本身就是一类「认证失败」的隐患用 TaoToken 的统一 Key 通道可以把这类配置收敛起来。先明确一个判断顺序避免瞎改配置先看 root 是否被锁 → 再看 PAM 的 su 栈 → 最后看 sudoers 是否限制了 su 组。顺序反了容易把能用的配置改坏。2. 动手前先把 TaoToken 的 Key 通道准备好排查系统认证问题本身不需要联网但我在实际工作里发现很多人改完 PAM 和 sudoers 后紧接着就要去配置各种开发工具的 API Key比如 Claude Code、各类 CLI 助手、自建脚本。这些工具的 Key 如果一台机器一份、一个工具一份时间一长就散成一片哪天某个 Key 失效你根本不知道是哪个配置文件在报认证失败。TaoToken 在这里的角色是「统一凭据入口」你在一处生成 Key多个工具通过同一个 API 通道去调用配置文件里只留一个引用而不是把明文 Key 复制到十几个地方。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置时直接写这个。具体操作路径我按用途分一下你按需选只是想验证模型能不能通、跑个对话测试走模型对话页 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content长期写代码、跑 Agent 任务需要稳定的编码额度走 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content要生成和管理 Key走 API Keys 页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content看接入说明和参数细节走接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content用 Claude Code 这类 Anthropic 协议工具走对应接入页 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content拿到 Key 之后你的工具配置里只写一次后续换机器、换工具都复用同一个 Key凭据管理从「到处找密码」变成「一处轮换」。这和下面要讲的 PAM 思路其实一致认证入口收敛问题才好定位。3. 可复制的 PAM 与 sudoers 配置骨架3.1 先确认 root 密码状态在改任何配置前先看 root 到底是不是锁的。执行sudo passwd -S root输出格式类似root L 01/01/2024 0 99999 7 -1第二列的字母是关键L表示 locked密码被锁这就是su认证失败的头号原因P表示已设置可用密码NP表示无密码如果是L你有两个选择给 root 设密码或者继续用 sudo 不启用 root。想启用就执行sudo passwd root系统会先要你当前用户的 sudo 密码然后让你输入两次新的 root 密码。设完再跑一次sudo passwd -S root看到P就说明 root 可登录了。这一步对应很多教程里让你sudo passwd的操作本质就是解锁 root。3.2 检查 /etc/pam.d/su 的准入栈root 解锁后如果su还是失败就要看 PAM。查看当前配置cat /etc/pam.d/su重点关注两行它们默认是注释掉的# auth required pam_wheel.so # auth sufficient pam_rootok.sopam_rootok.so的作用是如果当前已经是 root直接放行不再要密码。pam_wheel.so的作用是只允许 wheel 组成员使用su。如果你取消注释了pam_wheel.so但没把用户加进 wheel 组那这个用户su必然失败。一个稳妥的配置骨架如下你可以对照修改# /etc/pam.d/su auth sufficient pam_rootok.so auth required pam_env.so auth required pam_unix.so account required pam_unix.so session required pam_unix.so改之前务必备份sudo cp /etc/pam.d/su /etc/pam.d/su.bak改完不要关掉当前终端另开一个窗口测试su确认没问题再关旧窗口。这是 PAM 操作的基本纪律改错了还能用旧会话救回来。3.3 sudoers 骨架与 wheel 组如果你希望某个用户能su到 root同时又能用 sudo把它加进 wheel 组sudo usermod -aG wheel youruser然后用visudo编辑 sudoers注意必须用visudo它会做语法检查直接vim /etc/sudoers写错一个字符可能导致 sudo 全废sudo visudo在文件中确认这一行没有被注释%wheel ALL(ALL:ALL) ALL这行的含义是wheel 组的所有成员可以在所有主机上以所有用户和所有组的身份执行所有命令。改完保存退出visudo会自动校验语法。3.4 回滚步骤万一改完su和sudo都不能用了别慌用 Ubuntu 的恢复模式或 Live USB 挂载根分区把备份文件还原cp /etc/pam.d/su.bak /etc/pam.d/su cp /etc/sudoers.bak /etc/sudoers所以每次改之前cp一份备份不是形式主义是真能救命。4. 验证请求与成功结果配置改完按下面顺序验证每一步都要看到预期输出再进下一步。第一步确认 root 状态sudo passwd -S root期望看到第二列为P。第二步确认 wheel 组成员groups youruser期望输出里包含wheel。第三步实际切换测试su -输入 root 密码后提示符应该从$变成#并且当前目录切到/root。执行whoami应返回root。第四步验证 sudo 仍然可用在普通用户下sudo whoami期望返回root。如果这一步报sudoers语法错误说明 visudo 那步有问题回到 3.4 回滚。第五步如果你配置了 TaoToken 的 Key顺手验证一下 API 通道是否通。用 curl 测一个最小请求curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json | head -c 300把$TAOTOKEN_API_KEY换成你在 API Keys 页生成的 Key。返回里能看到模型列表的 JSON 片段就说明 Key 和通道都正常。这一步的意义在于系统认证和 API 认证是两套东西分开验证出问题才知道是哪一层。5. 本篇常见错误排查5.1 su: Authentication failure 反复出现先跑sudo passwd -S root。如果是L就是 root 被锁sudo passwd root解锁即可。如果已经是P还失败检查/etc/pam.d/su里pam_wheel.so是否被启用但用户不在 wheel 组。用groups确认不在就usermod -aG wheel加进去加完要重新登录才生效。5.2 sudo: /etc/sudoers is world writable这是权限被改坏了sudoers 必须是0440。用 root 或恢复模式执行chmod 0440 /etc/sudoers然后visudo -c检查语法。这个错误通常是因为有人用编辑器直接保存导致权限变化。5.3 su 能进但环境变量不对su和su -的区别在这里。su只切用户不加载目标用户的环境su -会加载完整的登录环境。如果你发现切到 root 后 PATH 不对、命令找不到用su -而不是su。这个坑我在早期排查时踩过以为是 PAM 问题其实是少了个减号。5.4 改了 PAM 后所有用户都登不进大概率是pam_unix.so那行被误删或写错。用备份还原或者进恢复模式把/etc/pam.d/su恢复成默认。默认的 su 文件里pam_rootok.so和pam_unix.so是核心缺一不可。5.5 TaoToken Key 报 401先确认 Key 没有多余空格再确认请求头是Authorization: Bearer key。如果 Key 是在 API Keys 页刚生成的注意复制完整。401 一般是 Key 本身的问题不是网络问题。想快速验证模型通道可以去模型对话页直接试一次排除本地配置干扰。6. 把凭据收敛成一处认证问题少一半回到开头那个场景su认证失败之所以让人慌是因为你不知道该查密码、查 PAM 还是查 sudoers三个地方各有一套逻辑。解决它的核心思路是「先定位层级再动手改」而不是一上来就乱改配置。同样的思路放到 API 凭据管理上当你有五台机器、八个工具每个都存一份 Key某天某个工具报认证失败你根本不知道是 Key 过期、配置写错还是通道问题。用 TaoToken 把 Key 收敛到一个入口工具配置里只留引用轮换时改一处即可。需要生成 Key 就去 API Keys 页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 长期跑编码任务就配 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 接入细节看文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一个我自己的习惯每次改/etc/pam.d/下的文件都在文件名后加日期备份比如su.20240601.bak这样回滚时能选版本而不是只有一个su.bak被后续操作覆盖。系统认证和 API 认证本质都是「入口清晰、备份在手、验证分步」做到这三点su认证失败这类问题就不再是拦路虎。