SSH agent forwarding via the -A flag or the ForwardAgent yes directive allows using local private keys across intermediate bastion hosts without copying them remotely. However, this mechanism creates a UNIX socket that any user with root permissions on the jump server can hijack to authenticate against other systems across your network.
The mechanics of socket hijacking in SSH agent forwarding
OpenSSH stores the agent communication socket in a temporary path defined by the SSH_AUTH_SOCK environment variable on the remote host, typically under /tmp/ssh-XXXXXXXXXX/agent.<ppid>. While this file descriptor is restricted to the connected system user by default, the root user or any process with system-level capabilities on that intermediate server has read and write access to the socket.
When an attacker compromises a jump server, they do not need to extract your private keys, as the keys remain strictly in your local client memory. Instead, the attacker merely points to the hijacked environment variable and requests cryptographic signatures directly from your active local agent for as long as your session remains connected:
# Locate active agent sockets from other connected users on the bastion
ls -la /tmp/ssh-*/agent.*
# Hijack the socket to authenticate toward internal infrastructure
export SSH_AUTH_SOCK=/tmp/ssh-AbCdEf1234/agent.5678
ssh [email protected]Your local client running ssh-agent will sign the incoming challenge sent by the target host, unable to distinguish between commands you initiated and requests made by the attacker. This exposure turns any shared or perimeter bastion into an immediate horizontal privilege escalation bridge across your infrastructure.
Security comparison between Agent Forwarding and ProxyJump
The ProxyJump directive, introduced in modern OpenSSH versions and available through the -J command line flag, completely eliminates the need to expose an authentication agent on intermediary hosts. With ProxyJump, your local SSH client establishes an end-to-end encrypted TCP stream directly to the target system over standard stdio, utilizing the jump host purely as an oblivious transport router.
| Métrique de sécurité | Agent Forwarding (-A) | ProxyJump (-J) |
|---|---|---|
| Exposition du socket | Crée un socket UNIX lisible par le root distant. | Aucun socket d'authentification créé sur le serveur de rebond. |
| Chiffrement de session | Déchiffrement saut par saut à chaque frontière. | Chiffrement de bout en bout jusqu'à la cible finale. |
| Rayon d'impact en cas de compromission | Expose toutes les clés actuellement conservées dans l'agent. | Isole le trafic des intermédiaires compromis. |
| Standard de configuration | Mécanisme hérité ; propice aux erreurs de configuration. | Standard de l'industrie par défaut pour le SSH multi-sauts. |
By relying on ProxyJump, even if an attacker controls root on the intermediate bastion while you are connected, they only observe raw encrypted traffic passing to destination port 22. They have no access to arbitrary authentication signatures.
Configuring bastion hosts cleanly in ~/.ssh/config
OpenSSH enforces strict permissions of 700 on the ~/.ssh directory and 600 on the config file and private keys. Rather than enabling ForwardAgent yes globally—which creates significant security hazards—the recommended practice is defining declarative routing blocks inside your local configuration file:
# Hardened ~/.ssh/config configuration
Host bastion
HostName bastion.example.com
User admin
Port 22
IdentityFile ~/.ssh/id_ed25519
ForwardAgent no
Host internal-node
HostName 10.0.1.50
User deploy
IdentityFile ~/.ssh/id_production
ProxyJump bastionConnecting via ssh internal-node automatically connects through bastion using end-to-end authentication. Modern infrastructure setups should leverage Ed25519 keys, supported since OpenSSH 6.5 (January 2014), or hardware-backed FIDO2 keys (ed25519-sk), supported since OpenSSH 8.2 (February 2020). Note that legacy ssh-rsa signatures with SHA-1 have been disabled by default since OpenSSH 8.8 (September 2021).
Managing secure jump sessions and mobile workflows
On mobile platforms, keys generated inside the terminal SSH et Mosh pour iOS et Android termi1 remain secured inside the hardware keystore or Secure Enclave, ensuring that private keys never leave the device. When managing remote servers across variable mobile connections, Mosh maintains state seamlessly across Wi-Fi and mobile data transitions using UDP ports 60000-61000.
However, Mosh does not support port forwarding or agent tunneling. When accessing private hosts without public IP addresses or exposed ports, an alternative to traditional jump bastions is running mesh networks like réseaux maillés privés sans ports ouverts (Prialo) or Tailscale. A mesh overlay assigns direct private IP addresses to each node and mobile client, removing the need for multi-hop SSH bastions or agent forwarding altogether.
When classic bastion hosts are mandatory, mobile terminal features such as dedicated fn, Ctrl, and Esc keys prevent syntax blunders in production prompts, while features like Production Guard protect infrastructure by halting destructive commands before they execute on critical hosts.
Questions fréquentes
Quand est-il acceptable d'utiliser ssh -A avec l'agent forwarding ?
Le transfert d'agent SSH est acceptable uniquement lors d'une connexion temporaire à des serveurs dédiés de confiance sous votre contrôle direct. Sur des bastions partagés, tiers ou hébergés dans le cloud public, le transfert expose votre socket d'authentification et doit impérativement être remplacé par ProxyJump.
Un attaquant peut-il extraire ma clé privée via un socket détourné ?
Les clés privées ne peuvent pas être extraites d'un socket ssh-agent détourné, car elles ne quittent jamais la mémoire du client local. Un attaquant peut seulement exploiter le socket pour générer des signatures cryptographiques valides vers d'autres serveurs tant que votre session SSH demeure active.
Comment le flag ProxyJump remplace-t-il ForwardAgent en ligne de commande ?
L'option ProxyJump remplace le transfert d'agent en ligne de commande via la syntaxe -J sans modifier vos fichiers de configuration. Exécuter ssh -J user@bastion user@destination établit un canal chiffré de bout en bout vers votre cible, évitant totalement la création d'un socket d'agent sur le serveur intermédiaire.
Mosh prend-il en charge le SSH agent forwarding ou la redirection de ports ?
Mosh ne prend pas en charge le SSH agent forwarding, la redirection de ports TCP ou le transfert X11, car il fonctionne via UDP après la session SSH initiale. Pour gérer des infrastructures privées avec Mosh, connectez-vous via un réseau maillé comme Prialo ou utilisez SSH standard pour les bastions.