Secure a new Ubuntu VPS: access, patching, ports and a recovery baseline

A newly provisioned VPS is infrastructure, not a finished production environment. Before publishing an application, establish how you will administer the machine, what it exposes and how it can be recovered. The checks below create a baseline you can compare against later rather than relying on a control-panel status that only says the virtual machine is running.

Confirm the machine and the administrative account

cat /etc/os-release
hostnamectl
id
sudo -v
ip -brief address
ip route

Compare the hostname and assigned addresses with Server Information in the Control Panel. Check that you are using the intended non-root administrator and can obtain the privileges required for maintenance. A public address alone does not prove server identity: verify the SSH host-key fingerprint through a trusted channel when connecting from a new workstation.

Open the browser console before making access changes. Knowing that a Console button exists is less useful than knowing you can launch it and reach the operating-system login. Keep a record of who owns the account, how recovery is authorized and where the service details are stored.

Establish key-based access and an inventory of administrators

Install a dedicated SSH public key for each administrator or managed role, verify a separate key-only login and retain the initial session until the test succeeds. Use a passphrase on the workstation's private key and protect the Control Panel account with its available authentication controls.

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

Review unexpected administrative accounts and authorized keys before treating an inherited image as ready. Do not remove a provider-required account or authentication integration without understanding its role. The separate SSH-key guide explains effective configuration, independent login tests and rollback.

Review updates and reboot requirements

sudo apt update
apt list --upgradable
sudo apt-get -s upgrade
systemctl --failed
test ! -e /var/run/reboot-required || cat /var/run/reboot-required

Review the simulated upgrade and schedule the real update for an appropriate time. Package installation can restart services, and some changes require a reboot. Check the supported release and repositories rather than assuming that any available image receives the same security coverage indefinitely.

After applying updates, verify application entry points and administrative access. A completed package command does not confirm that a website, database or background worker restarted correctly. Establish an ongoing maintenance owner and update-monitoring routine while the installation is still small.

Expose only the services your workload requires

sudo ss -lntup
systemctl list-units --type=service --state=running --no-pager
sudo ufw status verbose

Build a short list of public services, administration ports and private dependencies. A new web server might need 80/443, but a database normally does not need to listen publicly. Review both the built-in VPS firewall and any guest firewall, accounting for IPv4, IPv6 and container-published ports.

Configure and verify administration access before applying a restrictive default policy. Use the dedicated firewall guide for a staged procedure. Do not turn a first-hour checklist into a blind rule reset on a machine that already has production traffic.

Prepare recovery before destructive maintenance

Decide how files, databases and server configuration will be backed up, what recovery history you need and who will test restoration. Plenty Host's manual and automatic VPS backups are optional paid features, with automation and retention determined by the selected backup plan. Enable and verify the service you actually intend to rely on.

Create a recovery point before a major change and confirm that it completes. Restoring a VPS backup replaces current server data and can restore the saved operating-system password. OS reinstallation is also destructive. Keep separate application copies where your recovery needs require them and avoid treating an untested schedule as proof that recoverable data exists.

Capture a baseline and a simple acceptance test

umask 077
mkdir -p ~/server-baseline
date -Is > ~/server-baseline/created.txt
uname -a > ~/server-baseline/kernel.txt
dpkg-query -W > ~/server-baseline/packages.txt
sudo ss -lntup > ~/server-baseline/listeners.txt
df -h > ~/server-baseline/storage.txt

Keep this directory outside the website document root. Add the intended application URL, expected response, backup owner and maintenance contact to your operational notes. Test the public service from another machine and verify logs and resource statistics in the panel.

The first-hour outcome should be measurable: a verified administrator can reconnect, intended services work, unwanted services are not public, updates have an owner and recovery has been planned. Those checks are a stronger starting point than installing extra security tools without a clear purpose.

Primary documentation

• Ubuntu OpenSSH server
• Ubuntu security updates
• Ubuntu host firewall configuration
• Ubuntu automatic updates