How to Set Up SSH Key-Based Authentication Properly

This sets up SSH key-based authentication end to end, and — critically — disables password authentication only after confirming key-based login actually works, avoiding the single most common way people lock themselves out of a remote server.

Step 1: generate a key pair on your local machine

ssh-keygen -t ed25519 -C "daniel@laptop"

ed25519 is the recommended modern key type — smaller and faster than RSA while offering equivalent or better security. Use a strong passphrase when prompted; the private key file itself should never be copied anywhere except the machine(s) you personally control.

Step 2: copy the public key to the server

ssh-copy-id youruser@yourserver

This appends your public key to ~/.ssh/authorized_keys on the remote server, creating the directory and file with correct permissions if they don’t already exist. If ssh-copy-id isn’t available, the manual equivalent is:

cat ~/.ssh/id_ed25519.pub | ssh youruser@yourserver "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Step 3: verify correct permissions on the server

SSH is deliberately strict about permissions on these files and will silently refuse to use a key if they’re too permissive:

ssh youruser@yourserver "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Step 4: test key-based login before changing anything else

ssh youruser@yourserver

You should connect without being prompted for the account password (you may still be prompted for your key’s own passphrase, which is expected and different). Do not proceed to step 5 until this works reliably.

Step 5: only now, disable password authentication

With key-based login confirmed working, edit the SSH daemon configuration:

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

PermitRootLogin prohibit-password still allows root login via key if genuinely needed, while blocking password-based root login specifically — a reasonable middle ground for most setups.

Step 6: keep your current session open while testing the reload

sudo systemctl reload sshd

Keep your existing SSH session connected while you open a brand new terminal and test a fresh connection — if something is misconfigured, your still-open original session is how you fix it without needing console access.

# in a NEW terminal window/tab
ssh youruser@yourserver

Step 7: confirm password auth is actually rejected now

ssh -o PubkeyAuthentication=no youruser@yourserver

This forces SSH to skip key-based auth for this one connection attempt specifically — it should now be rejected outright rather than falling back to a password prompt, confirming step 5’s configuration actually took effect.

Step 8 (optional but recommended): disable root SSH login entirely

If you have a separate sudo-capable user account set up and don’t need direct root SSH access at all:

PermitRootLogin no

Why the order of operations here is the whole point

The single most common way people lock themselves out of a server is disabling password authentication before confirming key-based login actually works — if the key setup has any problem (wrong permissions, key not actually copied, wrong username), you discover this only after you’ve already cut off your fallback. Testing thoroughly at step 4, and keeping a working session open during step 6’s reload specifically, is what makes this whole process safely reversible at every stage rather than a one-way door.