Stop tunneling through Bastions when you can just use ProxyCommand

Technical Briefing | 9/18/2026

Most of us started by SSHing into a jump box and then SSHing again from there to the target server. It works, sure, but it turns your terminal history into a nightmare and makes port forwarding feel like an archeological dig. I once spent an hour trying to pipe a database dump through a double-hop tunnel because I had forgotten to set up an agent forward. That was the last time I did it the manual way.

Make your local config do the heavy lifting

You don’t need a fancy Zero Trust overlay to clean this up. You can bake the logic directly into your .ssh/config. By defining a ProxyCommand, your local SSH client handles the jump box handshake before it ever tries to authenticate with the internal node. It’s cleaner, it’s faster, and you can keep using your local tools like scp or rsync directly against the target host without copying files to the jump box first.

Host internal-server
HostName 10.0.5.22
ProxyCommand ssh -W %h:%p bastion.example.com

• Use the W flag to forward standard input and output through the bastion
• Keep your SSH agent running locally so your keys never touch the jump box
• Enable ControlMaster in your config to reuse existing connections for speed

If you are worried about security, this approach actually helps. It prevents the jump box from acting as a man-in-the-middle for your credentials because the authentication happens end-to-end between your workstation and the destination. You’re effectively treating the jump box as a transparent pipe, which is exactly how it should stay. Next time you have to debug a remote microservice, skip the double login and let the client handle the plumbing.