Asaduzzaman Pavel

Practical Look at SSH Config: From Spaghetti to Sanity

For a long time, my "workflow" was just a series of Ctrl+R searches in my shell history, hoping to find that one specific IP address or long-forgotten identity file flag. It was "SSH Spaghetti." It worked, but it was friction-heavy.

The moment I realized I needed a better way was when our team moved behind a Bastion host (Jump Box). Suddenly, every time I wanted to check a log or run a quick query on an internal DB, I had to SSH into the Bastion, authenticate again, and then SSH into the internal server. It was exhausting. It broke my flow.

ProxyJump: Making the Infrastructure Transparent

When I discovered ProxyJump, it felt like magic. I could define my Bastion and my internal servers once, and suddenly I was back to a single command: ssh internal-db. SSH handles the tunneling and identity forwarding behind the scenes.

Host bastion
  HostName 1.2.3.4
  User admin
  IdentityFile ~/.ssh/id_ed25519

Host internal-db
  HostName 10.0.1.50
  User postgres
  ProxyJump bastion

Instant Connections with Multiplexing

The second major shift was discovering Multiplexing (via ControlMaster). I often have three terminal windows open for the same server—one for htop, one for logs, and one for a shell. I was used to the 2-3 second delay of the SSH handshake every time I opened a new tab.

Setting up connection reuse changed everything. The first connection took its usual time, but the second and third were instantaneous. It made the remote server feel like it was running locally.

The Orphaned Socket Headache

...And then I realized that if the master connection hangs or the server reboots while I have multiple tabs open, the ControlPath socket gets orphaned. You’ll try to SSH back in and get some cryptic error about the socket already being in use, or worse, it’ll just hang indefinitely. I ended up having to write a tiny shell alias just to rm -rf ~/.ssh/sockets/* when things get weird. It's a trade-off I’m willing to make, but it's not the "fire and forget" solution people claim it is.

The IdentityFile Trap

I once spent an hour debugging why I couldn't SSH into a new staging box. Turns out, because I had too many keys in my ssh-agent, the server was rejecting me for "Too many authentication failures" before it even got to the right key.

The fix is IdentitiesOnly yes. It tells SSH to only use the key specified for that host, rather than trying every key in your agent like a brute-force attacker. It’s one of those things I think everyone should just have in their Host * defaults, but I’m not 100% sure if it breaks some edge cases with hardware tokens.

Keep-Alives (A Bit of a Guess)

I use ServerAliveInterval 60 and ServerAliveCountMax 3, but honestly, those numbers are a total guess based on what seemed to work for my home office's flaky Wi-Fi. It stops those annoying "Broken Pipe" disconnects during my morning coffee breaks, but I’ve also seen it keep a "zombie" connection alive for 10 minutes after I’ve closed my laptop lid.

Host *
  ServerAliveInterval 60
  ServerAliveCountMax 3
  IdentitiesOnly yes
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h:%p
  ControlPersist 10m

The real win here isn't saving a few seconds—it's removing the mental overhead of "getting there." Now, whether I'm jumping through a triple-bastion setup or just checking a dev box, the experience is identical. It’s the "commute" of my workday, and I finally stopped dreading it.

Asaduzzaman Pavel

About the Author

Asaduzzaman Pavel is a Software Engineer who actually enjoys the friction of a well-architected system. He has over 15 years of experience building high-performance backends and infrastructure that can actually handle the real-world chaos of scale.

Currently looking for new opportunities to build something amazing.