Minutes after a server goes online, the first bots start knocking and working through password lists — around the clock, fully automated. There is one answer to that constant drumbeat that beats any password, however long: SSH keys. Set them up once and every brute-force attempt runs into a wall, while your own logins get more convenient along the way.
Why keys beat every password
An SSH key is a cryptographic key pair. The private key stays on your machine and never leaves it; the public key goes onto the server. At login, your machine proves mathematically that it holds the private key — without any secret being transmitted.
That removes the two biggest weaknesses of passwords at once: a key cannot be guessed (its length makes trial and error hopeless) and it cannot be phished (there is nothing you could type into a fake page).
Step 1: Generate a key pair
Windows (10 and newer), macOS and Linux all ship with the command you need. Open a terminal or PowerShell and generate a modern ed25519 key pair:
ssh-keygen -t ed25519 -C "my-laptop"
Confirm the storage location with Enter. Do set the passphrase you are asked for: it encrypts the private key on your disk, so if your machine is ever stolen, the key alone is worthless. Your system's SSH agent remembers it, so you will not have to type it at every login.
Afterwards you will find two files in ~/.ssh/: id_ed25519 (private — never share it, never upload it anywhere) and id_ed25519.pub (public — that one goes to the server next).
Step 2: Copy the public key to your server
On Linux and macOS, one command handles this and sets the file permissions correctly along the way:
ssh-copy-id user@server-ip
Windows has no ssh-copy-id, so this PowerShell line does the same job:
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Both variants append your public key to ~/.ssh/authorized_keys on the server. That file takes one key per line, so you can authorise a second machine later without any fuss.
Step 3: Test — before you switch anything off
Open a new terminal window and connect as usual:
ssh user@server-ip
If you get logged in without a server password (at most your local key passphrase is requested), key login works.
Rule of thumb: test first, lock down second. Keep your existing SSH session open until key login is proven to work in a second session — that session is your lifeline if a typo sneaks into the configuration.
Step 4: Disable password login
Now for the step that shuts the bots out for good. Open the SSH configuration on the server:
sudo nano /etc/ssh/sshd_config
Set (or add) these lines:
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
The first two lines switch off every password-based method; the third allows root logins by key only.
One stumbling block on many cloud and hosting images: the directory /etc/ssh/sshd_config.d/ often holds additional configuration files that override your settings. Check for that in one go:
sudo grep -r "PasswordAuthentication" /etc/ssh/
If a PasswordAuthentication yes turns up anywhere (a classic is 50-cloud-init.conf), change it in that file too. Then validate the configuration and restart the service:
sudo sshd -t && sudo systemctl restart ssh
If sshd -t prints nothing, your syntax is fine. Now test in yet another window that key login still works — and that a password login is refused.
If it goes wrong anyway
Should you lock yourself out despite all precautions, nothing is lost: practically every provider offers a (VNC) console in its control panel that connects straight to the server, like a screen and keyboard attached to the physical machine. Use it to undo the change and take a second run at it.
Conclusion
Generate a key, install it, test it, disable password login — four steps that close the most common attack surface on a server entirely. Automated password attempts run into nothing from here on. Key login is the single most important building block of a basic hardening pass; which steps make sense next — firewall, updates, backups — is covered in securing your VPS in 7 steps. And why even the best login cannot defend against attacks aimed at the line itself is explained in what is a DDoS attack.