SSH keys and turning off password login
SSH password attacks can be stopped completely by disabling password authentication and using cryptographic keys instead. This guide walks through generating a key pair, testing it works, and safely disabling passwords on AlmaLinux 9 and Ubuntu 24.04, including how to avoid locking yourself out.
Rhys CallowayLinux VPS, servers, security and the command line
7 min read Updated 23 Sep 2026
AlmaLinux 9, Ubuntu 24.04 The most effective way to stop someone brute forcing your SSH password is to stop accepting passwords over SSH at all. Once you're logging in with a cryptographic key instead, there's no password for an attacker to guess, no matter how many attempts they throw at your VPS. This guide covers generating a key, proving it works, and then turning password login off properly on AlmaLinux 9 and Ubuntu 24.04, including the two mistakes that most commonly leave people locked out.
This picks up from a Hostworld VPS you can already reach over SSH using a username and password, whether that's a server you've just built or one you've been running for a while. If you haven't got that far yet, our VPS guides cover getting a server up and connected first.
Before you start
You'll need sudo or root access on the VPS, and a terminal on the computer you're connecting from (the built-in terminal on Mac and Linux, or the OpenSSH client that now ships with Windows 10 and 11). You do not need to know anything about cryptography to do this: generating a key pair is one command, and the rest is editing a text file.
The real risk here isn't losing data, it's locking yourself out of the server over SSH. Disabling password login before your key is proven to work leaves you with no way in remotely. We'll deal with that by testing the key in a second, separate connection before touching anything else, and by leaving your original session open until that test has succeeded. If you do end up locked out anyway, don't keep retrying the failing SSH connection: log in to the Hostworld client area at portal.hostworld.uk, open the VPS in Virtualizor, and use the VNC console to reach the server directly. That gets you a terminal on the box without going through SSH at all, so you can fix the configuration and try again.
Step 1: Generate an SSH key pair
This happens on your own computer, not the server. A key pair is two files: a private key that stays on your machine and must never be shared, and a public key that you copy to the server. The server checks that whoever's connecting holds the matching private key, rather than checking a password.
ssh-keygen -t ed25519 -C "[email protected]"Accept the default file location unless you have a reason to change it. You'll be asked for a passphrase: this encrypts the private key on your own disk, and we'd recommend setting one, though it's optional. This step is identical whether your server runs AlmaLinux or Ubuntu, since the key is generated on your computer, not the server.
Step 2: Copy the public key to the server
This uploads your public key to the server and adds it to the list of keys allowed to log in as your user. It works the same way regardless of whether the server is AlmaLinux 9 or Ubuntu 24.04.
ssh-copy-id -i ~/.ssh/id_ed25519.pub yourusername@your-server-ipYou'll be asked for your password one last time to authorise the copy. This is expected: password authentication needs to still be switched on at this point, because that's how the server confirms it's really you before it trusts the new key.
Step 3: Test the key in a second session
Do not close your current terminal window. Open a new one, and connect again:
ssh yourusername@your-server-ipIf this logs you in without asking for a password, the key is working and you're clear to move on. If it doesn't, stop here and work out why before going anywhere near sshd_config. Keeping the original session open while you test means that even if something's wrong, you've still got a working connection to fix it from.
Step 4: Turn off password authentication
Both AlmaLinux 9 and Ubuntu 24.04 load their SSH configuration in two places: the main file at /etc/ssh/sshd_config, and any .conf file inside /etc/ssh/sshd_config.d/. The main file should contain the line Include /etc/ssh/sshd_config.d/*.conf, which is normally there by default on both distributions. Rather than editing the long main file, add a small drop-in file of your own.
AlmaLinux 9:
sudo nano /etc/ssh/sshd_config.d/02-nopasswordlogin.confOn AlmaLinux, files in that directory are already present, such as 01-permitrootlogin.conf and 50-redhat.conf, and the number at the start of the filename sets priority: a lower number wins if two files disagree. Naming yours 02-... keeps it high priority without overriding 01-permitrootlogin.conf.
Ubuntu 24.04:
sudo nano /etc/ssh/sshd_config.d/02-nopasswordlogin.confThis directory is empty by default on Ubuntu, so there's nothing existing to conflict with, though the same numbering convention still applies if you add more files later.
In the file, on both distributions, add:
PasswordAuthentication no
KbdInteractiveAuthentication noThe second line matters as much as the first. PasswordAuthentication no on its own is not enough: OpenSSH has a second, older mechanism called keyboard-interactive authentication that can still accept a typed password even when the standard password method is switched off. Several real-world reports on both AlmaLinux and Ubuntu describe admins believing they'd disabled password login, only to find it still worked through this second path, because they'd only set one of the two directives. Set both to no.
Step 5: Check the file for syntax errors
A typo in sshd_config can stop the SSH service reloading at all, which is a particularly unwelcome discovery when you're relying on that same service to get back in. Check it before restarting anything:
sudo sshd -tNo output means the configuration is valid. If you get an error, it will tell you which file and line to fix.
Step 6: Restart the SSH service
AlmaLinux 9:
sudo systemctl restart sshdUbuntu 24.04:
sudo systemctl reload sshOne Ubuntu-specific detail is worth knowing even though it doesn't change what you type today: since Ubuntu 22.10, SSH runs via systemd socket activation rather than as a permanently running service. In practice, ssh.socket listens on the port and starts sshd on demand. Reloading ssh is enough for the change you've just made. It only becomes a problem if you later change the port SSH listens on, in which case you'd need to reload systemd and restart ssh.socket as well, or the old port carries on being used.
Step 7: Confirm what's actually being enforced
Don't take the file you just edited on trust. Ask the running SSH daemon what it's actually enforcing, since this merges the main file and every drop-in together the same way SSH itself does:
sudo sshd -T | grep -i authLook for passwordauthentication no and kbdinteractiveauthentication no in the output. This step exists because of a documented and recurring problem: a drop-in file with a lower priority number, or one you'd forgotten was there, can silently override the setting you think you've made. Checking the effective configuration this way catches that before an attacker does.
Step 8: Consider restricting root login too
Password login and root login are controlled separately, by the PermitRootLogin directive. Plain OpenSSH defaults to yes, though packaged AlmaLinux and Ubuntu images commonly ship with it already set to the commented-out value prohibit-password, meaning root can only log in with a key, never a password, even before you've made any changes. If root doesn't need to log in over SSH at all on your server, which is true for most setups where you use a regular sudo user instead, set it to no in the same drop-in file or a new one, then repeat steps 5 to 7 to check and confirm it.
If you're troubleshooting and a user still seems able to log in with a password after all this, check further down the configuration for a Match block or an AllowUsers line: these can apply different rules to specific users or connections and are a common cause of "I set this and it didn't work" reports.
What next
With password login switched off and confirmed with sshd -T, brute force attempts against your SSH port stop being a meaningful threat, since there's no password left to guess. A sensible next step is looking at your VPS firewall to control which ports are reachable at all. Our Linux VPS product page has details on the VPS lines this applies to, and our VPS guides cover the wider set of hardening and setup topics in sequence. If anything in this guide doesn't match what you're seeing on your server, or you end up locked out and the Virtualizor console doesn't resolve it, open a support ticket and we'll look at it with you.
Common questions
Is this the same as my Hostworld account password?
No. The password you're disabling here is the one used to log in to the operating system on your VPS over SSH. Your Hostworld account, invoices and support tickets are all handled separately through the client area at portal.hostworld.uk, and that password is unaffected by anything in this guide.
What happens if I lose my private key?
If password login is off and you lose the private key with no other key registered, you won't be able to log in over SSH. You'd need to reach the server through the Virtualizor VNC console from the client area to add a new key or re-enable password login temporarily. It's worth keeping a backup of your private key somewhere safe, and considering adding a second key from a different device before you rely on this setup fully.
Do I still need something like fail2ban if passwords are already off?
Removing password authentication removes the specific risk of someone guessing your password. It doesn't stop connection attempts arriving in the first place, so tools that watch for and block repeated failed logins still have a place if you want to reduce log noise and unwanted traffic, but they're no longer protecting a password that can be brute forced.
Should I do this on a brand new server or wait?
There's no reason to wait. Doing it early, before the server is doing anything important, means less risk if you make a mistake, and it becomes one less thing to remember to come back to later.
Can I do this on a Windows Server VPS instead?
This guide covers AlmaLinux 9 and Ubuntu 24.04 specifically, since the file locations and commands are Linux-specific. Windows Server VPS instances handle remote access differently and aren't covered here.