Stop carrying your SSH keys into the danger zone

Technical Briefing | 7/20/2026

I see it all the time. Someone needs to debug a production database, so they SSH into a bastion, then SSH again into the target. They’ve got their local SSH agent forwarded, meaning the target server technically has access to the private key sitting on their laptop. If that target server is compromised, you just handed over the keys to your entire kingdom.

Why agent forwarding is a trap

The socket created by forwarding your agent essentially lives in /tmp on the remote host. Any user on that box with root access can grab that socket and authenticate as you to any other server you have access to. It is the classic lateral movement vector. We used to do it because it was easy, but in a zero-trust world, it is a massive liability.

ssh -o ProxyCommand='ssh -W %h:%p jump-host' target-server

• Use ProxyJump in your ssh_config to avoid loading the agent on the intermediary
• Stop adding the -A flag to your terminal aliases just to make life easier
• Keep your identity keys isolated from transient or high-risk jump hosts

Shift the trust to the config file

By using ProxyJump, you are telling your local SSH client to pipe the connection through the jump host without ever presenting your credentials to it. The intermediate server is just a dumb relay. It doesn’t see your key, it doesn’t see your agent, and it certainly doesn’t get to impersonate you to the rest of the fleet. It is a small config change that saves you from a massive headache if a bastion host ever gets popped.

Audit your ~/.ssh/config today. If you see ForwardAgent yes under any host block, rip it out. You can handle the extra seconds it takes to copy a file or fetch a secret without needing your keys ghosting around your infrastructure.