Setting up SSH access on a new Linux VPS

Secure SSH access on a new VPS comes down to four things: log in with a key instead of a password, use a normal user account with sudo rather than root, confirm what the server is actually running before you change anything, and only turn password logins off once you have proved key logins work. The order matters more than the individual settings, because every lockout we see in a support ticket comes from someone doing the last step first.

This guide covers AlmaLinux 9 and Ubuntu 24.04, which behave differently in two places that catch people out: Ubuntu 24.04 starts sshd through a systemd socket, and AlmaLinux 9 reads configuration from a drop-in directory that can quietly override the file you just edited.

Before you start

This picks up from a VPS that is built and that you can already reach over SSH as root, using the root password from your Hostworld order. If you are not there yet, start with our VPS guides and come back.

You will need:

• The VPS IP address and current root password.
• A terminal on your own machine. On Windows, PowerShell or Windows Terminal includes an SSH client.
• Access to open a support ticket and to Virtualizor, reached from your Hostworld client area. Virtualizor is your way back in if SSH stops answering.

Two things that can go wrong, both avoidable:

• Locking yourself out. Keep your current SSH session open from the first change to the last. Test every change by opening a second session, not by closing the one you have.
• Locking yourself out and not being able to get into the client area either. If you have never logged into portal.hostworld.uk, check that now while SSH still works. The WHMCS forgotten password flow is not instant, and there is more on it at the end of this guide.

One more note before you touch a config file. Your VPS runs with the VNC console available in Virtualizor, which bypasses sshd entirely. That console is the reason a mistake here is recoverable rather than fatal, but it only works while the VPS is running.

Step 1: Find out what you are running

Package versions differ between images and change over time, so read your own rather than trusting a blog post. These print the client and server versions of OpenSSH.

ssh -V
sudo sshd -V

Note the number. Anything from OpenSSH 9.8 onwards includes automatic blocking of clients that repeatedly fail authentication or connect without completing it, controlled by PerSourcePenalties. That matters later, because testing a key setup badly from a single office IP can get you temporarily blocked by your own server.

Also worth knowing: DSA keys are gone. They were disabled at compile time in OpenSSH 9.8 and the build option that brought them back was dropped in 9.9. If a tutorial tells you to run ssh-keygen -t dsa, close the tab.

Step 2: Generate a key pair on your own machine

Run this on your laptop or desktop, not on the VPS. The private key should never leave the machine you type on. This creates an Ed25519 key pair, which is the current standard recommendation.

ssh-keygen -t ed25519 -C "laptop"

Accept the default path. When it asks for a passphrase, set one. A passphrase means a stolen laptop does not hand someone your server. You will get two files: ~/.ssh/id_ed25519 (private, never share it) and ~/.ssh/id_ed25519.pub (public, safe to copy anywhere).

Step 3: Create a user account that is not root

Logging in as root means every mistyped command runs with full privileges, and it means attackers know half your credentials already. Create a normal account and give it sudo.

AlmaLinux 9: the first command creates the user, the second sets a password, the third adds them to the wheel group, which has sudo rights by default.

sudo adduser alice
sudo passwd alice
sudo usermod -aG wheel alice

Ubuntu 24.04: adduser here is interactive and will prompt for the password itself. The second command grants sudo.

sudo adduser alice
sudo usermod -aG sudo alice

Step 4: Install your public key on the server

From your own machine, this copies your public key into the new user's authorized_keys file and sets the permissions correctly:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

It will ask for the password you set in step 3. If ssh-copy-id is not available, do it by hand on the server: create ~/.ssh, then append the contents of the .pub file to ~/.ssh/authorized_keys.

Permissions are the single most common reason a correct key is refused. sshd will ignore authorized_keys if it or its directory is writable by group or world, and your client will ignore a private key with loose permissions. Run these as the user who owns the files:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 755 ~

Ownership is the forgotten half. If you created the key directory as root on someone else's behalf, the chmods alone will not save you:

sudo chown -R alice:alice /home/alice/.ssh

Step 5: Test the key login before changing anything else

Leave your existing root session open. In a new terminal window:

ssh [email protected]

You should be prompted for your key passphrase, not the account password. If it asks for the account password, the key is not being accepted and you are not ready for step 7. Diagnose from the client with verbose output, which shows which keys are offered and what the server says about each:

ssh -vvv [email protected]

Do not brute-force your way through this by reconnecting twenty times in a row. On OpenSSH 9.8 and later that behaviour is what PerSourcePenalties is designed to punish, and you can end up blocking your own IP address and concluding the server is broken.

Step 6: Find where the configuration actually lives

This is the step most guides skip, and it is why people edit /etc/ssh/sshd_config, restart sshd and see no change at all.

AlmaLinux 9 uses a drop-in directory at /etc/ssh/sshd_config.d/. Files there are processed in alphabetical order and settings in an earlier file win. A file such as 01-permitrootlogin.conf is created at install time if root SSH login with a password was allowed, and it outranks anything you write in the main file. Look before you edit. This prints every non-empty setting in the drop-in directory:

sudo grep -r . /etc/ssh/sshd_config.d/

If you find a drop-in setting the thing you want to change, edit that file rather than the main one.

Ubuntu 24.04 can also use an include directory, so run the same grep and check the top of /etc/ssh/sshd_config for an Include line.

Step 7: Turn off root login and password authentication

Only do this now that step 5 succeeded. Back up the file first so you have something to restore from the console:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Edit the correct file (main config, or the drop-in that is overriding it) and set:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Now validate the syntax before restarting anything. sshd -t parses the configuration and prints errors without touching the running service. A typo caught here is a typo that does not cost you a console session:

sudo sshd -t

Then apply it. AlmaLinux 9:

sudo systemctl reload sshd

Ubuntu 24.04:

sudo systemctl restart ssh

The service name genuinely differs, so use the one for your OS rather than guessing.

Step 8: Verify what is actually in force

sshd -T prints the effective configuration after every include, drop-in and default has been resolved. It is the only honest answer to "did that work?", and it settles both the AlmaLinux drop-in problem and the Ubuntu socket problem:

sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|kbdinteractiveauthentication|port"

If those lines say what you set, you are done. If they do not, something is overriding you: go back to step 6.

Step 9: Firewall, and the port question

Open SSH in the host firewall before you change anything about ports, not after.

Ubuntu 24.04 uses UFW. This allows TCP port 22 and shows the current rules:

sudo ufw allow 22/tcp
sudo ufw status

AlmaLinux 9 uses firewalld. This allows the SSH service, makes it permanent and reloads:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Moving SSH off port 22 reduces log noise from automated scanning. It is not security on its own, and key-only authentication matters far more. If you want to do it anyway, be aware of two traps.

On Ubuntu 24.04, sshd is socket activated: since Ubuntu 22.10 the packaged openssh-server does not run persistently, and ssh.socket owns the listening port, starting sshd when a connection arrives. Reports differ on whether a Port line in sshd_config is honoured on 24.04, so do not assume. Make the change, restart both the socket and the service, then check what is truly listening. ss -tuln lists TCP and UDP listening sockets with numeric addresses:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket ssh
ss -tuln | grep LISTEN

If it is still on 22, the socket unit is overriding you. Fix that with a proper systemd drop-in for ssh.socket, not by editing the packaged unit file, which will be replaced on upgrade. Some administrators disable socket activation altogether (stop and disable ssh.socket, then enable and start ssh.service). That works, but it is a deliberate departure from Ubuntu's default, so treat it as a choice rather than a fix.

On AlmaLinux 9, SELinux keeps a list of ports sshd is permitted to bind to, and your new port will not be on it. You must add the port to the SELinux policy as well as the firewall, or sshd will refuse to start on it. If that is unfamiliar territory, staying on port 22 with keys only is the safer call.

Either way, add the new port as a second Port line first, confirm you can connect with ssh -p 2222 [email protected], and only then remove port 22.

Step 10: Leave the ciphers alone on AlmaLinux 9

Hardening blogs love pasting a block of Ciphers, MACs and KexAlgorithms into sshd_config. On AlmaLinux 9 that is usually a mistake. Those algorithms come from the system-wide cryptographic policy (DEFAULT, LEGACY, FUTURE or FIPS), which sshd reads at start-up via /etc/crypto-policies/back-ends/opensshserver.config. Hand-written lists fight the policy and tend to age badly. Leave it on DEFAULT unless you have a compliance requirement that names something else.

If you genuinely need a client-side override, Red Hat's convention is a .conf drop-in in /etc/ssh/ssh_config.d/ with a two-digit prefix below 50 so it sorts before 50-redhat.conf, for example 49-crypto-policy-override.conf.

If you lock yourself out

It happens. Because sshd is no longer the way in, you need something that bypasses it, and that is the VNC console in Virtualizor. Switch the VPS on if it is off, open the VPS management page in Virtualizor from your Hostworld client area, click the VNC icon and launch the HTML5 VNC client. You get a console login exactly as if you were standing in front of the machine in Maidenhead. Log in as root, restore /etc/ssh/sshd_config.backup over the broken file, run sshd -t, and restart the service.

If VNC itself errors with "Failed to connect to server" or "Authentication failed", that normally needs a stop and start of the VPS from the panel. If it persists, open a support ticket rather than rebuilding in frustration. Virtualizor also offers rescue mode, a root password change and a full OS reinstall, in roughly that order of destructiveness. Rescue mode boots a separate environment so you can mount and repair the disk. Reinstalling wipes the VPS.

One related point, because it catches people at the worst moment. If you cannot get into portal.hostworld.uk either, use Forgotten Password on the client area login form. WHMCS asks for your email address and the answer to your security question if you set one, then emails a confirmation link. That link is valid for two hours from the time you requested it. If you come back the next morning and click a dead link, request a new one rather than opening a ticket. Note also that nobody, including our staff, can read or choose your password for you: an admin-side reset still sends you the same email.

Keeping it patched

SSH vulnerabilities are usually in the client as often as the server. CVE-2025-26465, for example, affected ssh(1) from OpenSSH 6.8p1 through 9.9p1 and allowed an on-path attacker to impersonate a server when VerifyHostKeyDNS was enabled (it is off by default). Run your distribution's updates on a schedule and include your laptop, not only the VPS.

What next

You now have key-only SSH on a non-root account, a firewall that allows it and a documented way back in. The next step in this series is setting up a host firewall and fail2ban on your VPS, which builds on the UFW and firewalld commands above. You will find it with the rest of our VPS guides, along with guidance on choosing between our Maidenhead and New York locations for a Linux VPS.

If something in this guide did not match what your server did, tell us which OS and what sshd -T printed when you open a support ticket. That output answers most of the questions we would otherwise have to ask.