SSH报错“Permission denied (publickey)”常因未启用两步验证组合认证，需在sshd_config中配置AuthenticationMethods publickey,keyboard-interactive，并确保PAM模块正确加载，客户端使用ssh -o RequestTTY=yes触发OTP输入。
SSH 连接报错 Permission denied (publickey) 但密钥明明没问题
这大概率不是密钥问题，而是服务器启用了两步验证（如 google authenticator）后，sshd 默认仍走标准公钥流程，没触发二次挑战。openssh 6.2+ 支持 authenticationmethods，必须显式要求“公钥 + otp”组合认证，否则客户端连尝试输入验证码的机会都没有。
实操建议：
- 确认服务器已安装并配置好 PAM 模块（如
libpam-google-authenticator），且/etc/pam.d/sshd包含对应行（例如auth [success=ok default=ignore] pam_google_authenticator.so） - 在
/etc/ssh/sshd_config中启用组合认证：AuthenticationMethods publickey,keyboard-interactive
- 重启服务：
sudo systemctl restart sshd - 客户端连接时需确保支持 keyboard-interactive（OpenSSH 7.0+ 默认开启），旧版
ssh可能静默跳过二次提示
用 ssh 命令手动触发两步验证失败，终端直接退出
常见原因是客户端未启用交互式认证协商，或终端不支持密码/OTP 输入回显控制。OpenSSH 默认对非 TTY 环境（比如管道、脚本中）禁用 keyboard-interactive，导致认证链断在第二步。
实操建议：
- 强制分配伪终端：
ssh -o RequestTTY=yes user@host - 避免重定向输入输出（如
ssh ... ），会抑制交互提示 - 检查
ssh -v user@host输出，确认是否出现debug1: Next authentication method: keyboard-interactive—— 没这行说明服务端没下发挑战，或客户端拒绝了该方法 - 某些终端（如 Windows PowerShell 默认）对 ANSI 控制字符处理异常，换用
cmd.exe或 Windows Terminal 再试
~/.ssh/config 里配了 PreferredAuthentications 却没生效
这个配置项只影响客户端发起的认证方法顺序，不强制要求服务端接受。如果服务端 sshd_config 未设置 AuthenticationMethods，客户端即使声明要 publickey,keyboard-interactive，服务端也可能只返回 publickey 单一选项，后续步骤直接跳过。
实操建议：
-
PreferredAuthentications仅作协商提示，不能替代服务端策略。真正起作用的是服务端的AuthenticationMethods - 若想跳过密码（仅用密钥+OTP），必须设为：
PreferredAuthentications publickey,keyboard-interactive
，且不能包含password - 注意拼写：是
keyboard-interactive，不是keyboard_interactive或keyboardinteractive，错一个字符就失效
用 mosh 或 tmux 复用会话时两步验证反复触发
Mosh 不走 SSH 协议栈，完全绕过 sshd 的认证逻辑；而 tmux 会话复用依赖于原始 SSH 连接的 auth socket，一旦连接断开再连，PAM 挑战重新触发。这不是 bug，是协议分层导致的必然行为。
实操建议：
- 别用 mosh 连接启用了两步验证的服务器 —— 它根本不支持 keyboard-interactive，连建立连接都做不到
- 对 tmux，用
ssh -o ControlMaster=auto -o ControlPersist=60s启用连接复用，后续ssh子命令共享同一认证通道，避免重复输 OTP - 如需免 OTP 的后台任务，单独建一个无两步验证的受限用户（通过
Match User在sshd_config中排除），切勿关闭主用户的两步验证
sshd_config 里漏掉 AuthenticationMethods，或者 PAM 配置路径写错成 /etc/pam.d/ssh（正确应为 /etc/pam.d/sshd）。
