How to enable SSH agent forwarding

SSH agent forwarding enables reuse of local SSH keys on remote systems without copying private key files to every intermediate server. This is especially useful when connecting through bastion hosts or jump boxes where direct access from a workstation to internal hosts is restricted.

In a typical OpenSSH setup, a local ssh-agent process holds decrypted keys in memory and exposes a Unix domain socket path via the SSH_AUTH_SOCK environment variable. When agent forwarding is enabled, the remote server creates a temporary socket that tunnels back to the local agent over the encrypted connection, allowing remote processes to ask the agent to sign authentication challenges without ever receiving the private key material.

Forwarded agents remain powerful authentication endpoints for as long as the SSH session stays open, so a compromised remote host can use them to authenticate elsewhere. Safe use of agent forwarding relies on restricting which hosts receive forwarded agents, tightening /etc/ssh/sshd_config controls, and verifying that keys never persist on untrusted disks or in shared home directories.

Steps to enable SSH agent forwarding securely:

Open a terminal on the local workstation where the ssh-agent process runs.
```
$ echo "$SSH_AUTH_SOCK"
/tmp/ssh-V1NmuVPiia6g/agent.15847
```
SSH_AUTH_SOCK set to a non-empty path indicates that an agent socket is available to client programs.
List keys currently loaded in the local ssh-agent.
```
$ ssh-add -l
The agent has no identities.
```
If the agent reports The agent has no identities., load a key using ssh-add ~/.ssh/id_ed25519 before enabling forwarding.
Add the desired private key to the agent if it is not already listed.
```
$ ssh-add ~/.ssh/id_ed25519
Identity added: /home/user/.ssh/id_ed25519 (user@host)
```
Prefer modern ED25519 or ECDSA keys over older RSA keys unless interoperability requires otherwise.
Create or edit the personal SSH client configuration file /home/user/.ssh/config.
```
$ mkdir -p ~/.ssh
$ chmod 700 ~/.ssh
$ nano ~/.ssh/config
```
The /.ssh directory normally uses permission mode 700 so that only the account owner can read its contents.
Add a host-specific block that enables agent forwarding only for a trusted bastion host.
```
Host bastion
    HostName bastion.example.net
    User user
    ForwardAgent yes
```
Avoid placing ForwardAgent yes inside a global Host * block because every remote system would gain access to the local agent while sessions are active.
Save the client configuration file and close the editor.

The client automatically reloads ~/.ssh/config on the next connection attempt, so no daemon restart is required.
Connect to the trusted bastion host with agent forwarding enabled.
```
$ ssh -A user@bastion.example.net hostname
host
```
The -A flag forces agent forwarding for a single connection and pairs safely with host-specific ForwardAgent yes settings.
Inspect the agent-related environment variable on the bastion host to confirm that a forwarded socket is present.
```
$ ssh -A user@bastion.example.net "echo \"$SSH_AUTH_SOCK\""
/tmp/ssh-ZQt4r0OaYJ/agent.15878
```
A path under /tmp owned by the logged-in user indicates that a per-session forwarded socket has been created on the remote side.
List keys visible via the forwarded agent on the bastion host.
```
$ ssh -A user@bastion.example.net "ssh-add -l"
256 SHA256:f+q7HWwHs/zgRDYg5EMihaVDE1Xi94Zhru7p4/0Om8I user@host (ED25519)
```
The output should match the key list from the local workstation because the remote host is querying the same agent over the SSH tunnel.
Use the forwarded agent from the bastion host to reach an internal host without copying private key files.
```
$ ssh -A user@bastion.example.net "ssh app.internal.example hostname"
host
```
A hostile or compromised bastion can now authenticate to other systems with any key exposed via the forwarded agent while the session remains open.
On the bastion host, open the server configuration file /etc/ssh/sshd_config with root privileges.
```
$ sudo nano /etc/ssh/sshd_config
```
Incorrect edits in /etc/ssh/sshd_config can block new SSH logins, so ensure alternate console or out-of-band access exists.
Set a restrictive default and allow agent forwarding only for specific administrative users or groups.
```
AllowAgentForwarding no

Match User user
    AllowAgentForwarding yes
```
Placing AllowAgentForwarding no before the Match block disables forwarding globally while re-enabling it for the selected account, limiting blast radius if the host is compromised.
Validate the sshd configuration syntax before applying the change.
```
$ sudo sshd -t
```
No output from sshd -t indicates that the configuration syntax is valid for the running OpenSSH version.

Related: How to check and validate the SSH server configuration
Restart the ssh service so the updated server configuration takes effect.
```
$ sudo systemctl restart ssh
```
Restarting ssh terminates sessions that depend on old configuration, so avoid performing this step inside the only root shell on a remote system.

Related: How to manage the SSH server service with systemctl in Linux
From a new workstation session, confirm that agent forwarding works for the permitted account by listing forwarded identities.
```
$ ssh -A user@bastion.example.net "ssh-add -l"
256 SHA256:f+q7HWwHs/zgRDYg5EMihaVDE1Xi94Zhru7p4/0Om8I user@host (ED25519)
```
Seeing the local key list on the bastion confirms that agent forwarding is active for the allowed account.

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.