Ubuntu administration guide

Secure a new Ubuntu VPS step by step

Secure a new Ubuntu VPS by updating it, creating a named administrator, proving key-based SSH access, restricting exposed services, enabling a host firewall, and arranging monitoring and backups. Perform each change in order, keep the provider console available, and never close the original SSH session until a second connection succeeds.

Author VPSEverywhere.comReviewed by VPSEverywhere editorial team

Key facts

Applies to
Supported Ubuntu Server releases using systemd and OpenSSH
Primary safeguard
Maintain console access and test a second session
Authentication
Passphrase-protected SSH key for a named user
Recovery
Independent backup plus a tested restore

Update and inspect before changing access

Take a provider snapshot only if the platform offers one and you understand that it is not an independent backup. Sign in through the documented initial method, confirm the operating-system image, and apply repository updates with sudo apt update followed by sudo apt full-upgrade. Read prompts before accepting configuration-file replacements, then run sudo reboot if a kernel or core component requires it.

Reconnect and inventory listeners with sudo ss -tulpn. Every public listener should have an owner and purpose. A minimal Ubuntu cloud image may differ from an installer image, so never assume which services are enabled. Record the baseline before installing an application stack.

  • Use only repositories and keys you intentionally trust.
  • Remove unused software after confirming it is not a dependency.
  • Schedule updates rather than leaving the first upgrade as a one-time event.

Create a named administrator and prove SSH keys

Create a separate account with sudo adduser deploy, replacing deploy with your chosen name, then grant administrative access with sudo usermod -aG sudo deploy. Add the public half of your SSH key to that user's ~/.ssh/authorized_keys using the provider's key feature or ssh-copy-id. Never upload the private-key file.

Open a second terminal and test ssh deploy@SERVER_IP. Confirm sudo -v works. Only after that test should you consider disabling direct root and password login. Edit a drop-in with sudoedit /etc/ssh/sshd_config.d/60-local-hardening.conf, set PermitRootLogin no and PasswordAuthentication no, validate with sudo sshd -t, then reload with sudo systemctl reload ssh. Keep the existing session open and test again.

  • Replace all example names and addresses explicitly.
  • Use a local passphrase and a password manager or secure agent.
  • If validation fails, fix the file; do not reload SSH.

Allow only required network services

Ubuntu's UFW is a convenient host-firewall interface. First ensure your SSH service uses the expected port. Permit it with sudo ufw allow OpenSSH; if you deliberately changed the port, create the matching rule instead. Inspect the proposed state with sudo ufw status verbose, enable with sudo ufw enable, and verify access from a new terminal before closing the old one.

Add application ports only when the service is installed and ready. For a web server this commonly means TCP 80 and 443, but no universal list exists. A provider firewall and UFW can complement each other; document both so an incident responder knows which layer blocked traffic.

  • Never enable a default-deny firewall remotely without an SSH allow rule.
  • Bind private databases to local or private interfaces.
  • Re-run sudo ss -tulpn after deploying software.

Turn hardening into an operating routine

Install and review automatic security updates with sudo apt install unattended-upgrades, then configure them according to your maintenance and reboot policy. Monitor disk, memory, authentication failures, service health, certificate expiry, and backup results. Do not expose a monitoring agent without authentication and network restrictions.

Create an independent, versioned backup and restore it into an isolated test system. Store recovery codes and console instructions separately from the VPS. Security settings evolve, so compare this generic checklist with current Ubuntu documentation and the needs of your application before production.

  • Review administrator accounts and keys regularly.
  • Patch applications as well as the operating system.
  • Document a recovery path before removing any login method.

Sources

  1. Ubuntu Server firewall documentation
  2. Ubuntu security documentation
Frequently asked questions

Frequently asked questions

Should I change the SSH port?

It may reduce routine scan noise but is not a substitute for key authentication, patching, access controls, and monitoring. If you change it, update every firewall layer and test before ending the session.

Can I disable root login immediately?

Only after a named user can authenticate by key, obtain required sudo access, and reconnect in a separate session. Keep console recovery available.

Is UFW enough to secure the VPS?

No. A firewall limits network reachability; it does not patch vulnerable software, protect stolen credentials, secure application logic, or replace backups.

Configure a VPSView pricing