Five things worth doing before you deploy anything on a new VPS: update the system, create a sudo user, switch to key-based SSH, disable root password login through a drop-in config file, and enable ufw without cutting off your own access.

You just got access to a new server: an IP address and a root password. The instinct is to jump straight to whatever you bought the server for - a site, a bot, a control panel. Don't, yet. Securing a fresh VPS is five things, done in about 10 minutes, and doing them now costs far less than fixing the fallout later, once there's something on the box worth losing: update the system, create a separate user, switch to key-based login, close root's password login, and turn on a firewall without locking yourself out.

Short version. SSH in as root and run apt update && apt upgrade -y. Create a regular user with adduser, add it to the sudo group. On your own machine, generate a key with ssh-keygen -t ed25519 and push it to that user with ssh-copy-id. Confirm key login actually works, and only then create /etc/ssh/sshd_config.d/10-hardening.conf with PermitRootLogin prohibit-password and PasswordAuthentication no, check it with sshd -t, and apply it with systemctl reload ssh. Finish with ufw allow OpenSSH, then and only then ufw enable - the order matters, or you'll cut off your own access.

Why root works out of the box, and why that's worth changing

On a new WeaselCloud server the panel shows ssh root@IP plus a password as the primary way to connect - deliberate, so you can get in immediately with no setup first. But a password-reachable root account has a cost: passwords can be brute-forced, and automated scanning of hosting-provider IP ranges runs more or less constantly. The longer root stays reachable by password, the higher the odds someone guesses yours. What follows doesn't hide root, it gives you a real way in instead: a separate user plus a key that brute-forcing can't reach. For the theory behind root versus sudo, see Root, su, and sudo in Ubuntu; here we take it as given.

Step 1. Update the system

Connect over SSH as root (if you haven't yet, see the Windows and macOS/Linux connection guides), then refresh packages and install available updates:

apt update && apt upgrade -y

apt update refreshes the list of available package versions from the repositories; apt upgrade -y installs updates, security patches included, without prompting per package. The image your server was built from could be weeks old, and updates since then may include something for SSH itself.

Expect a message about restarting a handful of services - apt restarts whatever the update touched, and your current SSH session survives it. If /var/run/reboot-required shows up afterward, a reboot is worth doing, just not necessarily right now.

Step 2. Create a sudo user

Working as root directly is a bad habit: one misplaced space in an rm -rf costs a lot more when nothing's stopping you from running it. Create a regular account:

adduser deploy

Swap deploy for whatever name you like. The command asks for a password (set your own - sudo will need it) and some optional details you can skip with Enter. Add the account to the sudo group, which grants permission to run commands as root:

usermod -aG sudo deploy

-a appends the group instead of replacing the user's existing ones; -G sudo names the group to add. Worth flagging: sudo under this account later asks for deploy's own password, the one you just set, not the root password from the panel.

Step 3. Set up key login for the new user

Even your own password can be brute-forced or leaked in a chat log. A key fixes both: the private half never leaves your machine, and the server only lets in whoever holds the matching key. On your own computer, not the server, generate a pair:

ssh-keygen -t ed25519 -C "you@laptop"

Press Enter on the file location prompt, then copy the public key to the new account on the server:

ssh-copy-id deploy@your-server-ip

It asks for deploy's password one last time, creates ~/.ssh for that user on the server, and appends your public key to ~/.ssh/authorized_keys with correct permissions. If ssh-copy-id isn't available, the manual fallback and a breakdown of errors like Permission denied are covered in connecting over SSH from macOS and Linux - same mechanics, for a non-root account.

This check matters more than the rest of the step. Open a second terminal window, leave the root session running, and connect as the new user:

ssh deploy@your-server-ip

If it lets you in without a password prompt (or only asks for the key's passphrase), the key works. If it doesn't, fix it now while root's session is still open - the next step closes password login entirely, and if the key genuinely isn't working, you'll lock yourself out completely.

Before these 10 minutes

After

SSH access

root, by password, from any IP

separate user, key only

Root over SSH

reachable with a password

password login closed, key access only if needed at all

Open ports

anything the system happens to listen on is reachable

only SSH and whatever you explicitly allowed in ufw

Step 4. Turn off root password login

SSH's settings live in /etc/ssh/sshd_config, but editing it directly is a bad idea - system updates can overwrite it and quietly drop your changes. Instead, use /etc/ssh/sshd_config.d/: any .conf file dropped there loads automatically and survives updates. Create one:

cat > /etc/ssh/sshd_config.d/10-hardening.conf << 'EOF'
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
EOF

PermitRootLogin prohibit-password still lets root in via an SSH key (handy for backup tooling or automation) but never with a password; to close root's SSH access entirely, use no instead, leaving only the panel's web console as a way in. PasswordAuthentication no closes password login for every account, not just root - otherwise the sudo user's password from step 2 stays exposed to the same brute-force risk. PubkeyAuthentication yes spells out key login explicitly, though it's usually already on by default.

The filename matters more than it looks. Files in sshd_config.d/ load alphabetically, and for a repeated directive the first value wins - later repeats are silently dropped. Some Ubuntu images already carry a file like 50-cloud-init.conf that turns password login back on. Name your file 90-hardening.conf and it loads after that one, so the restriction never actually takes effect, even though the file itself looks correct. That's why the name here starts with 10-: below 50, so it reliably wins.

Before reloading the service, check the syntax - success means no output at all, a typo gets you a line number:

sshd -t

Then apply it without dropping current connections:

systemctl reload ssh

On Ubuntu 24.04 the systemd unit is called ssh, not sshd - just the unit name, the binary itself is still sshd. reload, unlike restart, re-reads the config without tearing down existing sessions, yours included.

Verify in a fresh terminal window without closing the current one: a root login attempt with a password should be refused before it even offers a prompt, while your sudo user's key login keeps working as before.

Step 5. Enable ufw - in the right order

ufw is a friendlier front end for the Linux kernel's firewall, deciding which inbound connections get through. Firewalls are usually off by default on a fresh server, which is its own gap: any service that starts listening on a port, even by accident, becomes reachable from the whole internet. The rule that matters: allow SSH BEFORE turning the firewall on, or the first thing ufw enable does is cut off your own access under its default deny-all-inbound policy:

ufw allow OpenSSH

OpenSSH is a built-in application profile that adds a rule for both IPv4 and IPv6 on whatever port SSH listens on (22 by default). Moved SSH to a non-standard port? Use ufw allow <port>/tcp instead. Only now turn the firewall on:

ufw enable

It asks for confirmation with wording close to Command may disrupt existing ssh connections. Proceed with operation (y|n)? - not a malfunction, just the built-in warning for the exact scenario you avoided by allowing SSH first. Answer y, then check the resulting rule set:

ufw status

You should see active and an allowed SSH rule. Opening a port for anything else later is the same command with the port you need, e.g. ufw allow 80/tcp.

If something goes wrong

Lost SSH access - say, closed password login before confirming the key worked? The server itself is fine; only SSH is unreachable. Every server's client-area page has a web console: browser-based command-line access that bypasses SSH and any ufw rules entirely. Use it to fix whatever broke - revert the sshd_config.d change, fix up authorized_keys, or temporarily run ufw disable to sort things out.

FAQ

What to do right after getting a new VPS

Update the system, create a sudo user with key-based SSH access, disable root's password login through sshd_config.d, and enable ufw after allowing SSH. That's the entire checklist - nothing else is worth doing before it.

How to disable root password login over SSH

/etc/ssh/sshd_config.d/10-hardening.conf with PermitRootLogin prohibit-password and PasswordAuthentication no, validated with sshd -t, applied with systemctl reload ssh. Do this only after confirming key login for another account works.

How to create a sudo user on Linux

adduser username creates the account and sets a password; usermod -aG sudo username adds it to the sudo group, granting permission to run commands as root via sudo command. The password sudo asks for is the one set at account creation, not root's.

Why did ufw lock me out of SSH

Because the SSH rule wasn't added before the firewall was turned on - ufw blocks all inbound traffic that isn't explicitly allowed by default. If access is already gone, use the server's web console in the client area to get in without SSH and fix the rules.

Should I change the root password on a new server

Yes, even when closing root's password SSH login entirely: the initial password passed through the panel and an email in plain text, and it can still matter for the web console, where SSH restrictions don't apply. Details in changing a password in Ubuntu.

Key takeaways

  • The first 10 minutes on a new VPS: update the system, create a sudo user, switch to key login, close root's password login, enable ufw - in that order.
  • apt update && apt upgrade -y before installing anything else, security patches included.
  • adduser deploy plus usermod -aG sudo deploy - a dedicated account instead of living as root.
  • ssh-keygen locally, ssh-copy-id to the server, and confirm the key works in a fresh window before doing anything else.
  • Disable root's password only through /etc/ssh/sshd_config.d/, with a filename numbered below 50 so it wins the load order in that directory.
  • sshd -t to validate, systemctl reload ssh to apply without dropping sessions.
  • ufw allow OpenSSH strictly before ufw enable - otherwise the first firewall toggle cuts your own access.
  • Locked yourself out anyway - the client area's web console bypasses SSH and ufw entirely.

What's next