密码正确却提示 Authentication failure，问题通常出在认证链环节被拦截，如 root 账户未启用、PAM wheel 组限制、faillock 锁定、SELinux 或 systemd-logind 干预，以及 /bin/su 缺失 SUID 位等。
密码正确却提示 Authentication failure，基本可以排除输错密码本身——问题出在认证链的某个环节被拦截或跳过，而不是“密码不对”。重点不是重试密码，而是检查系统是否允许这次认证发生。
su 命令失败：root 用户未启用或密码为空
绝大多数桌面或最小化安装的 Linux（如 Ubuntu、CentOS Stream）默认禁用 root 账户，su - 会直接失败，哪怕你记得 root 密码。这不是 bug，是安全设计。
-
sudo passwd root是最直接的修复动作：它为 root 设置一个可用密码，并同时解锁账户（如果已被锁） - 执行后若提示
password updated successfully，再运行su -并输入刚设的密码即可 - 注意：
su验证的是目标用户（root）的密码，不是当前用户的密码；而sudo su验证的是当前用户的密码
/etc/pam.d/su 配置限制了 wheel 组权限
有些发行版（如 RHEL/CentOS/Fedora）默认启用 pam_wheel.so，要求只有 wheel 组成员才能用 su 切换到 root。即使密码对，非 wheel 用户也会被拒绝。
- 检查当前用户是否在 wheel 组：
groups或id -nG - 若无
wheel，运行sudo usermod -aG wheel $USER并重新登录终端 - 确认
/etc/pam.d/su中有类似auth required pam_wheel.so use_uid的行（不是注释掉的） - 如果不想改组，也可临时注释该行（仅用于测试），但不推荐长期禁用
账户被 PAM faillock 锁定或 shadow 状态异常
连续输错几次密码后，pam_faillock 模块可能已将用户锁定，此时即使输入正确密码也立刻被拒，且日志里通常不提示“locked”，只报 Authentication failure。
- 查锁定状态：
sudo faillock --user username（username 替换为实际用户名） - 清空失败记录：
sudo faillock --user username --reset - 检查账户是否被锁：
sudo passwd -S username，输出含LK表示锁定，用sudo passwd -u username解锁 - 看
/var/log/secure或journalctl -u systemd-logind -n 30，搜索faillock、authentication failure、locked
SELinux 或 systemd-logind 干预了认证流程
SELinux 在 enforcing 模式下可能阻止 su 调用认证模块；而 systemd-logind 若配置了 NAutoVTs=6 或 ReserveVT=6 不匹配，也可能导致 TTY 登录认证静默失败。
- 临时关闭 SELinux 测试：
sudo setenforce 0，若su立刻成功，说明策略限制，需查audit.log并用ausearch -m avc -ts recent | audit2why分析 - 检查 logind 是否异常：
loginctl show-user $USER，关注State=和LockedHint=字段 - 重启 logind 服务有时能恢复：
sudo systemctl restart systemd-logind
真正容易被忽略的点是：错误发生在哪一层并不总由提示语决定。比如 su: Authentication failure 看似是密码层，但背后可能是 PAM 拒绝加载 system-auth、shadow 文件权限错误（如被改成 600 以外）、甚至 /bin/su 丢失 SUID 位（ls -l /bin/su 应显示 -rwsr-xr-x）。别急着重设密码，先看日志、查状态、验权限。
