🔒 The Safer Way to Set Up SSH Keys

Tutorials & Methods
, ,
1

:key: ED25519 key auth, verified explicitly AND normally before you touch password login — so a bad config can’t lock you out

Most SSH-key tutorials tell you to disable password login the second you set up a key. That’s exactly how people lock themselves out of their own server. This is the safer order: set up the key, verify it actually works, THEN think about disabling the password fallback — not before.

LOCAL WORKSTATION
       │
       │ ED25519 private key (never leaves this machine)
       ▼
SSH CONNECTION
       │
       │ matching public key only
       ▼
REMOTE SERVER

:one: Check for an existing key

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub 2>/dev/null

Nothing there? Make one:

ssh-keygen -t ed25519 -C "workstation-to-server"

:warning: id_ed25519 (no .pub) is your private key — never email it, paste it anywhere, put it in GitHub, put it in a zip, or send it to an AI chat. Only id_ed25519.pub ever leaves your machine.

:two: Copy the public key to the server

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@SERVER_FQDN

You’ll type your password one last time here, while the key gets installed.

:three: Verify it explicitly, then verify it normally

ssh -i ~/.ssh/id_ed25519 root@SERVER_FQDN 'hostname'   # explicit key test
ssh root@SERVER_FQDN 'hostname'                          # does it pick the key automatically?

If both return your hostname with no password prompt, key auth is working — for real, not just “should be working.”

BEFORE                          AFTER
ssh                              ssh
 ↓                                ↓
password prompt         client offers private key
 ↓                                ↓
type password             server verifies public key
 ↓                                ↓
login                            login

:green_circle: Keep the password fallback — on purpose

You do not have to disable password login just because keys work. Keep both until you’ve tested from every machine you actually depend on. There’s no prize for locking yourself out of your own server.

:wrapped_gift: Bonus: name your server so you stop typing the FQDN

nano ~/.ssh/config

Host myserver
    HostName server.example.com
    User root
    IdentityFile ~/.ssh/id_ed25519

chmod 600 ~/.ssh/config

Now ssh myserver is the whole command.

:magnifying_glass_tilted_left: Checking your work

ssh -v root@SERVER_FQDN          # see which identity it's trying
ls -la ~/.ssh/                    # what keys exist
chmod 600 ~/.ssh/id_ed25519      # private key: owner-only
chmod 644 ~/.ssh/id_ed25519.pub  # public key: fine to be readable

:high_voltage: Full quick version

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub 2>/dev/null || \
ssh-keygen -t ed25519 -C "workstation-to-server"

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@SERVER_FQDN
ssh -i ~/.ssh/id_ed25519 root@SERVER_FQDN 'hostname'
ssh root@SERVER_FQDN 'hostname'

Last command returns your hostname, no password asked? Done.

:thought_balloon: Why ED25519 specifically

Small keys, fast, strong modern crypto, supported on every current Linux distro. It’s just the sane default now:

ssh-keygen -t ed25519
2 Likes