SSH Key Pairs

Asymmetric crypto, in one image

SSH keys come in pairs: a private key and a public key, mathematically linked. Think of the public key as a padlock you mail to anyone — they can lock things with it but can't unlock. The private key is the only key that opens those padlocks, and it never leaves your machine.

How auth actually works

The server has your public key in ~/.ssh/authorized_keys.
You connect. The server generates a random challenge and signs it with the algorithm parameters tied to your public key.
Your client signs the challenge with your private key and returns the signature.
The server verifies the signature with the public key. If it matches, you're in.

Crucially, the private key never crosses the wire. The server never sees it. The challenge-response mechanism proves you have it without disclosing it.

Why keys beat passwords

Strength — A 256-bit ed25519 key is astronomically harder to brute-force than any password.
No transmission — Nothing secret ever travels.
No reuse — Each device has its own key. One device compromised doesn't mean others are.
Revocable per device — Remove one line from authorized_keys to revoke one device.
Automation-friendly — Cron, CI, scripts authenticate without a stored password.

Code

Look at a key pair·bash

# Generate a key pair (full lesson is next — for now just look)
ls -la ~/.ssh/

# Public key — this is what goes on servers
cat ~/.ssh/id_ed25519.pub
# Format: <type> <base64-key> <comment>
# ssh-ed25519 AAAAC3...  you_username@macbook

# Private key — NEVER cat or share this
file ~/.ssh/id_ed25519
# Should be: OpenSSH private key

Exercise

If you don't already have a key, peek into ~/.ssh/. If you do have one, run cat ~/.ssh/id_ed25519.pub and identify the three parts of the line: type, base64-encoded key, and comment. The comment is your only way to remember which device a key belongs to once it lands on a server — make it descriptive when you generate one in the next lesson.