Why SSH Keys Beat Passwords
Password authentication is convenient but fragile — one data breach, one phishing attempt, and your server is exposed. SSH keys flip that model: the private key never leaves your machine, and the server only holds a public key that’s useless on its own.
On macOS, every key you create with ssh-keygen lands in ~/.ssh/ alongside your config file, authorized_keys, and known_hosts. It’s a small directory that punches well above its weight in your daily workflow.
Generating a Key Pair with ssh-keygen
ssh-keygen ships with macOS — no install needed. The modern recommendation is the Ed25519 algorithm. It’s fast, compact, and considered more secure than the older RSA 2048 default that’s still widespread:
ssh-keygen -t ed25519 -C "your@email.com" The -t flag picks the key type. The -C flag is just a comment — use your email or a hostname so you remember what this key is for. When ssh-keygen prompts you, choose a strong passphrase. Without one, anyone who copies your private key file has full access to every server you've configured it on.
You’ll end up with two files: id_ed25519 (private — guard this) and id_ed25519.pub (public — safe to share). Copy the public key to your server with ssh-copy-id, or paste it into GitHub/GitLab’s SSH settings.
If you want to keep keys outside the default path — for example, one key per project — pass -f to ssh-keygen:
ssh-keygen -t ed25519 -f ~/.ssh/work_ed25519 -C "work-laptop"
ssh-keygen Flags Worth Remembering
A handful of ssh-keygen flags come up often enough to memorize:
- -t <type> — choose the algorithm. Use ed25519 unless you have a specific reason for rsa or ecdsa.
- -b <bits> — key length. Only relevant for RSA; -b 4096 is the modern minimum.
- -C <comment> — embed a label in the public key so you can identify it on the server side.
- -f <path> — write to a non-default file path.
- -p — change the passphrase on an existing key without regenerating it.
- -y -f <key> — print the public key derived from an existing private key, handy if you lose the .pub file.
- -l -f <key> — show the fingerprint of a key, useful for verifying what’s installed where.
Everything else ssh-keygen does — certificate signing, KRL management, format conversion — is rarely needed for day-to-day work.
Organizing Multiple Keys
The moment ssh-keygen has produced more than two or three keys, things get messy fast. A key for work GitHub, one for personal projects, one per production server — it’s easy to lose track of what’s what.
The ~/.ssh/config file is how you stay sane. You can specify which key to use per host, set default usernames, configure timeouts, and create short aliases for long hostnames.
SSHVault gives you a visual overview of all keys in your .ssh directory — their types, comment fields, and whether they have a passphrase. No more guessing which file is which.
Protecting Your Keys
A passphrase is mandatory if your machine is ever shared, taken to a coffee shop, or could conceivably be stolen. macOS Keychain integrates with ssh-agent so you only type the passphrase once per login session.
If you already have unprotected keys, you don’t need to run ssh-keygen again to add one — just change the passphrase in place:
ssh-keygen -p -f ~/.ssh/id_ed25519
SSHVault’s key editor exposes the same operation through a UI — it calls standard ssh-keygen under the hood, but saves you from remembering the flags.