ssh

SSH Key vs Password Authentication: the Difference Is What Crosses the Network

secure-os· Updated September 5, 2026· 4 min read #ssh#authentication#linux#hardening

A hand in a dark suit sleeve holding a blue and white access card against a grey wall mounted reader, its small screen showing a time of 08:24 and a green arrow

Most comparisons of the two present it as a matter of strength: a key is longer than a password, therefore harder to guess. That is true and it is the least interesting part.

The real difference is architectural. A password is a secret you transmit. A private key is a secret that never leaves your machine.

Everything below follows from that one sentence.

What actually happens on the wire

With password authentication, you type a secret, it travels through the encrypted channel, and the server compares it against its stored hash. The channel protects it in transit, but the server receives the secret itself.

With key authentication, the server sends a challenge. Your client signs it with the private key and returns the signature. The server verifies the signature against the public key it already holds. Your private key never crosses the network, and the server never learns it.

The consequence is concrete rather than theoretical: a compromised or malicious server learns your password the moment you log in. With a key, the same server learns a signature that is useless anywhere else. If you reuse that password on three other machines, one bad server has just collected all three.

Where each one actually fails

Passwords fail online. A public SSH port receives automated guessing attempts continuously, and a weak password eventually falls. The failure is remote, silent, and does not require touching your machine.

Keys fail locally. A private key sitting unencrypted in ~/.ssh/id_ed25519 is a file, and anything that can read your home directory can copy it. Backup software, a synced folder, a malicious dependency in a project you built. The attack surface moves from the network to your disk, which is usually a better trade and is not the same as no risk.

That is what the passphrase is for. It encrypts the key at rest, so a stolen file is not a stolen key. It is not a second factor, it is the thing that makes the first factor survive a theft.

An open silver laptop on a plain beige background, its entire screen covered with rows of orange, green and pink sticky notes overlapping each other

Setting it up, and the two steps people skip

Generate a modern key. Ed25519 rather than RSA unless something old requires otherwise:

ssh-keygen -t ed25519 -C "laptop-2026"

Give it a passphrase when asked. Copy the public half to the server:

ssh-copy-id user@server

Then test the key login in a second terminal, while the first one is still connected. This is the step people skip, and it is the difference between fixing a typo and losing access to a remote machine.

Only once that works, disable password authentication in /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Then sudo sshd -t to check the syntax before reloading, because a bad config file plus a reload is the second common way to lock yourself out.

The comparison that is usually left out

Keys are harder to revoke than passwords, and nobody mentions it.

Changing a password is one command on the server. Revoking a key means removing the right line from authorized_keys on every machine that has it, and there is no central list telling you where it went. For one personal laptop this is trivial. For a team, it is the problem that eventually justifies a certificate authority or a bastion host.

Neither is a second factor. A key alone is one factor: something you have. A password alone is one factor: something you know. A key with a passphrase is closer to two, but the second one is checked by your own machine rather than by the server, which is not the same guarantee.

If a server genuinely needs two factors verified server side, that is TOTP or a hardware token on top of the key, and it is a separate configuration. The general reasoning is in two factor authentication.

What to do, in one paragraph

For a personal server: keys with a passphrase, password authentication disabled, and an ssh-agent so you type the passphrase once per session. For anything holding data you cannot lose: the same, plus the key on a hardware token so the private half cannot be copied at all.

And do not expect this to remove the noise from your logs. Disabling passwords stops the guessing from succeeding; it does not stop it from happening, and the attempts continue. Tools that promise otherwise are addressing the symptom, as our fail2ban analysis sets out. The rest of the surface is covered in Linux hardening.