SSH Key Authentication
Public-key authentication replaces passwords with a cryptographic challenge — strictly stronger, more convenient, and the default for any serious infrastructure.
The keypair
You generate a private key (stays on your machine) and a public key (gets installed on every server you want to log into). When you connect, the server sends a challenge that only the private key can answer. The password — if any — protects the private key locally and is never transmitted.
# Generate a modern Ed25519 keypair
ssh-keygen -t ed25519 -C "you@host"
# Install your public key on a server
ssh-copy-id user@host
# (or manually append ~/.ssh/id_ed25519.pub to the server's ~/.ssh/authorized_keys)Key types
| Type | Notes |
|---|---|
ed25519 | Modern default. Small, fast, secure. |
ecdsa (P-256/384/521) | Faster than RSA at equivalent security. Avoid P-521 — less widely supported. |
rsa | Use 4096-bit minimum if you must. |
dsa | Deprecated. Don't use. |
authorized_keys file
On the server, ~/.ssh/authorized_keys lists permitted public keys, one per line. You can prepend options to restrict each key:
command="/usr/local/bin/backup",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA...ssh-agent
An agent caches the decrypted private key in memory so you don't have to enter the passphrase for every connection. Forward the agent with ssh -A only to hosts you fully trust — a compromised host with a forwarded agent can use your key while you're connected.
SSH certificates
For organisations, certificate-based SSH avoids the operational nightmare of distributing keys to every host. A CA signs short-lived user certificates; hosts trust the CA. Combined with hardware tokens, this is the modern best practice for high-assurance access.
Disable password auth on production servers. Set PasswordAuthentication no and PermitRootLogin no in /etc/ssh/sshd_config. Brute-force scans against port 22 are constant; key-only auth defeats them entirely.