Context
An engineer connects to a bastion and then signs in to an internal server using a forwarded SSH agent. The private key stays on the engineer's device, yet the intermediate machine receives a way to request signatures from that agent. Understanding that distinction is essential when choosing a jump-host workflow.
An SSH agent holds or brokers authentication identities. Forwarding makes an agent socket available across a connection; it does not grant the destination permission by itself. Before testing, identify approved hosts, client versions, required identities and independent recovery access. Keep host-key verification enabled and use a test identity with the minimum necessary access.
Inspect the current route
- Use
ssh -G internal.exampleto inspect the client's effective configuration without opening a session. Checkproxyjump,forwardagent,identityfile,identityagentandidentitiesonly. Replace the example with an approved host alias. Included configuration and matching host blocks can make the effective result different from the one line an engineer remembers editing. - Inspect the intended identities locally with
ssh-add -l. Fingerprints are more useful than private key contents. Avoid adding every organizational key just to troubleshoot a single destination. If authentication fails, capture redacted client debug output for that destination and distinguish offered identities from accepted ones; verbose output can reveal internal hostnames and account information. - Test a
ProxyJumproute in a separate session using the approved client configuration. ProxyJump carries the destination connection through an intermediate host while authentication to the final server is handled by the local client. Verify whether the workflow actually requires an agent socket on the jump host. An ordinary terminal-to-terminal habit may be the only reason forwarding was enabled.
An illustrative bastion risk
In an illustrative support environment, several administrators use a shared bastion. A broad Host * rule enables agent forwarding everywhere. A compromised privileged process on the bastion could access forwarded sockets and ask loaded identities to authenticate elsewhere. The correction is to review the workflow and restrict forwarding to demonstrated needs, rather than assuming that keeping key files local eliminates the exposure.
| Observation | Check | Meaning |
|---|---|---|
| Agent available on unexpected host | Effective ForwardAgent setting | Broad host match may enable forwarding |
| Wrong identities offered | ssh-add -l and identity-selection options | Agent contents exceed this connection's needs |
| Final server works through ProxyJump | Destination authentication evidence | Forwarding may be unnecessary |
| Failure occurs before final authentication | Jump-host connection and route | Investigate transport separately |
Correct and verify the workflow
Make configuration changes for a narrow host alias first. Preserve existing approved access while testing a fresh connection. If forwarding is required, document why and assess the trust level of the intermediate host. Identity constraints and confirmation features can help in supported agent/client combinations, but they need their own compatibility tests; a checkbox is not proof of effective restriction.
Verify the destination host key, final account and harmless remote command. Confirm whether an agent socket is present only where intended. Repeat the automation or file-transfer workflow that depends on the route, because interactive success alone may miss an integration requirement.
Maintain a connection inventory
Record each jump host, final destination, identity owner and forwarding exception. Review wildcard client rules when laptops or support images are rebuilt. Treat a compromised bastion as a reason to investigate agent use during affected sessions, not merely rotate a server host key. Clouvenix server hardening can help align access paths with a documented trust boundary.
Technical reference
OpenSSH forwarding guidance and client configuration reference.