Every internal tool I need sits behind SSH.
Grafana, Prometheus, the staging clusters, internal AI tooling—none of it answers on a public address, and the only door is a bastion I have a key for.
That is the right setup for anything with real data behind it, and I wouldn't change it.
What I did change is typing from memory four times a day across three different machines.
So one weekend, I started writing SSH Config Manager.
It is a native macOS app that edits without wrecking formatting, saves tunnels as presets, and opens those tunnels in-process instead of shelling out to .
I wrote it for my own workflow first.
Putting it on the App Store came later, once it was genuinely useful to me and I figured others were struggling with the exact same friction.
The VPN Question The first thing people ask is: why not run a VPN and be done with it?
Fair question, but the honest answer is that SSH is the tool I already understand inside and out.
I have configured enough times to know what and actually change.
When a connection stops working, I can usually name the exact line that broke it.
A VPN introduces a whole second network layer underneath, complete with its own credentials, its own background daemon to keep patched, and its own unique failure modes to debug at 2:00 AM when production is down.
SSH is already on every Linux server I touch and every developer machine I own — there is nothing new to roll out and nothing new to secure.
The tradeoff is real, and I would rather acknowledge it up front.
Operating without a VPN means no transparent network routing: every internal service I want to reach must be explicitly forwarded to a local port in advance, and a colleague without my config reaches none of them.
Still, I would far rather maintain a clean list of port forwards than maintain another background daemon.
Shell Aliases Do Not Survive Three Machines The obvious fix for long commands is a set of shell functions.
In practice, that fell apart for me.
I use a MacBook Pro for most daily tasks, but ScyllaDB work happens on Linux because every team member uses Linux and the tooling assumes it.
Those environments don't agree on much—different shells, different key paths, and a different set of inventory hosts.
I never got dotfile synchronization into a state where SSH aliases were cleanly shared rather than messily merged.
The failure mode was predictable: an alias written on the laptop was missing on the remote machine where I needed it, or worse, pointed to a port that moved months ago.
The configuration file itself is the piece that is already portable and universally standardized.
Everything reads it out of the box: , , , and my editor's remote development plugins.
Building a tool around rather than shell scripts is the core design decision everything else flows from.
Nothing Tells You What Config Keys Mean Another friction point is that standard text editors treat as an arbitrary blob of text.
A misspelled directive isn't auto-completed or flagged—you find out at connect time when the setting you thought you configured was silently ignored.
The actual definition of what a keyword does lives inside the man page in a separate terminal window, which is exactly where you don't want to be toggling back and forth while editing.
To fix this, the app embeds a comprehensive keyword catalog. currently contains 95 entries, each specifying its canonical spelling, expected value type (string, integer, boolean, fixed enum, path, or list), category section, and a concise help string pulled directly from : That registry powers real-time auto-completion, a searchable "Add Setting" picker, and inline field documentation—eliminating second-guessing over whether it's or , or whether accepts a file path.
The editor engine is completely lossless.
Comments, blank lines, and custom indentation formatting stay untouched.
Only the modified directive gets rewritten on save.
This proved vital: my SSH configuration contains years of inline comments explaining