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:

  1. Open a terminal on the local workstation where the ssh-agent process runs.
    $ echo "$SSH_AUTH_SOCK"
    /run/user/1000/keyring/ssh

    SSH_AUTH_SOCK set to a non-empty path indicates that an agent socket is available to client programs.

  2. List keys currently loaded in the local ssh-agent.
    $ ssh-add -l
    256 SHA256:O0CqvWQz7b8QGQGzZlT3xgP5WbqQm2YF9oZLxJmFv4k /home/user/.ssh/id_ed25519 (ED25519)

    If the agent reports The agent has no identities., load a key using ssh-add ~/.ssh/id_ed25519 before enabling forwarding.

  3. Add the desired private key to the agent if it is not already listed.
    $ ssh-add ~/.ssh/id_ed25519
    Enter passphrase for /home/user/.ssh/id_ed25519:
    Identity added: /home/user/.ssh/id_ed25519 (/home/user/.ssh/id_ed25519)

    Prefer modern ED25519 or ECDSA keys over older RSA keys unless interoperability requires otherwise.

  4. 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.

  5. Add a host-specific block that enables agent forwarding only for a trusted bastion host.
    Host bastion
        HostName bastion.example.com
        User deploy
        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.

  6. 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.

  7. Connect to the trusted bastion host with agent forwarding enabled.
    $ ssh -A bastion
    Welcome to Ubuntu 22.04 LTS
    ##### snipped #####

    The -A flag forces agent forwarding for a single connection and pairs safely with host-specific ForwardAgent yes settings.

  8. Inspect the agent-related environment variable on the bastion host to confirm that a forwarded socket is present.
    $ echo "$SSH_AUTH_SOCK"
    /tmp/ssh-abc12345/agent.1234

    A path under /tmp owned by the logged-in user indicates that a per-session forwarded socket has been created on the remote side.

  9. List keys visible via the forwarded agent on the bastion host.
    $ ssh-add -l
    256 SHA256:O0CqvWQz7b8QGQGzZlT3xgP5WbqQm2YF9oZLxJmFv4k /home/user/.ssh/id_ed25519 (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.

  10. Use the forwarded agent from the bastion host to reach an internal host without copying private key files.
    $ ssh app01.internal
    Welcome to Ubuntu 22.04 LTS
    ##### snipped #####

    A hostile or compromised bastion can now authenticate to other systems with any key exposed via the forwarded agent while the session remains open.

  11. 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.

  12. Set a restrictive default and allow agent forwarding only for specific administrative users or groups.
    AllowAgentForwarding no
    
    Match User deploy
        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.

  13. 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.

  14. 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.

  15. From a new workstation session, confirm that agent forwarding works only for the permitted user and is rejected for a disallowed account.
    $ ssh -A deploy@bastion.example.com 'ssh-add -l | head -n 1'
    256 SHA256:O0CqvWQz7b8QGQGzZlT3xgP5WbqQm2YF9oZLxJmFv4k /home/deploy/.ssh/id_ed25519 (ED25519)
    $ ssh -A otheruser@bastion.example.com 'ssh-add -l'
    The agent has no identities.
    error fetching identities: agent refused operation

    Differing results for the two accounts verify that server-side AllowAgentForwarding restrictions are active while client-side ForwardAgent continues to work for trusted principals.

  16. Verify that no private key files were copied to the bastion host by inspecting the remote /home/user/.ssh directory.
    $ ls -l ~/.ssh
    total 4
    -rw------- 1 deploy deploy 740 Jun  1 12:00 authorized_keys

    The absence of private key files such as id_ed25519 or id_rsa on the remote host confirms that authentication relies solely on the forwarded agent.

Discuss the article:

Comment anonymously. Login not required.