通过 VPN 的远程 SSH：隧道做不到什么
VPN 只是让 SSH 服务器变得可达，仅此而已。三个条件决定它是否合适，而失败阶段能指出是哪一层出了问题。
VPN 为 SSH 服务器提供一条私有路径，并免去在 22 端口上开放公共监听的需要。它不验证主机身份，不授权用户，也不决定哪些账户可以登录。这些仍然由 SSH 负责。VPN 是否是访问该服务器的正确方式取决于三个条件，而隧道只是可能的答案之一。
隧道改变了什么，SSH 仍然决定什么
隧道改变的是可达性：哪些地址可以从哪里访问。它不改变 TCP 连接建立之后发生的事，也就是服务器出示主机密钥并要求用户身份的那个阶段。
在头脑里和文档中都要把这两层分开。VPN 登录只能证明谁被允许使用网络。它不说明目标上存在哪些账户，也不是登录每一台可达机器的许可。
失败方式也是彼此独立的，而这正是这种区分在事故排查中有用的原因。
决定访问模型的三个条件
第一，服务器真的需要被网络之外的人访问吗？如果不需要，私有路径加跳板机或组网是更小的设计。第二，客户端群体能否真正运行 VPN 客户端，包括那些处在受限的受管设备上的人？
第三，你需要按服务控制还是按用户控制？VPN 授予的是网络可达，SSH 授予的是账户访问。如果要求是让一名外包人员只能到达一台主机而不能到达别处，那属于授权要求，单靠隧道无法表达。
回答这三个问题，模型会自己选出来。跳过它们，你最后就会为了让客户端不必铺开而把 SSH 暴露在公网上。
在归咎 SSH 之前先确认私有路径
连上获批的 VPN，使用目标文档中记录的私有名称或地址。然后检查选中的路由、网关的许可，以及回到客户端的返回路径。名称能正确解析并不能证明该地址走的正是预期的隧道，因为相互重叠的本地与远端前缀可能把请求送到完全不同的地方。这个区别值得写进操作手册。
如果连接始终建立不起来，先确认服务器确实在预期的接口上监听，并确认其主机防火墙放行了它实际看到的来源。网关的 NAT 可能改写该来源，因此按客户端隧道地址编写的允许列表可能永远匹配不上。
这种不匹配是 VPN 上最常见的自伤式 SSH 故障。
读失败阶段，而不是合成后的报错
三个阶段会产生三种不同的提示，而其中只有一种与凭据有关。
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
使用确切的错误和服务端自己的日志，而不是同时重置 VPN 与 SSH 两套凭据。两套一起重置，正是五分钟的诊断变成两天的身份事故的方式。
详细输出会显示你走到了哪个阶段：
ssh -vv [email protected]保持主机密钥与授权完整
通过既定的可信流程验证主机密钥，尤其是在更换服务器之后。意外的主机密钥变更警告，恰恰是不能因为 VPN 已连上就忽略的提示，因为私有隧道并不会让目标变成你以为的那台机器。要拿指纹与独立于本次连接的来源比对。
在服务端，确认该账户已被授权，并且实际提供的正是你配置的认证方式。密钥存在却被忽略，通常是权限或配置问题，而不是网络问题。
把服务访问限制在需要的身份范围内，并为网络变更保留一条经过授权的恢复路径。