Passwords over SSH are a standing invitation. Keys are not magic either — they get lost, left on old laptops, or copied into the wrong hands. Here is how keys actually work, and the small habits that keep them useful instead of scary.

What a key really is

A keypair is two files: a private key that stays on your machine and a public key that you copy to servers. The server challenges the client with a signature only the private key can produce. Nothing secret ever crosses the wire, and there is nothing to brute-force.

ssh-keygen -t ed25519 -a 64
ssh-copy-id deploy@server

The passphrase question

An unprotected private key is a skeleton key for anyone who steals your laptop. Put a passphrase on it, then let an agent remember it for the session:

# ~/.ssh/config
Host *
    AddKeysToAgent yes
    IdentityAgent ~/.ssh/agent.sock  # or your distro's default agent

You type the passphrase once per boot, not per connection. If your desktop environment does not unlock the agent at login, ssh-agent from your shell profile is fine.

Keys get lost. Plan for it.

# one key per device, named after the device
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/laptop -C "laptop-2026"

# when a laptop dies: revoke its key on every server
# (remove the line from ~/.ssh/authorized_keys, or use a CA if you have many)

One key copied to five machines becomes a key you cannot safely delete. One key per device means losing a device costs you one key, and the audit trail stays honest.

When passwords still make sense

Console access on the hypervisor, the BIOS, the router you manage out-of-band: places where a key is not an option. Long random passwords, unique per device, stored in your password manager. SSH itself should never see one.

Keys are not a firewall — they are an identity. Treat them like one: protected, per-device, and revoked the moment they are not yours anymore.