OpenVPN 登录中静态挑战码到底放在哪里

客户端在密码框之后又显示一个框，你把硬件令牌上的代码填进去，登录却仍然报认证错误。这个框存在，说明配置文件要求了它。服务器究竟有没有收到它看得懂的值，是另一个问题，而这个才值得先回答。

先从客户端实际显示的提示入手

配置文件可以带上静态挑战指令，其中包括提示字符串，以及一个控制输入时是否回显的开关。提示字符串就是对话框里看到的那句；开关只是同一个输入的显示偏好。两者都没有告诉服务器该如何校验任何东西。

数一数你实际拿到了几个框。一个用户名框加一个掩码框，就是没有挑战的普通密码登录。密码之后多出来的、自带标签的第二个框，才是客户端在实现挑战交互。

如果你用的客户端从不出现第二个框，可能是它没有实现这套交互，也可能只通过另一个前端（例如管理接口）来实现。检查客户端比改写配置更省事，而不匹配通常就出在这里。

配置文件只描述客户端该收集什么，并不会在服务器上启用校验。缺少相应认证集成的服务器，只会收到一个它不认识的密码。这就是为什么有些部署显示了提示却拒绝每一个验证码，也是为什么运维方关于由哪套机制执行校验的回答才是关键。

去问运维方，究竟由哪套机制执行校验。它可能是与 PAM 对接的插件、拿响应去令牌服务核对的脚本钩子，也可能是自行解析打包值的管理侧集成。每一种对输入的要求都略有不同。

这里同样需要校准预期。第二个提示只是输入机制，并不能证明第二因素真的被强制执行；强制发生在服务器一侧，只有当你用一个错误验证码去试时才会显现。

当前端通过管理接口驱动连接时，密码与挑战响应会在提交前被包进同一个值。管理接口参考文档描述了这一格式：先是一个前缀，随后密码与响应各作为一个 Base64 分量。

Base64 只是编码，不是保护。它对任何能读到该字段的人都藏不住东西，也不会把一次性验证码变成可重复使用的东西。打包后的值与密码一样需要谨慎对待：不进共享配置，不进命令行，也不进诊断日志。

这种编码也是最常见的混淆来源，因为现在有三种看起来相似、却不能互换的形态。明文凭据文件里放的是密码。把密码与验证码直接拼接得到的是另一个字符串。管理客户端打包后的响应又是第三种。只因为报错消失就改字段之前，先确认你的校验路径期望的是哪一种。

静态挑战在提交第一份凭据之前就已确定，客户端可以提前索要。动态挑战来得更晚，由认证流程在交互已经开始之后发出，需要客户端能处理会话中途的请求。

支持其中一个，并不等于支持另一个。配置静态提示的指令并不会实现服务器发起的挑战；而能处理动态请求的前端，也未必会显示静态挑战。看请求由哪一侧发起，是区分两者最快的方法。

无人值守运行才是这变成设计问题而非界面问题的地方。保存下来的验证码不是开机时可用的长久凭据；几小时后重连仍需重新输入，除非部署支持运维方刻意启用的令牌方案。

把测试的两半都跑一遍。正确凭据配有效响应应当成功；正确凭据配故意错误的响应应当被拒绝。如果两者都成功，说明客户端收集的输入没有任何东西在校验，对话框被误当成了控制手段。仅这一项测试，就能比任何配置复查抓出更多部署问题。

然后把连接在重连之后再重复一遍，用未登记的账号，并通过用户实际运行的客户端来做。出现提示是客户端的行为；拒绝错误验证码才是服务器在强制执行某件事。