SSH Agent Forwarding: Safer Bastion Connections

SSH agent forwarding lets a remote host ask your local agent to perform authentication operations. It does not normally copy the private key file to that host, but it can still let a compromised remote environment use your available credentials while forwarding is active. Keep it disabled unless a specific workflow needs it.

For reaching a server through a bastion, a jump connection is often the clearer design. The important distinction is where authentication happens and which machine can request use of your agent. A key remaining on your laptop does not eliminate every risk.

Draw the connection before changing settings

List your workstation, bastion and destination. Decide whether the destination connection is initiated by your local SSH client or by a shell running on the bastion. These are different trust arrangements.

With a local jump connection, the workstation can authenticate to the destination through the bastion's transport. With a forwarded agent and a remote shell, software on the bastion may access the forwarded agent socket. That software becomes part of the credential-use boundary.

Use the OpenSSH configuration manual to confirm the behavior of ForwardAgent and ProxyJump for your client version. Avoid copying an entire configuration from an unrelated system merely to make a single connection work.

Prefer explicit per-host configuration

Host bastion
  HostName bastion.example.net
  User deploy
  ForwardAgent no

Host production
  HostName app.internal
  User deploy
  ProxyJump bastion
  ForwardAgent no

This example shows intent rather than a complete production policy. Use your actual hostnames and authorized accounts. Keep host-key verification enabled for both the bastion and the destination; the jump does not make the destination's identity irrelevant.

Inspect changes with Text Diff, using redacted hostnames if the configuration is sensitive. Pay attention to wildcard sections and ordering. A broad default elsewhere in the file may override the behavior you thought was local to one host.

What a forwarded agent can expose

A forwarded agent socket offers an authentication capability. A privileged attacker or compromised software on the remote host may be able to request operations through it. The private key need not be exported for an unwanted authentication to occur.

Limit the identities available in the agent, how long they remain available and whether user confirmation is required where supported. These controls reduce exposure but do not turn an untrusted host into a safe place to forward credentials.

Do not forward a workstation agent to a server used for experimenting with unknown repositories or scripts. Keep development experiments separate from accounts that can reach production. A convenient connection path should not silently combine those privileges.

Check the effective settings

Use the SSH client's effective-configuration output to inspect the selected host rather than reading only the visible stanza:

ssh -G production

Review the jump configuration, identity files and agent-forwarding setting in that output. Do not publish the complete output if it reveals internal hosts or account names; extract only what a reviewer needs.

During an authorized test, verify whether the remote environment exposes an agent socket and whether that is expected. Do not enumerate or use another user's agent. The purpose is to establish your own connection boundary, not to probe credentials on a shared machine.

If forwarding is genuinely necessary

Document why the remote process must authenticate onward and which destinations it needs. Use a dedicated limited identity rather than every key from your normal agent. Prefer short-lived credentials and a narrow destination policy when the infrastructure supports them.

Close the forwarded session when the work is complete. Review long-running multiplexed connections too: a terminal window closing may not be the same as the underlying authenticated connection ending. Understand how your client manages persistent connections.

Keep third-party commands out of the session until their origin and behavior are understood. An agent socket is a resource available to processes in that environment. Shell access and credential-use access should therefore be assessed together.

Avoid the most common workarounds

Copying a private key to the bastion changes the risk rather than solving it. The key may be retained in backups, home directories or shell history if handled poorly. Disabling host-key checking introduces a separate server-identity problem.

Also avoid a global ForwardAgent yes rule. It applies a sensitive capability to future hosts that were not part of the original decision. Configuration changes should identify the required host and use case explicitly.

A practical review checklist

Confirm who controls the bastion, which account is used, which identities the agent contains and whether forwarding is actually required. Check effective configuration, verify both host identities and record the approved connection path. Revisit the decision when the bastion's purpose or users change.

For an unexpected server fingerprint, follow SSH Host Key Verification before investigating onward authentication. Trustworthy transport and limited credential use are complementary controls.

Keep the workstation as the authentication boundary

Prefer a local jump connection where it meets the workflow. When forwarding is necessary, restrict and document it. The right result is a working connection with a clear credential-use boundary, not merely a private key file that stayed on disk.