In this guide · 8 sections
Short answer
Create a key pair with ssh-keygen -t ed25519, copy the public key to the server, confirm you can log in with it, then set PasswordAuthentication no, KbdInteractiveAuthentication no and PermitRootLogin no, check with sshd -T, and reload SSH while keeping a second session open.
Why password SSH logins get brute-forced
SSH is the standard way to manage a Linux server remotely. When it accepts passwords, anyone on the internet can try them. Bots scan whole address ranges for port 22 and try common usernames (root, admin, ubuntu) with lists of leaked passwords, all day, every day.
The OpenSSH sshd_config manual shows that PasswordAuthentication defaults to yes, and MaxAuthTries allows 6 attempts per connection by default. Bots simply open new connections. Rate limiting and tools such as fail2ban slow them down, but the real fix is to stop accepting passwords at all.
Password login
- Can be guessed or reused from a breach
- Can be phished or shoulder-surfed
- Shared passwords make leavers hard to remove
Best for: Nothing exposed to the internet.
SSH key login
Recommended- Private key never leaves the user's device
- Cannot be brute-forced in practice
- Each person has their own key to revoke
Best for: Every server reachable over the internet.
Create an SSH key pair and store it safely
An SSH key pair is two files: a private key that stays on your laptop and a public key you place on the server. The ssh-keygen manual lists Ed25519 as a supported key type; it is a sensible default for new keys.
Generate the key on your own laptop
Run ssh-keygen -t ed25519 -C "name@company". On Windows, OpenSSH is built into PowerShell; on Mac and Linux it is in the Terminal.
Set a passphrase
When asked, enter a passphrase. It protects the private key if your laptop is lost or stolen.
Keep the private key private
Never email it, paste it into chat or put it in a shared drive. Only the .pub file is ever shared.
Consider a hardware or managed key
OpenSSH supports security-key types (ed25519-sk) that need a physical key such as a YubiKey. Some password managers can also store SSH keys and act as an agent.
For more on admin access in general, see our guide to admin account best practice for small businesses.
Install the public key on the server
Each user's public keys go in the file ~/.ssh/authorized_keys in their home directory on the server, which the manual lists as the default AuthorizedKeysFile.
- The easiest way is ssh-copy-id user@server, which appends your public key while you can still log in with a password.
- On a cloud VPS, you can usually paste the public key in the provider's console when creating the server, so password login is never needed.
- Log in once with the key (ssh user@server) and confirm it does not ask for the account password. It may ask for your key passphrase; that is local.
Disable password and root login
Edit the SSH server settings with sudo. Change or add these lines:
| Setting | Set to | Why |
|---|---|---|
| PasswordAuthentication | no | Stops password logins (default is yes) |
| KbdInteractiveAuthentication | no | Closes the other password-style prompt (default is yes) |
| PubkeyAuthentication | yes | Key login (already the default) |
| PermitRootLogin | no | No direct root login; admins use their own account and sudo (default is prohibit-password) |
Check for drop-in files
Many distributions include files from /etc/ssh/sshd_config.d/ at the top of sshd_config. The manual says the first value read for each keyword is used, so an included file that says PasswordAuthentication yes beats your edit further down. Put your settings in an early drop-in file such as 10-hardening.conf, or fix the conflicting file.
Validate the config
Run sudo sshd -t to check for syntax errors.
Confirm the effective values
Run sudo sshd -T and look for passwordauthentication no, kbdinteractiveauthentication no and permitrootlogin no.
Reload SSH
Reload or restart the ssh service (the name differs by distribution), keeping your existing session open.
Test from a new window
Try ssh -o PubkeyAuthentication=no user@server. It should be refused. Then confirm normal key login still works.
Ubuntu's OpenSSH server documentation covers the same settings for Ubuntu servers.
Extra hardening that helps
Server login hardening
Exposed admin interfaces are a common way in; see our write-up of the Carbonato botnet and exposed Docker servers and the self-hosted n8n security checklist for examples.
Managing keys when staff join and leave
NIST's report on SSH key-based access management (IR 7966) makes the point that SSH keys need the same provisioning, termination and monitoring as passwords, and that this is often neglected.
One key per person, per device
Never share a key between people. Add a clear comment (name and device) so you know whose key each line is.
Keep a simple register
List each server, which accounts exist and whose keys are in each authorized_keys file.
Remove keys on the leaving day
Delete the person's lines from authorized_keys on every server, and remove their user account if they had one.
Rotate shared automation keys
If a deploy or backup key was ever on the leaver's laptop, replace it.
Review twice a year
Compare every authorized_keys file with the register and remove anything you cannot explain.
Do it yourself or get help?
If you are comfortable in a terminal and have console access as a fallback, the steps above take under an hour per server. The risk is locking yourself out, so test carefully.
If you would rather have it done and documented, our Software & Server Protection Setup (S$590, paid upfront) moves logins to keys, disables password and root login, sets the firewall and automatic updates, and leaves you a key register. IT Sorted is a Singapore-based team of developers with over 10 years of experience.
Frequently asked questions
Yes, once you have confirmed key login works for at least two admin accounts and you have a fallback such as your cloud provider's console. Keep one SSH session open while you change the settings, validate with sshd -t, check the effective values with sshd -T, then reload and test from a new window before closing the old one.
Usually because another file sets it to yes first. Many distributions include files from /etc/ssh/sshd_config.d/ near the top of sshd_config, and OpenSSH uses the first value it reads for each keyword. Run sshd -T to see the effective setting, then fix the conflicting drop-in file.
Ed25519 is a good default for new keys on current OpenSSH: short, fast and widely supported. If you have hardware security keys, the ed25519-sk type ties login to the physical key. RSA keys still work if an old system requires them, but use a large key size.
Moving SSH to another port reduces log noise from simple bots but does not stop a determined attacker scanning all ports. It is optional. The changes that matter are key-only login, no root login, and a firewall that only allows SSH from your own IP addresses or VPN.
Remove their public key lines from authorized_keys on every server they could reach, disable or delete their user account, and replace any shared automation keys that were ever on their device. Then update your key register. Doing this on their last day is far easier than reconstructing it months later.