SSH 谷歌双因子不弹验证码 校验失败 PAM 权限全故障排查教程

部署 SSH 谷歌验证双因子时常遇到登录不弹验证码、校验失效问题，大多源于 PAM 配置顺序、SSH 交互参数、密钥文件权限三处配置疏漏。本文围绕不弹出验证码、验证码校验失败等高频故障，详解 sshd_config、pam.d 配置规范、初始化选型、文件权限与系统时间同步要点，同时补充 CentOS7 下 SELinux 特殊适配方案。

SSH 双因子认证不是“装完插件就生效”，核心卡点永远在 PAM 配置顺序、ChallengeResponseAuthentication 开关、以及 .google_authenticator 文件权限这三处。其他步骤出错通常有明确报错，而这三处失败时 SSH 登录往往静默跳过验证码，让人以为“没起作用”。

为什么 SSH 登录根本不提示输入验证码

最常见原因是 OpenSSH 没真正启用交互式挑战响应流程。仅改 /etc/ssh/sshd_config 不够，必须同时满足三个条件：

• ChallengeResponseAuthentication yes（注意是 yes，不是 on 或 true）
• UsePAM yes（否则整个 /etc/pam.d/sshd 配置被忽略）
• 若使用密钥登录，还需显式设置 AuthenticationMethods publickey,keyboard-interactive，否则密钥验证成功后直接放行，不走 PAM 的二次验证

改完必须 sudo systemctl restart sshd —— reload 不会重载 ChallengeResponseAuthentication 状态。

/etc/pam.d/sshd 中 auth 行怎么写才不绕过密码

错误写法：auth [success=done default=ignore] pam_google_authenticator.so —— 这会让验证码通过后直接跳过后续所有 auth 模块（包括密码检查），变成“只认验证码”。

正确目标是“密码 + 验证码”双校验，应使用：CentOS Linux 7.9.2009 是传统 CentOS Linux 7 的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容 RHEL 7 生态、文档丰富和软件支持广泛著称，曾长期用于 Web 服务、数据库、虚拟化节点和企业内部业务系统。不过 CentOS Linux 7 已于 2024 年 6 月 30 日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。

• auth [success=ok default=bad] pam_google_authenticator.so nullok：验证码成功则继续执行下一条 auth 规则（比如密码），失败则标记整个 auth 栈为 bad
• 这行必须放在 auth include password-auth 的正上方，否则密码验证先完成，二次验证根本不会触发
• nullok 是临时选项，上线前建议改为 secret=/home/${USER}/.google_authenticator 强制每个用户必须初始化

google-authenticator 命令运行时哪些选项不能乱选

运行 google-authenticator 后的 5 个交互问题中，以下三项直接影响可用性与安全性：

• “Do you want authentication tokens to be time-based?” → 必须选 y（TOTP）。选 n 是 HOTP，手机端 App 大多不兼容，且易因计数器不同步失效
• “Do you want to disallow multiple uses of the same authentication token?” → 必须选 y，否则同一验证码可重复提交，失去防重放意义
• “By default, tokens are good for 30 seconds” → 不要改这个值。客户端和服务端时间差超过 ±90 秒（3 个窗口）即失效，靠调宽窗口掩盖时间不同步，不如直接同步 NTP

生成后立刻执行：chmod 600 ~/.google_authenticator && chmod 700 ~。OpenSSH 的 StrictModes 会静默拒绝权限过松的文件，日志里只显示 authentication failure，无任何具体提示。

系统时间不同步导致验证码总失败

Google Authenticator 基于 TOTP，服务端和手机时间差超过 30 秒即失效。但很多人只记得 ntpdate 一次，却忽略 chronyd/ntpd 是否持续运行。

• 检查偏移：chronyc tracking（systemd-timesyncd 用户用 timedatectl status）
• 强制同步并确认服务活跃：sudo systemctl stop chronyd && sudo ntpdate -s pool.ntp.org && sudo systemctl start chronyd
• 验证是否生效：google-authenticator -t -d 会输出本地时间戳与期望窗口，比猜更可靠
• SELinux 启用时（如 CentOS 7 默认 enforcing），还需运行：sudo setsebool -P authlogin_nis_enabled 1，否则 PAM 模块读取密钥文件会被拦截

最隐蔽的坑是：你可能在 root 下跑了 google-authenticator，但实际想保护的是普通用户 deploy —— 每个用户必须用自己的身份单独运行该命令，.google_authenticator 文件必须归属该用户且不可被 group/o 写入。

结语

想要 SSH 双因子稳妥生效，需要规范 PAM 配置顺序、正确开启 SSH 交互认证，严控验证配置文件权限，保证服务端与客户端时间同步。遵循初始化关键选项标准配置，兼顾 SELinux 环境特殊设置，即可规避验证被静默绕过、验证码报错等问题，切实依靠双因子提升服务器登录安全等级。

以上关于SSH 谷歌双因子不弹验证码 校验失败 PAM 权限全故障排查教程的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。