How to Secure an Ubuntu VPS: SSH, UFW, and Automatic Updates

A new Ubuntu VPS should be secured before it hosts a public website or application. The essential first steps are to create a non-root administrator, prove that SSH key authentication works, restrict inbound traffic with UFW, and confirm that security updates are applied. This guide presents a cautious sequence designed to reduce exposure without locking you out of a remote server.

The commands are suitable for a current, supported Ubuntu Server release. Run them from an existing administrative SSH session, and keep that session open until a second connection has passed every login test. Provider images and preinstalled control panels can change defaults, so inspect the current configuration before replacing anything.

Before changing remote access

Take a recoverable backup or snapshot if your provider offers one, and confirm that you have console or recovery access. A firewall or SSH error can make a healthy VPS unreachable. Mailitus explicitly describes its WordPress hosting VPS as self-administered and without provider backups, so the administrator is responsible for both configuration and recovery planning.

Record the Ubuntu release, listening services, and SSH configuration:

cat /etc/os-release
sudo ss -tulpn
sudo sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication) '

sshd -T shows the effective SSH settings after included configuration files are processed. Do not assume that a commented line in /etc/ssh/sshd_config represents the active value.

Create a named administrator

Routine administration should use a named account rather than direct root login. Replace adminuser with your chosen account name:

sudo adduser adminuser
sudo usermod -aG sudo adminuser
id adminuser

Use id to confirm membership in the sudo group. Do not close the original session yet.

Configure and test SSH keys

Generate a key on your local computer

Ubuntu recommends Ed25519 for its short keys and low computational requirements. Generate the key on the computer from which you will connect, not on the VPS:

ssh-keygen -t ed25519 -a 100 -C "admin VPS access"

Protect the private key with a strong passphrase and keep it off the server. Copy only the public key:

ssh-copy-id adminuser@SERVER_IP

If ssh-copy-id is unavailable, add the single-line public key to /home/adminuser/.ssh/authorized_keys through your existing session. Then enforce ownership and permissions:

sudo install -d -m 700 -o adminuser -g adminuser /home/adminuser/.ssh
sudo chown adminuser:adminuser /home/adminuser/.ssh/authorized_keys
sudo chmod 600 /home/adminuser/.ssh/authorized_keys

Prove the new login before hardening SSH

Open a second terminal and connect explicitly with the new account:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 adminuser@SERVER_IP
sudo -v

Continue only when both key login and sudo work. Leave this second session open as well.

Disable risky login paths safely

Ubuntu supports modular snippets in /etc/ssh/sshd_config.d/. Create a focused file instead of rewriting the distribution configuration:

sudoedit /etc/ssh/sshd_config.d/10-vps-hardening.conf

Add:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Disabling password and keyboard-interactive authentication is appropriate only after a key-based login succeeds. It can also affect automation, SFTP users, or control panels that depend on those methods.

Validate the complete configuration before applying it:

sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

If sshd -t prints an error, fix it before proceeding. When validation is clean, reload rather than abruptly stopping the service:

sudo systemctl reload ssh.service

Open a third terminal and repeat the key login. Also verify that an intended invalid method is refused. Keep at least one known-good session open until all network changes are complete.

Allow only required traffic with UFW

UFW is Ubuntu’s default host-firewall tool, but it starts disabled. List application profiles and current status first:

sudo ufw status verbose
sudo ufw app list

Permit SSH before enabling the firewall. If SSH listens on port 22:

sudo ufw allow OpenSSH

For a custom SSH port, allow the actual port explicitly, for example sudo ufw allow 2222/tcp. If you have a stable administrative source address, a narrower rule is safer:

sudo ufw allow proto tcp from 203.0.113.10 to any port 22

Replace the documentation address with your real public IP. Do not use a source-restricted rule if your address changes unexpectedly.

For a web server, allow HTTP and HTTPS only when those services are installed and intended to be public:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered
sudo ufw enable
sudo ufw status verbose

Test a fresh SSH connection immediately. A VPS may also sit behind a provider firewall or a virtual router such as the MikroTik component described in the Mailitus VPS service overview. Host and upstream rules must agree, but opening a port in one layer does not require exposing it in every layer.

Apply and automate security updates

Refresh package metadata, review available changes, and apply current upgrades during a maintenance window:

sudo apt update
apt list --upgradable
sudo apt upgrade

Ubuntu Server uses unattended-upgrades for automatic security updates and normally includes it by default. Confirm the package and periodic settings rather than assuming they are active:

dpkg -s unattended-upgrades | grep '^Status'
cat /etc/apt/apt.conf.d/20auto-upgrades
systemctl status apt-daily-upgrade.timer --no-pager

If the package is missing, install and enable it:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Review /etc/apt/apt.conf.d/50unattended-upgrades before changing allowed origins, automatic reboots, or package exclusions. Third-party repositories are not automatically included merely because they exist in APT. On production systems, note that Ubuntu 24.04 LTS and later can automatically restart affected services through needrestart; coordinate this with maintenance and application health checks.

Inspect results and reboot requirements:

sudo unattended-upgrade --dry-run --debug
sudo tail -n 100 /var/log/unattended-upgrades/unattended-upgrades.log
test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs

A dry run is diagnostic, not proof that future updates will never disrupt a service. Backups, application tests, monitoring, and a documented rollback procedure remain necessary.

Verify the final security baseline

Finish with a short audit from both the server and a separate client:

sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '
sudo ufw status verbose
sudo ss -tulpn
systemctl --failed
sudo journalctl -u ssh.service --since today --no-pager

Confirm that only expected ports listen publicly, root and password SSH access are disabled as intended, the named administrator can reconnect, and no essential unit has failed. Schedule periodic reviews because users, keys, packages, and exposed services change over time.

Risks and limitations

Firewall and SSH changes can lock out every remote administrator. Maintain console access and test each stage in a separate session.
Disabling password authentication does not revoke existing authorized keys. Review every user’s authorized_keys files and remove stale access.
UFW controls the VPS host, not upstream routers, provider firewalls, application authorization, or vulnerabilities in listening software.
Automatic updates reduce exposure to known flaws but can restart services and do not replace backups, monitoring, least privilege, or incident response.
Do not copy rules blindly to a server managed by a hosting panel. Confirm which component owns SSH, firewall, and update configuration.

Conclusion

A secure Ubuntu VPS baseline is a sequence, not a single command: establish recoverable access, prove SSH keys, validate configuration, allow the real SSH path, enable the firewall, and monitor automatic security updates. Recheck each control from a new connection before closing the original session.

If you need a self-administered Ubuntu environment for a WordPress deployment, review the verified Mailitus WordPress hosting VPS page, including its administration and backup responsibilities, before choosing a service.

Sources and further reading

Information verified: October 15, 2026