If you maintain WordPress sites across more than a couple of servers, you've probably typed a command like more times than you'd like.
Remembering the right key path, port number, and username for each server isn't realistic, and copying a similar-looking command from shell history is exactly how you end up connecting to the wrong box. solves this by letting you collect per-host settings in one file.
Note: is a file read by the OpenSSH client — it's not a server-side setting.
It lives on your local machine (Mac/Linux/Windows SSH client) and teaches it how to reach each server, typically with just a few lines per host.
Basic structure A minimal block looks like this: Once saved, you can connect with: here is an alias — an arbitrary string, unrelated to the actual hostname. and can use the same alias, so just works.
You no longer need to pass the port or username on the command line every time, and there's no chance of mistyping the key path.
Why matters Specifying alone isn't quite enough.
Without , the OpenSSH client will offer the specified key plus any other keys registered with .
If the server enforces a limit on authentication attempts (), or runs something like fail2ban that temporarily blocks an IP after repeated failed auth attempts, offering several unintended keys before reaching the correct one can get your connection blocked before it ever succeeds. restricts the client to only the key explicitly listed in that block, which avoids the extra authentication attempts.
If you keep separate keys for different projects or separate personal and work use, this option is effectively mandatory.
Grouping shared settings across similar servers with wildcards When you have several servers with similar setups, supports wildcard patterns so you can group shared settings: OpenSSH reads the config file top to bottom and keeps the first value it finds for a given option — later matching blocks don't override earlier ones.
That means specific blocks need to come before the wildcard block.
If were placed first, the individual blocks' values would never be read, and every alias would try to connect to the same server. sends a keepalive packet every 30 seconds, which matters on networks that drop idle connections (some routers and firewalls do this).
It's particularly useful when running a long backup job over SSH that you don't want interrupted mid-way.
Splitting the config file with As the number of projects grows, cramming every server into a single gets hard to navigate.
OpenSSH 7.3 and later supports an directive to split the file up: Keeping one file per project or client under means that when a project ends, you delete one file and the cleanup is done. expands exactly where it's written, so whether you place it before or after a catch-all block changes which settings take precedence — worth keeping in mind.
How this differs from WP-CLI aliases Using WP-CLI aliases to switch between multiple WordPress environments safely covered aliases, which manage "which WordPress site a command runs against" at the application layer — inside WP-CLI itself. operates one layer down, at the OS's SSH client, managing "how to connect to which server" in the first place.
The two are independent, but combining them compounds the benefit. organizes the connection itself; WP-CLI aliases then organize the sites within each server.
Together, both the connection command and the site-targeting command stay short and less error-prone.
A security note stores hostnames, IP addresses, and port numbers in plain text.
As a baseline, keep the file's permissions at (readable/writable only by you) — some OpenSSH client implementations will warn if permissions are looser than that.
It's also worth being deliberate about not committing this file to a Git repository by accident, since that would leak internal connection details externally. is typically outside any project repo, but if you version-control your dotfiles, make sure it's explicitly excluded via .
Summary S