Use SSH keys safely

Your SSH private key stays on your machine. The server receives the public key.

The key pair replaces the password. The server keeps ~/.ssh/authorized_keys, a list of public keys allowed to log in. Anyone can hold the public half. Only the private half, on your laptop, can answer the login challenge.

Generate a modern key

Use a supported modern key type. Ed25519 is the current default choice:

ssh-keygen -t ed25519 -C "flavio-macbook-2026"

The -C comment labels the key, so a year from now you know which device it belongs to. Set a passphrase where practical, and use an agent or secure hardware for frequent use so you type it once per session:

ssh-add ~/.ssh/id_ed25519

Install it on the server

ssh-copy-id [email protected]

This appends the public key to authorized_keys with the right permissions. Verify host fingerprints on first connection: the client shows the server’s key fingerprint, and you confirm it against a value you obtained some other way.

Host verification protects the other direction. Record the expected server fingerprint through a trusted channel so a convincing login prompt cannot silently collect credentials or commands.

One key per device

A key copied across ten servers turns one stolen laptop into ten entry points. A dedicated key costs more management but allows narrow revocation and clearer attribution.

Label authorized keys and remove them when a device or person no longer needs access. The comment field makes the cleanup a one-line edit:

grep flavio-macbook /home/dana/.ssh/authorized_keys

The mistake to watch for: copying the private key onto the server “to hop to the next machine”. Never move the private file. If you need to reach a second host through the first, use ProxyJump in your SSH config, which keeps the key on your laptop.

Create a dedicated lab key and record its fingerprint beside the authorized entry. Remove that public key, then prove the old private key fails while the documented recovery key still works.