Mountain Duck SFTP：VPN 之后的第二次登录

VPN 已连接，菜单栏显示隧道，Mountain Duck 却仍然要求登录。接着它要求输入验证码。什么都没有坏：两个不同的系统在验证你，而第二个系统从未听过第一个。VPN 的多因素认证向网关证明了某件事。SFTP 服务器则要求它自己的凭证，对照它自己的账户。

两个提示，两个系统

网关和文件服务器是两个独立的策略域。它们可能共用同一个目录，也可能除了使用它们的人之外毫无共同点。在 VPN 上通过一次性验证码并不会在 SFTP 主机上建立会话，SFTP 主机也无从知道你究竟有没有使用隧道。每个系统都以为只有自己在提问。

把三者当作笔记里独立的三行。当其中一行失败时，那一行会告诉你该打开哪个控制台，而这已经是大半的工作。

使用 SFTP 管理员提供的地址

书签需要文件服务真正监听的主机名和端口，这未必是 VPN 服务器的地址。询问运行 SFTP 服务的管理员，并使用与其他客户端相同的主机名。

保持服务器身份校验完好。Mountain Duck 和 Cyberduck 会在首次连接时显示主机密钥，把它与管理员通过另一渠道提供的值进行比对，正是阻止错误服务器接收你凭据的那一步。为了让书签连上去而禁用该校验，是一个伪装成便利的永久决定。它还会抹掉你日后唯一的证据，证明文件确实去了你想去的地方。

回应服务器发来的挑战

该项目的 SFTP 文档描述了针对一次性验证码的挑战-响应支持：先是登录提示，随后在服务器要求时出现第二个验证码提示。这一流程属于服务器端的配置，客户端无法通过在密码字段里再存一个值来增加服务器侧的强制两步验证。

所以书签应当保存普通的账户凭证，验证码则在提示出现时手动输入。把会变化的验证码存成固定密码，得到的书签只能成功一次，之后失败的样子就和密码错误一样。把验证码填进 VPN 的凭证字段则会以另一种方式失败：网关直接拒绝，隧道根本不会建立。两个提示、两个位置，互换它们会让两边都失效。

自动挂载按不了按钮

如果书签在后台重新连接，交互式挑战就没有人来回答。挂载会不断重试，服务器反复索要，日志里塞满了不可能成功的尝试。这就是一项要求本人在场的策略的诚实结果。

把交互安排进流程：本人在场时连好隧道和书签，之后的自动重连就当作尽力而为。如果工作流确实需要无人值守的访问，服务器所有者必须批准另一种认证安排，而那是策略变更，不是书签设置。

挂载的卷不等于权限

挂载的卷只能证明会话通过了认证。它不能证明账户可以在这台服务器的任何位置写入。检查目标文件夹，尝试你真正需要的操作，而在答案重要时从服务器侧确认结果。Finder 的边栏显示的是一个卷，它对背后的权限只字不提。

换用其他协议时，请使用该提供方文档中的认证方式，而不是照搬这一套流程。云登录与 SSH 挑战在边栏里看起来可能一模一样，底层行为却完全不同。