SSH to a Remote ASA Through the Site VPN: Step by Step

You point an SSH client at the remote ASA inside address and the session dies at connect. The firewall answers from its own site, the tunnel shows up, and yet nothing listens on port 22. In most of these cases the packet never reaches management admission, because the path being tested was never designed as a management path. Walk the flow below in order and the failure stops moving around.

Pick the address you are actually administering

Three designs look similar and behave differently: reaching the ASA public VPN-facing address, reaching an internal interface through IPsec, and reaching a dedicated management interface. Write down the administrator source address, the exact destination address and TCP 22 before touching a permission. Everything later depends on that pair.

A tunnel that carries two server VLANs may not carry the firewall interface address or the administrator management subnet at all. Check the interesting traffic list for the site-to-site policy and confirm the ASA's own address appears as a destination, not just the subnets passing through it.

Because the destination is the firewall itself, management admission is separate from rules for forwarded traffic. An ACL that lets clients reach servers behind the ASA does not independently enable SSH administration of the appliance, and fixing the forwarded rule will not move this failure.

management-access is interface-specific

The management-access command tells the ASA to accept management connections to a named interface when they arrive over VPN. It does not create a route, it does not add an SSH permission, and it does not apply to every interface at once. If the destination interface is not the one named, the connection is discarded before authentication.

Two exclusions bite here. Management-only interfaces are outside this mechanism, and the ASA 9.20 management guide notes that the default CiscoSSH stack does not support cross-interface SSH over VPN while the ASA SSH stack does. Confirm the active stack on the deployed release before you spend time on routes.

Four gates before the login prompt

Between the client and the username prompt sit four independent gates: a route and tunnel match for the management pair, an interface ACL that permits TCP 22 to the ASA address, an ssh permission covering the administrator source, and AAA authentication for that user. Each one can drop the packet without telling the client which gate closed.

Use packet-tracer to see which gate fails before you change anything: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. The trace names the ACL, the NAT stage and the to-the-box decision, which is usually enough to separate a routing problem from an admission problem.

Write the narrow permission, not the broad one

Scope the permission to the approved administrative subnet and the interface that receives the tunnel traffic: ssh 10.10.5.0 255.255.255.0 inside. Pair it with an authentication method such as aaa authentication ssh console LOCAL and a named local account, rather than opening every source on the outside interface.

Keep the interface ACL and the ssh permission consistent. A permission for a subnet that the ACL blocks still fails, and an ACL that permits the subnet without a matching ssh entry fails at the next gate. Both statements describe the same path from different layers, so review them together in the running config.

Verify from the named host, then narrow again

Open a fresh session from the named management host rather than from your desk, and confirm on the ASA which source address and interface the connection used. Check the active sessions and the SSH section of the running config while the session is up, then close it and remove any temporary permission you added for testing. If the session appears but drops right after login, the remaining problem is authorization rather than reachability. Record the interface and source in the change record so the next person does not repeat the diagnosis.

Keep console or another independently approved recovery path available for the whole change. Once the private path works, confirm that public sources and unrelated VPN users did not gain the same access, because a management path that works for everyone is a different problem than the one you started with.