SSH Key vs Password Authentication - Why Keys Win

2026-06-06 Reading time: About 11 min Difficulty: Intermediate

What You'll Learn

• The fundamental difference between SSH key and password authentication
• Why keys are safer, explained from how the cryptography works
• The practical workflow: create, install, and harden keys with ssh-keygen

What's the difference between key and password auth?

Conclusion: Password auth sends a "secret you know" to the server every time to be checked. Key auth proves you "have" the private key without putting it on the network.

The two methods differ fundamentally in how they prove who you are.

Why is key authentication safer?

Conclusion: The private key never travels the network (so it can't be sniffed), the key space is effectively impossible to brute force, and a server compromise can't reveal the private key.

Key auth's security comes mainly from three structural properties.

1. The secret never travels the network

With password auth the password itself reaches the server, encrypted but present. With key auth the private key stays on the client; what gets sent is only a signature (a proof made with the private key). The private key itself is never on the wire.

2. Brute force is effectively impossible

Human-memorable passwords are limited in length and complexity, making them targets for brute-force and dictionary attacks. An Ed25519 key, or RSA of 2048 bits or more, has an astronomically large key space, so brute force is not practical.

3. Resilient to server compromise

The server stores only your public key. You cannot derive the private key from the public key, so even if authorized_keys leaks, nobody gains the ability to log in. That is a different situation from a leaked password hash, which is the starting point for offline cracking.

How do the public and private keys work?

Conclusion: The client signs with the private key and the server verifies with the matching public key. You prove possession of the private key without ever sending it.

Key auth works as a public-key challenge-response. The flow is roughly:

1. The client tells the server "I want to authenticate with this public key."
2. The server checks whether a matching public key exists in authorized_keys.
3. The client signs session-specific data with the private key and returns it.
4. The server verifies the signature with the public key. A match means you are who you claim to be.

The key point: the signature is made over data that is unique to each session, so sniffing and replaying past traffic does not help with the next login. The private key itself never goes on the network.

How do you create and install a key pair?

Conclusion: Create a pair with ssh-keygen -t ed25519, then install the public key into the server's authorized_keys with ssh-copy-id.

1. Create a key pair

$ ssh-keygen -t ed25519 -C "you@example.com"

• -t ed25519: the current recommended algorithm (fast and secure; for older environments use -t rsa -b 4096)
• -C: a comment (a label to identify the key later)
• Output: the private key ~/.ssh/id_ed25519 and the public key ~/.ssh/id_ed25519.pub

You'll be prompted for a passphrase. This is an extra key that encrypts the private key file itself, and setting it is strongly recommended (see below).

2. Install the public key on the server

$ ssh-copy-id user@server

ssh-copy-id safely appends the public key to the server's ~/.ssh/authorized_keys and sets the right permissions. To do it manually, append the contents of the public key (the .pub file) as one line in authorized_keys.

3. Verify the connection

$ ssh user@server

Success means you log in without a password prompt (or with only your passphrase).

Should you disable password authentication?

Conclusion: After confirming key auth works reliably, disabling password auth on production servers is the standard. It physically closes the door to brute-force attacks.

Even with key auth enabled, leaving password auth on keeps the brute-force entry point open. Disable it in /etc/ssh/sshd_config.

# /etc/ssh/sshd_config
PubkeyAuthentication yes
PasswordAuthentication no

Then restart the SSH service.

$ sudo systemctl restart ssh      # Debian / Ubuntu family
# On RHEL family the service is named sshd
$ sudo systemctl restart sshd

How do you keep the private key safe?

Conclusion: Set a passphrase, tighten permissions on ~/.ssh and the private key, and use ssh-agent to reduce typing.

Key auth's security rests on protecting the private key. At minimum, do the following.

Set a passphrase

A passphrase on the private key means a stolen file isn't immediately usable. The easiest time to set it is during ssh-keygen.

Tighten permissions

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ed25519
$ chmod 600 ~/.ssh/authorized_keys

OpenSSH refuses to authenticate if the private key or ~/.ssh is too permissive. This is a classic place to get rejected with a permissions error.

Use ssh-agent to reduce typing

$ eval "$(ssh-agent -s)"
$ ssh-add ~/.ssh/id_ed25519

With the unlocked key held by ssh-agent, you don't re-enter the passphrase during the session. You get both safety (a passphrase is set) and convenience.