Diagnosing SSH Jump Host (ProxyJump) Connection Failures

Problem Statement

You can reach a target server directly, but routing through an intermediate jump host with ssh -J or ProxyJump fails. The connection may time out, refuse, or abort with a host-key or authentication error. The goal is to determine whether the failure lies on the client, the jump host, the network path between them, or the target server.

Recognizable Symptom

Direct SSH to the target works, but a proxied connection does not. Common client-side errors include:

• ssh: connect to host bastion.example.com port 22: Connection refused
• ssh: connect to host bastion.example.com port 22: Connection timed out
• kex_exchange_identification: Connection closed by remote host
• Permission denied (publickey,keyboard-interactive)
• Host key verification failed

A hang with no output after entering the command also indicates the client never completed the jump.

Cause-Diagnostic Table

Cause	Diagnostic Hint
Jump host unreachable	Direct ssh to the bastion fails or nc -z to port 22 times out
ProxyJump syntax incorrect	ssh -vvv shows no jump attempt; config uses invalid ProxyJump format
Authentication fails on jump host	Direct ssh user@bastion prompts for password or rejects the key
Host key mismatch	Verbose output shows Host key verification failed or a changed fingerprint warning
Jump host blocks forwarding	sshd -T on the bastion shows AllowTcpForwarding no
SSH config override	A later Host block or global setting overrides ProxyJump

Ordered Checks & Fixes

1. 1. Confirm the jump host is reachable

   Run on the client (no special permissions required):

   ssh -vvv -o ProxyJump=none [contact removed]
   # or
   nc -z bastion.example.com 22 && echo "port open" || echo "port closed"
   

   Expected: an SSH banner or succeeded!. If the connection is refused or times out, the problem is network-level or the bastion sshd is not running. Fix firewall rules, security groups, or start the bastion SSH service before continuing.

2. 2. Validate ProxyJump syntax

   On the client, check ~/.ssh/config or the command line. A valid config block looks like:

   Host bastion
       HostName bastion.example.com
       User bob
   
   Host target
       HostName 10.0.0.5
       User alice
       ProxyJump bastion
   

   Equivalent command line:

   ssh -J [contact removed] alice@10.0.0.5
   

   Risk: omitting the user in -J or using an undefined host alias causes the client to ignore the jump. Correct the config or flag, then retry.

3. 3. Authenticate to the jump host directly

   Run on the client:

   ssh [contact removed]
   

   Expected: a shell prompt or password challenge. If this fails, load the correct key:

   ssh-add -l
   # If empty:
   ssh-add ~/.ssh/id_ed25519
   

   Risk: loading keys you do not intend to use exposes them to the agent. Add only the bastion key.

4. 4. Inspect host keys and known_hosts

   Run on the client with verbose output:

   ssh -vvv -J [contact removed] alice@10.0.0.5
   

   Look for Host key verification failed or a changed-fingerprint warning for the bastion or target. A stale entry in ~/.ssh/known_hosts can abort the connection before authentication.

   To remove a stale entry:

   ssh-keygen -R bastion.example.com
   ssh-keygen -R 10.0.0.5
   

   Risk: removing host keys disables man-in-the-middle verification for that host. Re-accept the fingerprint only after confirming it out of band.

5. 5. Verify the jump host permits forwarding

   Run on the jump host (requires shell access, typically root or sudo):

   sshd -T | grep -E 'AllowTcpForwarding|GatewayPorts|AllowAgentForwarding'
   

   Expected: AllowTcpForwarding yes. If it shows no, edit /etc/ssh/sshd_config:

   AllowTcpForwarding yes
   

   Then restart the SSH service:

   sudo systemctl restart sshd
   

   Check for Match blocks that may override the global setting for your user or group. Rollback: revert AllowTcpForwarding to its previous value and restart sshd if the change causes unintended exposure.

6. 6. Test the full path verbosely

   Run on the client:

   ssh -vvv -J [contact removed] alice@10.0.0.5
   

   Look for channel 2: open and Authentication succeeded. If the channel never opens, the jump host accepted the connection but could not reach the target.

Escalation Criteria

After the checks above, involve the system or network administrator if:

• Direct SSH to the bastion works, but the proxied connection still fails.
• The bastion logs (journalctl -u sshd) show dropped connections to the target subnet.
• Firewall rules, security groups, or SELinux/AppArmor policies block traffic from the jump host to the target.
• Custom Match blocks in sshd_config disable forwarding for your user or group.

Capture the verbose client output and the bastion sshd log lines before escalating.

Limitations & Practical Checks

• These steps assume you have access to the client and the jump host; root or sudo is required to modify sshd_config on the bastion.
• Some distributions use service ssh restart instead of systemctl restart sshd.
• Test configuration changes in a staging environment before applying them to production bastion hosts.
• ProxyJump trusts the intermediate host. Do not chain through untrusted jump hosts, and limit forwarded keys with IdentityFile where appropriate.

Practical Example

An operator runs:

ssh -J [contact removed] alice@10.0.0.5
ssh: connect to host bastion.example.com port 22: Connection timed out

Running nc -z bastion.example.com 22 also times out. The client cannot reach the bastion. After the network team adds an inbound SSH rule from the operator's subnet to the bastion security group, nc -z bastion.example.com 22 succeeds and the proxied SSH connection completes.

Conclusion

SSH jump host failures usually separate into reachability, syntax, authentication, host-key, and forwarding categories. By checking the bastion first, validating ProxyJump syntax, and verifying forwarding on the intermediate host, you can isolate the layer that is breaking and apply the correct fix.