01
Draw the path before testing credentials
Identify the local client, reachable bastion, and target address reachable from that bastion. The target’s private address does not need to be reachable directly from your laptop. The jump host does need a permitted path to the target SSH port.
In our lab the client could not connect directly to the target network. The jump host had the required second network interface. That distinction let us test a path problem separately from a bad target key.
02
Define the two hosts separately
Use independent host entries so the right user, port, and key apply to each hop. The example names and private address are placeholders. It assumes both public host keys have already been verified through trusted channels.
The local client retains both private keys. ForwardAgent no makes that intent explicit; do not copy the target private key to the jump machine. Different organizations may require certificates or other authentication methods instead of these example key files.
Host lab-bastion
HostName bastion.example.com
User gateway-user
IdentityFile ~/.ssh/bastion_ed25519
IdentitiesOnly yes
ForwardAgent no
Host private-app
HostName 10.20.1.15
User developer
IdentityFile ~/.ssh/app_ed25519
IdentitiesOnly yes
ProxyJump lab-bastion
ForwardAgent no03
Test the bastion, then the full route
First confirm that the bastion entry resolves correctly and permits the intended login. Next attempt a harmless command on the target with verbose output. Keep track of which host produced an authentication failure; the same short error can occur at either hop.
A forwarding refusal after successful bastion authentication can indicate a jump-host policy such as AllowTcpForwarding or PermitOpen. Have the administrator inspect the applicable restriction. Do not remove every forwarding restriction to solve one intended route.
ssh -G lab-bastion
ssh lab-bastion 'id -un'
ssh -v private-app 'id -un'04
Verify the result without an agent on the server
In the isolated reproduction, the direct connection failed, the ProxyJump connection returned our test marker, and the target session had no forwarded SSH_AUTH_SOCK. This confirmed that the target could be reached and authenticated without exposing an agent socket there.
For your own verification, check the target account and a harmless host identifier. Keep host-key checking enabled for both endpoints. The ability to log in to the bastion does not establish the identity of the final server.
ssh private-app 'id -un; hostname; test -z "$SSH_AUTH_SOCK" && printf "no forwarded agent\n"'05
Keep transport success separate from application health
A working SSH route proves access to the target SSH service. It does not prove that the application, database, or downstream dependencies are healthy. Continue with the particular service observation you needed the connection for.
If target DNS fails from the jump host, verify the name in that network’s resolver context. If the connection times out, inspect its route and port policy there. Keep the two-hop model visible so you do not repeatedly replace a valid key for a network failure.
Sınırları bil
Validated with a client and target on separate internal Docker networks and a jump host attached to both. The lab verifies transport and authentication behavior, not any specific cloud firewall or production network topology.
Kaynaklar ve ileri okuma
CoreTrailKit tarafından hazırlanan teknik yayın.
Bütün yazıları keşfet