Ping works but SSH fails over the VPN: which stage broke?
One verbose attempt separates TCP reachability, SSH transport, host identity, user login and session permission, so you stop guessing at the tunnel.
Ping replies and a refused SSH login can both be true at once, and the pair does not implicate the tunnel. Echo replies and a TCP connection to port 22 are different tests with different selectors, different policies and often different destinations. Capture one deliberate SSH attempt, then name the last stage it reached. That single artefact replaces a dozen speculative configuration changes.
Capture one attempt, not a session of pokes
Run the client once with verbose diagnostics, connection sharing disabled, and a bounded connect timeout. Disabling sharing matters because a previously authenticated master connection will otherwise answer for the new attempt and hide the failure you are chasing.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]Keep the destination, address family, timestamp and the final non-secret error. The IPv4 flag also means this attempt says nothing about an IPv6 path to the same name, so do not generalise from it. Record where the attempt was made from. A check run on the VPN gateway is not the same vantage point as a laptop behind it, and most contradictions in these tickets come from mixing the two.
Stages one and two: TCP before SSH
The first boundary is reachability of the socket: an address, a port and a route that the packet actually follows. If the TCP connection never completes, nothing above it exists yet, and host keys and accounts are irrelevant.
nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'Correlate the capture with the client attempt. A SYN leaving and nothing returning points at filtering, selectors or a missing route on the far side; a reply with a reset points at something actively refusing rather than dropping. The second boundary is the SSH protocol exchange itself. A TCP connection that completes and then stalls has moved past reachability and into negotiation, server response or packet handling. That is a different investigation, and it is where size-related problems first become plausible.
Stage three: whose key answered
Once the transport is up, the client verifies the server's host key. A rejection here is a statement about identity, not about cryptography: the peer presented a key that your policy does not accept. Treat that as a stop condition and verify out of band, against the console or the operator who rebuilt the host. Deleting the remembered entry to clear the warning is the one shortcut to refuse, because it destroys the evidence that something answered unexpectedly.
If the host really was rebuilt, remove the stale record only after the new fingerprint is confirmed, and note the date and reason. The next engineer will meet the same warning and needs that context.
Stages four and five: account versus permission
Authentication is the fourth boundary. A rejected credential means the server evaluated the attempt and refused it; check the account, the credential type the server accepts, and the server's own policy rather than the VPN password. The fifth boundary is authorization after successful login. An authenticated user can still be denied a shell, a command, a subsystem or forwarding, and those refusals look like failures to someone reading only the client's last line.
| Last stage reached | What it proves | Where to look next |
|---|---|---|
| No TCP connection | No SSH transport exists | Address, port, route, selectors, filter, listener |
| TCP up, exchange incomplete | Reachability is not the blocker | Server response, negotiation, packet handling |
| Host identity rejected | The peer is not the expected host | Independently verified host key |
| User authentication rejected | The attempt reached authentication | Account, credential and server policy |
| Authenticated, session denied | Login succeeded, the operation did not | Shell, command or forwarding permission |
Stop after a couple of failed password attempts. Repeated guesses produce lockouts that then look like a second, unrelated fault and cost more time than the original ticket.
Rollback and the record you keep
Change one thing at a time, and write down what you changed before you retest. If a change makes the attempt worse, revert it immediately instead of stacking another fix on top. Repeat the original operation from the original client and context. A successful login from a different machine, on a different address family, is not a reproduction and does not prove the fix.
Sanitise what you share. Verbose client output can carry internal names, account labels, key paths and public key identifiers, so publish the staged conclusion rather than a raw trace.