SSH password authentication is surprisingly insecure and often relies on weak credentials.
Let’s see what it looks like when it’s working correctly. Imagine you’re trying to log into a server, prod-web-01.example.com, as the user admin.
# On your local machine
ssh admin@prod-web-01.example.com
If password authentication is enabled, you’d see:
admin@prod-web-01.example.com's password:
After entering the correct password, you’re in. But if you had a typo in your password, or if someone brute-forced it, you’d be locked out or worse, compromised.
Now, let’s switch to key-only login. First, generate a key pair on your local machine if you don’t have one:
# On your local machine
ssh-keygen -t ed25519
This command creates two files in ~/.ssh/: id_ed25519 (your private key, keep this secret!) and id_ed25519.pub (your public key, safe to share).
Next, copy your public key to the server. The ssh-copy-id utility is the easiest way:
# On your local machine
ssh-copy-id admin@prod-web-01.example.com
This command logs you in using your password (one last time!), and appends your public key to ~/.ssh/authorized_keys on the server. If you don’t have ssh-copy-id, you can do it manually:
# On your local machine
cat ~/.ssh/id_ed25519.pub | ssh admin@prod-web-01.example.com 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'
Now, on the server (prod-web-01.example.com), you need to configure SSH to only accept key-based authentication. Edit the SSH daemon configuration file, typically located at /etc/ssh/sshd_config.
# On prod-web-01.example.com
sudo nano /etc/ssh/sshd_config
Find these lines and ensure they are set as follows:
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no: This is the crucial setting that disables password-based logins entirely.PubkeyAuthentication yes: This explicitly enables public key authentication.ChallengeResponseAuthentication no: This disables other interactive authentication methods like PAM, which might fall back to password prompts.
After saving the changes to sshd_config, you must restart the SSH service for them to take effect. The command varies slightly by system:
On systems using systemd (most modern Linux distributions):
# On prod-web-01.example.com
sudo systemctl restart sshd
On older systems using SysVinit:
# On prod-web-01.example.com
sudo service ssh restart
Now, try logging in again from your local machine:
# On your local machine
ssh admin@prod-web-01.example.com
This time, you should be logged in immediately without any password prompt. If you try to log in from a machine without the corresponding private key, you will be denied access.
The mental model here is asymmetric cryptography. Your private key is a secret, and your public key is a public declaration of "I am the holder of this secret." When you connect, the SSH server uses your public key to issue a challenge that only the corresponding private key can solve. If your client can solve it, the server knows it’s you, and since password authentication is off, it grants access.
The exact levers you control are primarily in /etc/ssh/sshd_config. Beyond PasswordAuthentication and PubkeyAuthentication, you can configure:
AuthorizedKeysFile: Specifies wheresshdlooks forauthorized_keysfiles. The default is.ssh/authorized_keysin the user’s home directory.PermitRootLogin: Should usually be set tonoorprohibit-passwordfor enhanced security, forcing users to log in as a regular user and thensudo.AllowUsersandDenyUsers: Fine-grained control over which users can log in via SSH.
A common mistake is to disable PasswordAuthentication before successfully copying the public key and testing key-based login. This can lead to being locked out of your server, as you won’t be able to log in at all. Always ensure key-based login works before disabling password authentication.
The next step is to manage SSH access for multiple users and servers efficiently, often involving centralized authentication mechanisms like LDAP or SSH certificate authorities.