ssh登录不提示验证码的根本原因是未启用pam或pam配置缺失：必须同时满足sshd_config中usepam yes、/etc/pam.d/sshd中正确添加pam_google_authenticator.so行（置于@include common-auth之前）、用户家目录下存在权限为600的~/.google_authenticator文件。
登录时只让输密码，完全不提示验证码
这是最典型的“静默失败”，表面看是登录卡住，实际是2FA根本没被触发。核心原因只有三个，缺一不可：
-
UsePAM yes没在/etc/ssh/sshd_config中启用 → PAM 配置压根不加载 -
/etc/pam.d/sshd里没加pam_google_authenticator.so行，或加在了@include common-auth之后 → 认证流程跳过了 2FA - 用户家目录下没有
~/.google_authenticator文件，或权限不是600，或属主不是该用户 → PAM 直接拒绝读取
检查顺序不能乱：先确认 sshd_config，再查 pam.d/sshd，最后用 ls -l ~username/.google_authenticator 看文件权限和归属。
登录报错“Authentication failure”但日志没线索
这时候别只盯着 auth.log 或 secure，要开 debug 模式抓真实拦截点：
- 临时启动一个调试用的 sshd：
sudo /usr/sbin/sshd -d -p 2222（-d 表示 debug），然后用ssh -p 2222 username@localhost登录，终端会直接打印每一步认证决策 - 常见输出如
auth [default=ignore] pam_google_authenticator.so后跟ignoring module，说明 PAM 模块被跳过，大概率是路径、权限或配置顺序问题 - 如果看到
error: Could not open /home/xxx/.google_authenticator: Permission denied，立刻检查 SELinux 是否开启（sestatus）或家目录是否挂载为noexec
能输密码，也能输验证码，但始终提示“Verification code incorrect”
时间偏差是头号杀手，TOTP 对时间精度要求极高：
- 服务端与手机时间差超过 ±90 秒（即 ±3 个 30 秒窗口）就会失败，不要调宽窗口，而要同步时间
- 运行
timedatectl status看是否启用 NTP；若未启用，执行sudo timedatectl set-ntp true - 手动校准一次：
sudo chronyd -q 'server time.google.com iburst'（CentOS/RHEL）或sudo ntpdate -s time.google.com（旧系统） - 别忽略硬件时钟：重启后时间漂移？执行
sudo hwclock --systohc写回 BIOS
SSH 登录成功了，但 CloudShell 或堡垒机里无法输入验证码
这不是配置错误，而是交互能力缺失 —— 这两类通道不支持 PAM 的 Challenge-Response 交互模式：
- CloudShell 工具、云厂商堡垒机、某些 Web SSH 终端，底层走的是非交互式 shell 启动流程，
read调用直接失败，验证码环节被跳过 - 现象是：你输完密码就直接进去了（绕过 2FA），或者直接报错退出
- 唯一解法是换通道：必须用原生 OpenSSH 客户端（
ssh user@host）或支持 PAM Challenge 的终端（如某些新版 MobaXterm） - 如果业务强依赖堡垒机，得确认其是否支持 RADIUS 或 SAML 接入 Google Authenticator，而不是靠本地 PAM
真正难的不是配通，而是配稳：时间不同步、SELinux 干预、PAM 加载顺序、非交互通道限制 —— 这些点任何一个松动，2FA 就会从安全锁变成登录拦路虎。
