Secure a VPS in a safe order: confirm you can recover access, identify and update the system, establish a tested non-root administrator account, restrict network exposure, then set up monitoring and backups. Make one change at a time and verify it before closing your existing SSH session. These steps reduce common risks; they do not guarantee that a server is secure or replace a security assessment.
What to check before you change anything
Start by recording what the server actually runs and how you would regain control if a change blocks your access. VPS defaults vary by provider, Linux distribution and release, network design, containers, and hosted applications, so do not apply a generic rule without checking its effect on your setup.
- Identify the distribution and release, hosting provider, public network interfaces, running services, and any container or private-network arrangement.
- Check whether the installed release is still maintained. Consult the distribution’s official lifecycle information and security tracker for that specific release; a familiar version number alone does not establish support status. Debian’s security FAQ explains Debian security support, but check release-specific information for your system.
- Find and test the provider’s recovery console, rescue environment, or other out-of-band access route before changing SSH or firewall settings.
- Keep your current SSH session open while making remote-access changes. Use a separate session to test the new login before closing the original one.
- Note which public services must remain reachable, including any application, mail, or management services your workload depends on.
Provider features are not Linux defaults. For example, DigitalOcean’s recommended Droplet setup combines SSH keys, a sudo-enabled non-root user, a cloud firewall, backups, VPC, IPv6, and monitoring. Treat that as guidance for that provider’s Droplets, not a universal configuration recipe.
How to patch the system and reduce unused software
Install available updates before adding more hardening controls. Ubuntu’s security suggestions recommends regular updates and gives this command for Ubuntu systems using APT:
#1 Best Overall
sudo apt update && sudo apt upgrade
Review package changes and plan any service restarts or reboot the updates require around the needs of your workload. Ubuntu also documents unattended-upgrades for automatically fetching and installing security updates and bug fixes; its documented default run frequency is daily, and its behavior can be configured. Automatic installation is useful only if someone monitors results and handles updates that need intervention.
- Remove packages and services the server does not need, after confirming they are not dependencies of your application or provider tooling.
- Be cautious with third-party repositories: adding one expands the set of software sources you rely on. Understand its maintainer and update process before enabling it.
- Keep track of the installed release’s support status over time and plan a supported upgrade when necessary.
How to create a safer administrator and secure SSH
Use a named account for routine administration instead of logging in as root. Grant that account only the privileges it needs, and use sudo for administrative tasks. Ubuntu recommends non-root accounts with as few privileges as possible; DigitalOcean likewise recommends a sudo-enabled non-root user and SSH keys in its Droplet setup guidance.
- Create or identify the named administrator account and install its SSH public key using the instructions for your distribution and provider.
- Open a second SSH session and confirm that the account can log in with the key and perform required administrative tasks.
- Confirm that the provider recovery route works before restricting existing login methods.
- Only after both checks succeed, change root-login or password-authentication settings if appropriate for your environment.
- Test the new configuration from another session before closing the original SSH connection.
Do not assume that changing one file changes the active SSH policy. Configuration includes, cloud-init snippets, and service reload behavior vary across installations. Use the OpenSSH sshd_config manual to understand directives, then validate the effective configuration and reload procedure for the installed OpenSSH version and distribution.
For a production or sensitive system, consider stronger authentication such as a FIDO2 security key or MFA where the SSH client and server setup support it. This is an additional control to assess, not a prerequisite for the baseline steps.
How to limit the VPS’s public network exposure
Allow only the traffic required by the services you intend to make public. First inventory listening services and their purpose; then choose provider-level rules, a host firewall, or both according to how your existing network is designed. Ubuntu identifies UFW as its firewall configuration tool, while DigitalOcean describes cloud firewalls as a way to control traffic to and from Droplets and reduce publicly reachable services.
- Keep databases, caches, and administration interfaces private unless they genuinely need public access.
- Check both IPv4 and IPv6 rules. A restriction that applies to one address family may not provide the same protection for the other.
- Account for containers, forwarding, VPNs, provider networking, and private interfaces before changing firewall rules; a rule that is sensible for a simple host can disrupt routing or application connectivity elsewhere.
- Do not stack, replace, or reconfigure firewall frontends unless you understand which rules are active and how they interact.
DigitalOcean’s Droplet security best-practices guide describes provider firewalling and backups in its own product context. Check your provider’s documentation for the rules and recovery behavior available on your VPS.
What monitoring and additional controls should you add?
Choose controls that match the workload and that someone can maintain. Enabling a feature without reviewing alerts or logs does not provide much operational protection.
- For Ubuntu hosts: consider AppArmor to restrict application capabilities, as described in Ubuntu’s security guidance.
- For administration: a VPN or bastion can limit where administrative connections come from, if it fits your network and recovery plan.
- For production or sensitive systems: consider persistent, remote logs; external alerts; audit tooling; stronger authentication; and backup repositories with protections against alteration.
- For any monitoring setup: decide who reviews update status, service health, security-relevant logs, and alerts, and how they will respond.
How to back up the VPS and prove you can restore it
Backups are part of security because they can help recover from accidental deletion, hardware or service failure, and compromise. Provider backups may be useful, but they are not proof that a usable restore is available. DigitalOcean describes its backups as system-level disk images that can restore a Droplet or support rebuilding; its security best-practices guide also notes that an incomplete or corrupt backup makes restoration harder.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Choose backup coverage that fits what you must recover, including relevant system data and application data.
- Keep an off-host copy when the failure or compromise scenario could also affect provider-held backups.
- Document the restore steps and the access or credentials they require.
- Perform a test restore in a suitable environment and confirm the recovered system or data is usable.
A snapshot can be valuable for rollback or rebuilding, but it is not automatically an independent backup strategy. Set recovery expectations only after a restore test establishes what your setup can actually recover.
How to verify the hardening changes
After each change, check its real effect rather than assuming that a successful command or saved file means the control is active. Keep a dated record of the recovery route, administrative access method, intended public services, firewall exceptions, update process, monitoring owner, and backup restore procedure.
- Confirm that the intended SSH account and recovery route still work.
- Review active firewall rules and verify that required public services remain reachable while private services are not unnecessarily exposed.
- Check that updates are being applied and that any required restart or reboot has been handled.
- Verify that monitoring produces reviewable logs or alerts and that someone is responsible for them.
- Confirm that the documented backup can be restored using the tested procedure.
There is no universal audit command or single security score that proves a VPS is secure. Recheck these controls when the operating system, application, network design, or provider configuration changes.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute
