Key-Based Authentication

Why password auth has to go

Password authentication is fundamentally weaker than key auth in five concrete ways:

Guessable — Even a strong password is brute-forceable. An ed25519 key is 2^256 possibilities; the universe heat-deaths first.
Phishable — Someone can build a fake server to harvest passwords. Keys verify the server too (via known_hosts).
Reused — Humans reuse passwords. One leak, many compromises.
Transmitted — The password (encrypted, but still) crosses the network on every login. The private key never does.
Not auditable per device — A password is a password. With keys, every device has a unique line in authorized_keys.

Auditing authorized_keys

Treat authorized_keys as a guest list. Every line should be a key whose owner you can identify. The comment at the end of each line is the only audit trail — clear comments mean fast revocations.

Code

Audit and revoke·bash

# On the server, see the guest list
cat ~/.ssh/authorized_keys
# Each line:
#   ssh-ed25519 AAAA...abc you_username@macbook-2024
#   ssh-ed25519 AAAA...def you_username@office-mac
#   ssh-ed25519 AAAA...ghi you_username@retired-laptop  ← revoke me

# Revoke a single device — remove its line
sed -i.bak '/retired-laptop/d' ~/.ssh/authorized_keys

# See the fingerprint of every line (cleaner audit)
ssh-keygen -l -f ~/.ssh/authorized_keys

Force key-only auth (pre-Track-8 sneak peek)·bash

# /etc/ssh/sshd_config (server-side)
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

# Restart sshd (Linux)
sudo systemctl restart sshd
# macOS — toggle Remote Login off/on in System Settings

Exercise

On any server you can SSH into, run ssh-keygen -l -f ~/.ssh/authorized_keys and list every key. For each line, can you identify the device from the comment? If any line says just "user@host" or has no comment at all, that's a future audit headache. Bonus: regenerate any keys with weak comments and replace the entries.