How does SSH public key authentication work?
The client proves its identity by signing a challenge with its private key; the server verifies that signature using the matching public key it already trusts — no password ever crosses the wire.
Key authentication rests on an asymmetric key pair: a private key that never leaves the client, and a public key that is freely copied to every server you want to reach. The two are mathematically linked — anything signed by the private key can be verified by the public key, but you cannot derive the private key from the public one.
What actually happens at login:
- The server finds your public key in its
~/.ssh/authorized_keysand sends a random challenge. - The client signs that challenge with its private key (the key may itself be passphrase-protected).
- The server verifies the signature against the stored public key. A valid signature proves the client holds the private key, so it grants access.
(This is separate from the host key step earlier in the handshake, where the server proves its identity to the client and gets recorded in known_hosts.)
Key locations:
| Key | Location | Shared? |
|---|---|---|
| Private key | Client: ~/.ssh/id_rsa |
Never share! |
| Public key | Server: ~/.ssh/authorized_keys |
Safe to share |
Why use keys over passwords?
- More secure (can't be brute-forced)
- Enables passwordless automation
- Can be revoked per-device
- Required by many production servers
Generate keys:
ssh-keygen -t rsa -b 4096
ssh-copy-id user@server
Go deeper:
sshd(8) — AUTHENTICATION & AUTHORIZED_KEYS — the public-key auth flow and the authorized_keys/known_hostsfile formats.