If you’re still typing ssh -i ~/.ssh/id_ed25519_prod deploy@203.0.113.42 -p 2222, you’re wasting keystrokes on something SSH already solved. Put it in ~/.ssh/config once and never type it again.

The problem

Every server you manage tends to have its own quirks: a non-standard port, a specific key, a non-default username. You either retype the full command every time or keep a text file of commands to copy-paste from. Both are worse than the built-in fix.

1. Create the config file

touch ~/.ssh/config
chmod 600 ~/.ssh/config

The permissions matter — SSH silently ignores a config file that’s group- or world-readable on some setups, and you’ll be confused why your shortcuts “aren’t working.”

2. Add a host entry

Host prod
    HostName 203.0.113.42
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

Now ssh prod does everything that long command did. scp, rsync -e ssh, and even VS Code’s Remote-SSH extension all read this same file, so the shortcut works everywhere, not just for plain SSH.

3. Add every server you touch regularly

Host staging
    HostName 198.51.100.7
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod

Host db
    HostName 10.0.0.5
    User admin
    ProxyJump prod

That last one is worth calling out: ProxyJump tells SSH to tunnel through prod to reach a server that’s only reachable on a private network. Without it, you’d need a manual two-hop SSH command or a separate tunnel setup every time. With it, ssh db just works, jumping through prod transparently.

4. Use wildcards for shared settings

If most of your servers share a key and username, don’t repeat it in every block:

Host *.mycompany.internal
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod

Host prod
    HostName 203.0.113.42
    Port 2222

Host staging
    HostName 198.51.100.7

More specific Host blocks override the wildcard for matching settings, and SSH merges the rest. Order matters here — put specific hosts before broad wildcards, since SSH takes the first matching value for each setting, not the last.

5. Speed up repeated connections

If you SSH into the same box multiple times in a session (deploy script, then a manual check, then a log tail), each new connection pays a fresh TCP and auth handshake. Multiplexing reuses one connection:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 600

Create the sockets directory once (mkdir -p ~/.ssh/sockets), and every subsequent connection to the same host within 10 minutes reuses the existing one instead of renegotiating. The difference is most noticeable on high-latency connections or servers with slow SSH daemons — a connection that took a second or two now feels instant.

What actually breaks

Stale control sockets. If a connection drops uncleanly, the socket file can be left behind and new connections hang trying to use it. If ssh prod suddenly hangs instead of connecting, check ~/.ssh/sockets/ and delete the relevant file.

Config precedence surprises. Command-line flags still override the config file, and a more specific Host pattern earlier in the file wins over a broader one later — the opposite of how you might expect cascading to work. If a setting isn’t taking effect, run ssh -G prod to see exactly what SSH resolved for that host, rather than guessing.

The takeaway

Two minutes of setup turns every long SSH invocation you’ll ever type for a given server into a short alias — and it’s not just for you: anyone who clones your dotfiles gets the same shortcuts, and tools like rsync, git, and scp inherit them for free.