Within hours of a new server appearing on the internet, automated bots begin knocking on its SSH port with common passwords. Switching to key-based login is the single highest-value security change you can make.

The math that ends the argument

A decent password has maybe 50–60 bits of entropy if it's random — and most people's aren't. An ed25519 SSH key is a 256-bit random secret that never gets typed, never travels through your keyboard, and can't be phrased into a "guess the password" game. Brute-forcing one is not a realistic attack; brute-forcing a password absolutely is, and it's happening to your server right now.

How keys actually work

  • You generate a key pair: a private key that stays on your laptop, and a public key that goes on the server.
  • When you connect, the server proves its identity to you (the fingerprint prompt), and you prove yours by signing a challenge only your private key can sign.
  • Your private key never leaves your device. Nothing to intercept, nothing to leak in a breach of the server.

The five-minute switch

# 1. Generate a key (on your computer)
ssh-keygen -t ed25519 -C "my-laptop"

# 2. Install it on the server
ssh-copy-id root@203.0.113.10

# 3. Verify key login works in a NEW window, then disable passwords
#    in /etc/ssh/sshd_config: PasswordAuthentication no

That third step is the important one: test before you lock. Full walkthrough with the safety checks is in the SSH security guide.

The one trade-off, honestly

Keys tie your access to a device. Lose the laptop without a backup key, and you're recovering through your provider's web console. The fix is boring: keep your public key on a second trusted device, and know where your provider's emergency console lives. For that small bit of hygiene, you eliminate the attack vector behind the overwhelming majority of server break-ins.