SSH Keys and Authentication

For using SSH day-to-day - connecting, config files, port forwarding - see SSH. This page covers specifically how key-based authentication works and how to set it up, which is what makes disabling password login (a standard hardening step) practical in the first place.

How it actually works

A key pair consists of a private key (kept secret, never shared) and a public key (safe to hand out freely - that's the point of it). When you connect, the server challenges your client to prove it holds the private key matching a public key it already trusts, using public-key cryptography - the private key itself is never transmitted anywhere during this exchange, which is why it's meaningfully more resistant to interception than a password.

Generating a key pair

ssh-keygen -t ed25519 -C "alice@laptop"

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alice/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):

ed25519 is the modern recommended key type - smaller and faster than RSA at an equivalent security level. Use RSA (-t rsa -b 4096) only if you need compatibility with an older system that doesn't support ed25519.

This produces two files: id_ed25519 (the private key - never copy this anywhere except between your own machines) and id_ed25519.pub (the public key - this is what gets distributed).

Set a passphrase. An unencrypted private key means anyone who gets a copy of the file - a stolen laptop, a compromised backup - can use it immediately with no further barrier. A passphrase means they'd also need to crack it first.

Authorizing a key on a server

ssh-copy-id alice@devbox

This appends your public key to ~/.ssh/authorized_keys on the remote machine. Without ssh-copy-id, the same thing done manually:

cat ~/.ssh/id_ed25519.pub | ssh alice@devbox "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Permissions matter - SSH will silently refuse loose ones

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519

If ~/.ssh or authorized_keys is group- or world-writable, sshd refuses to use it at all, for anyone's protection - including yours if someone else could otherwise plant a key of their own. This is one of the most common causes of "key auth suddenly stopped working," and worth checking first (ls -la ~/.ssh) before assuming the key itself is wrong. See File Permissions and Ownership for what these specific octal values mean.

Not re-typing your passphrase constantly: ssh-agent

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

ssh-agent holds your decrypted private key in memory for the rest of the session, so a passphrase-protected key doesn't mean re-entering it on every single connection - most desktop environments start an agent automatically at login.

Disabling password login once keys work

Only after confirming key-based login actually works - test in a second terminal before closing the one you're already connected through:

# /etc/ssh/sshd_config
PasswordAuthentication no

sudo systemctl reload sshd

See Hardening Basics for this as one part of a broader baseline security checklist.