NetworkManager 中缺少 OpenConnect 的 TOTP 提示：四项检查

网关接受密码、要求输入验证码，而对话框却没有提供任何输入框。并不是输入有误：NetworkManager 插件在没有要求六位数值的情况下就完成了凭据交换。请按顺序完成下面四项检查，因为其中只有一项会改变客户端。清单的其余部分则排除网关、账户和插件构建。

第一项检查：读出认证停在哪一步

密码错误会立即失败。缺少第二因素则会在凭据步骤之后失败，通常表现为反复提示或网关侧超时。时机和网关日志会说明哪一轮没有得到应答。

在改动配置文件之前先读连接日志。如果网关报告认证不完整或挑战超时，说明客户端从未发送验证码。如果报告凭据无效，问题就在密码上，任何 TOTP 设置都修不好。

记下网关要求的准确提示顺序：用户名、密码、然后验证码，或者用户名、验证码、然后密码。有些网关会调整轮次顺序，只知道第一种顺序的客户端会卡在第二种上。

第二项检查：使用掌握该挑战的客户端

OpenConnect 自身实现了包括挑战轮在内的完整对话，直接运行它是确认账户和网关正常的最可预测的方法。

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

客户端按网关要求的顺序提示。用户代理很重要，因为有些网关会针对已知客户端调整登录流程，通用字符串可能产生更短、从不索要验证码的流程。在安排任何后台服务之前，先在前台运行一次。

如果命令行提示正确，账户、网关和第二因素都没有问题。剩下的问题出在插件的对话框上，而不是认证服务。这样无需接触服务器就能隔离故障组件。把命令输出与事件记录放在一起。

如果命令行也跳过提示，就停下来和负责人一起检查网关配置。没有桌面客户端能回答服务器从不发送的挑战。

第三项检查：看你的插件是否提供 TOTP 模式

某些 NetworkManager OpenConnect 构建会在连接的 Identity 标签页中提供令牌模式和用户代理字段。把用户代理设为网关期望的值，选择手动输入 TOTP，然后保存连接。

这些字段是否存在取决于插件版本以及桌面使用哪个连接编辑器。独立编辑器可能显示 GNOME 面板隐藏的选项，也可能相反。寻找隐藏设置之前，先查看已安装包的版本。

如果令牌模式存在但提示仍不出现，说明该构建缺少插件与通用机密对话框之间的挑战交接。重新输入密码、重装同一个包或清空密钥环，都不会造出构建并未实现的字段。

第四项检查：把生成的验证码视为一种取舍

脚本可以调用 oathtool 获取当前验证码，并把用户名、密码和验证码送入 nmcli connection up --ask。这个流程可行，但共享密钥最终会存放在任何能打开脚本的人都能读到的地方，而该读者可以永久生成验证码。这是凭据暴露面的永久扩大，而不是客户端修复。

选择这种方式的人应把密钥文件限制为 root，把生成的值排除在 shell 历史之外，并把脚本当作凭据材料。把验证码回显到终端的包装脚本等于丢掉了第二因素。先用一次性账户测试该包装脚本。

脚本还必须遵循网关的提示顺序。如果服务器先要验证码再要密码，固定的输入顺序就会把错误的值送给错误的提示，产生同样的不完整认证。接入登录任务之前，先用测试账户演练。

确认是同一个网关和同一个账户

针对同一个网关、同一个账户和同一个隧道组测试每一种规避方案。还要求设备证书的网关可能以与 TOTP 无关的原因拒绝命令行客户端，提示顺序也可能与你演练的不同。

记录客户端、版本、用户代理和奏效的提示顺序。这份记录能告诉下一个人问题出在插件构建、网关流程还是账户策略上，而不必再来一轮密码重置。

完整注销后再连接一次作为收尾。缓存的密钥会让损坏的流程看起来已经修好，直到下一次会话；而缺失的提示通常会在第二次连接时回来。