Key Algorithm Choice

If you’re still using RSA-2048 keys generated before 2020, it’s worth rotating them. Not because RSA-2048 is broken — it isn’t — but because Ed25519 is strictly better for most purposes: shorter keys, faster operations, and no parameter choice that could go wrong.

For high-security environments, ECDSA-521 or RSA-4096 are also defensible. The main thing to avoid is DSA (deprecated and removed in OpenSSH 7.0) and RSA keys shorter than 2048 bits.

Passphrases Are Not Optional

A private key without a passphrase is a password written in plaintext. If your laptop is stolen, your cloud storage is compromised, or your dotfiles repo accidentally includes .ssh/, an unprotected private key hands an attacker access to every server it’s authorized on.

Use a passphrase. macOS Keychain integration means you only type it at login — after that, ssh-agent handles it transparently. The UX cost is close to zero; the security benefit is significant.

Agent Forwarding: Use Carefully

ForwardAgent yes in your ssh config lets you hop from server to server without copying keys everywhere. It’s convenient, and it’s also a meaningful attack surface: a compromised intermediate server can use your forwarded agent socket to authenticate as you to other hosts.

The safer alternative is ProxyJump (or the equivalent -J flag). It tunnels your SSH connection through a bastion host without exposing your agent to that host. Most modern SSH deployments should prefer ProxyJump over agent forwarding.

Server-Side Hardening

On servers you control: disable password authentication entirely (PasswordAuthentication no in sshd_config), disable root login (PermitRootLogin no), and consider moving SSH off port 22 to cut down on automated scan noise — though this is security through obscurity and not a substitute for proper hardening.

Regularly audit your authorized_keys files. It’s easy to accumulate old keys from contractors, former employees, or machines you no longer use. SSHVault helps on the client side — keeping your local key inventory clean — but the server side needs attention too.

Rotate Old Keys

There’s no hard rule on rotation frequency, but a reasonable practice is to rotate keys when: an employee leaves, a machine is decommissioned, you suspect a compromise, or you haven’t looked at your key inventory in over a year.

Rotation is just generating a new key pair, distributing the new public key, and removing the old one from authorized_keys. It’s low effort and meaningfully reduces your exposure window if an old key was silently compromised.