通过站点 VPN 对远程 ASA 进行 SSH：分步指南

你把 SSH 客户端指向远程 ASA 的内部地址，会话在连接阶段就中断了。防火墙从自己的站点应答，隧道也显示已建立，但 22 端口上没有任何监听。这类情况大多是因为数据包根本没到达管理准入，因为被测试的路径从未按管理路径设计。按下面的流程逐步排查，故障就不会再到处漂移。

选择你真正在管理的那个地址

三种设计看起来相似，行为却不同：访问 ASA 面向 VPN 的公网地址、通过 IPsec 访问内部接口、访问专用的管理接口。在动任何权限之前，先写下管理员的源地址、确切的目标地址和 TCP 22。后面的一切都取决于这一对。

承载两个服务器 VLAN 的隧道，可能根本不承载防火墙接口地址或管理员管理子网。检查站点到站点策略的感兴趣流量列表，确认 ASA 自身的地址作为目标出现，而不仅仅是穿过它的子网。

由于目标就是防火墙本身，管理准入与转发流量的规则是分开的。允许客户端访问 ASA 背后服务器的 ACL 并不会单独启用设备自身的 SSH 管理，修好转发规则也不会让这个故障移动。

management-access 是接口相关的

management-access 命令要求 ASA 在 VPN 到达时接受指向指定接口的管理连接。它不创建路由，不添加 SSH 权限，也不会同时作用于所有接口。如果目标接口不是被指定的那个，连接会在认证之前被丢弃。

这里有两个例外要留意。仅管理接口不在这个机制之内；ASA 9.20 管理指南指出，默认的 CiscoSSH 栈不支持经 VPN 的跨接口 SSH，而 ASA SSH 栈支持。在把时间花在路由上之前，先确认部署版本上实际生效的是哪个栈。

登录提示之前的四道关卡

在客户端和用户名提示之间有四道独立的关卡：管理地址对的路由与隧道匹配、允许 TCP 22 到达 ASA 地址的接口 ACL、覆盖管理员源地址的 ssh 权限，以及该用户的 AAA 认证。任何一道都可能丢弃数据包，却不告诉客户端是哪道关上的。

在改动任何东西之前，先用 packet-tracer 看哪道关卡失败：packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed。跟踪结果会指出 ACL、NAT 阶段和 to-the-box 判定，通常足以把路由问题和准入问题分开。

写窄权限，不要写宽权限

把权限限定在已批准的管理子网和接收隧道流量的接口上：ssh 10.10.5.0 255.255.255.0 inside。将其与 aaa authentication ssh console LOCAL 这类认证方式以及本地命名账户配合使用，而不是在外网接口上对所有源开放。

保持接口 ACL 与 ssh 权限一致。ACL 阻断的子网即使有权限也仍然失败；没有匹配 ssh 条目的子网即使 ACL 放行，也会在下一道关卡失败。两条语句从不同层次描述同一条路径，务必在运行配置中一起核对。

从指定主机验证，然后再次收窄

不要从自己的桌面，而是从指定的管理主机打开新会话，并在 ASA 上确认连接使用的是哪个源地址和接口。会话打开期间检查活动会话和运行配置中的 SSH 部分，然后关闭会话并删除为测试添加的任何临时权限。如果会话能建立但登录后立刻掉线，剩下的问题是授权而不是可达性。把接口和源地址记入变更记录，避免下一位重复诊断。

整个变更过程中保留控制台或另一条独立获批的恢复路径。私有路径打通之后，确认公网源地址和无关的 VPN 用户没有获得同样的访问权，因为一条对所有人都有效的管理路径，和你最初面对的问题并不是同一个问题。