SSH Public Key Authentication: How It Works and How to Set It Up Correctly

Public key authentication is the right default for SSH access: it removes passwords from the wire, resists brute-force attacks, and can be audited per key. The short version of how it works: you generate a key pair, place the public half on the server in ~/.ssh/authorized_keys, and the server proves you hold the matching private key by asking you to sign a challenge. No secret ever crosses the network.

The mechanism: a signature, not a password

With password authentication, the client sends something secret to the server, which means a spoofed or compromised server can capture it. Public key authentication inverts this. The server sends a random challenge tied to the session; the client signs that challenge with its private key; the server verifies the signature against the public key it has on file. The private key never leaves your machine, and a replayed signature is useless because each challenge is unique to the session.

Because the server only ever sees signatures, stealing authorized_keys from a server gives an attacker nothing they can log in with — public keys are safe to distribute.

A worked setup

Run these on your client machine as your normal user. Ed25519 is the recommended algorithm on any reasonably current OpenSSH (7.0+); it is fast, compact, and avoids the pitfalls of older RSA key sizes.

ssh-keygen -t ed25519 -C "jane@laptop-2026" -f ~/.ssh/id_ed25519

Set a passphrase when prompted. This encrypts the private key at rest, so a stolen laptop does not immediately mean a compromised server. The comment (-C) is a label only — it helps you identify the key later in authorized_keys files.

Next, copy the public key to the server. ssh-copy-id handles permissions correctly and appends rather than overwrites:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [contact removed]

This requires one last password login. If the server has password auth disabled already, append the contents of id_ed25519.pub to ~/.ssh/authorized_keys on the server through whatever access you have (console, another key, a provisioning tool).

Verify before you close the door

Test the key explicitly, keeping your existing session open in case something is wrong:

ssh -i ~/.ssh/id_ed25519 -v [contact removed]

The -v flag shows which identity files are offered and whether the server accepts one — look for a line like Server accepts key followed by successful authentication. On the server, confirm the event in the auth log (/var/log/auth.log on Debian/Ubuntu, or journalctl -u sshd on systemd systems): you want an Accepted publickey entry.

Only after key login works should you consider disabling password authentication in /etc/ssh/sshd_config (PasswordAuthentication no), followed by sshd -t to validate the config and a service reload. Do this while you still have an active session and a recovery path.

Permissions: the most common failure

OpenSSH refuses to use keys from locations it considers unsafe. If key auth silently falls back to password or fails outright, check these first on the server:

Path	Required permission	Owner
~ (home directory)	not group/world-writable	the user
~/.ssh	700	the user
~/.ssh/authorized_keys	600	the user

Fix with chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys run as the target user. When debugging, sshd logs the exact reason for rejection — read the auth log before guessing.

Limits and common mistakes

• Key loss is lockout. There is no password reset for a private key. Keep a second authorized key (for example, on a backup machine or hardware token) or an out-of-band console before disabling passwords.
• Unencrypted private keys are bearer tokens. Anyone who copies id_ed25519 from an unprotected key can authenticate as you. Use a passphrase, and use ssh-agent so you only type it once per session.
• Wrong key offered. If you have many keys, the server may reject the session after too many attempts (MaxAuthTries). Pin the key per host in ~/.ssh/config with IdentityFile and IdentitiesOnly yes.
• authorized_keys is per-account. A key in root's file does not help you log in as another user. Grant access by adding keys to the right account, ideally via a configuration management tool so revoked keys actually disappear.

The practical check that everything is in order: log in with -v, confirm Accepted publickey in the server log, and confirm ssh -o PasswordAuthentication=no still connects. If all three pass, your key setup — not a password fallback — is doing the work.