A VPS gives you control over server configuration, but security depends on both the hosting environment and the way you administer it. This checklist covers ten practical hardening steps for an Ubuntu VPS, from SSH access to recovery.
Internet-facing services are routinely scanned. Weak credentials, unnecessary listening services and unpatched software can give attackers an opening. A public IP address alone is not a configuration error.
Before changing SSH or firewall rules, confirm that you have a working non-root sudo account, a current backup and access to the provider’s recovery console. Keep your existing SSH session open while you test each change.
Key Takeaways
- Confirm recovery access before changing SSH or firewall rules.
- Use SSH keys and test a separate sudo login before restricting access.
- Allow only required services through host and provider firewalls.
- Maintain security updates, logs and least-privilege accounts.
- Keep independent backups and test restoration.
Why VPS Security Matters
A VPS with publicly reachable services can receive unsolicited connection attempts at any time. Limit exposure to the services you need and keep both the operating system and applications maintained.
Repeated SSH login attempts and scans for vulnerable applications are common examples. Use brute-force protection alongside strong authentication, updates and appropriate access rules. No single control guarantees that a server cannot be compromised.
10 Essential VPS Security Steps (Server Hardening Checklist)
Step 1: Use SSH Key Authentication
Generate a key pair on your own computer and install only the public key in the intended server account. Protect the private key with a passphrase and never send it to someone else. Test a new SSH connection using the key before changing password authentication. Adding a key does not, by itself, turn password login off.
Step 2: Restrict Direct Root Login
Create or verify a separate account with the sudo privileges you need. Confirm that it can sign in and run an authorized sudo command. Then set PermitRootLogin no in the effective SSH configuration. Keep the original session open and verify another login after applying the change.
Step 3: Harden SSH Access
Review /etc/ssh/sshd_config and included files under /etc/ssh/sshd_config.d/. After testing key access, review PasswordAuthentication and keyboard-interactive authentication in the context of your MFA setup. Validate syntax with sudo sshd -t before reloading SSH. A different SSH port can reduce log noise, but does not replace authentication; allow the new port in every firewall before switching.
Step 4: Restrict Network Exposure
Use trusted source-IP rules or a VPN for administrative access when practical. Confirm how administrators will connect if their public IP changes. Review both IPv4 and IPv6 exposure and any provider firewall, load balancer or container port mappings.
Step 5: Configure the UFW Host Firewall
UFW manages host firewall rules; it is not a web application firewall. Allow your actual SSH port before enabling it, then allow ports 80 and 443 only if this VPS serves a website. Review existing rules and the incoming default policy with sudo ufw status verbose. Do not replace rules blindly on a server with existing applications. Docker-published ports can bypass UFW rules, so review container exposure separately.
Step 6: Configure and Verify Fail2Ban
Fail2Ban reads configured logs and can temporarily ban source IP addresses after repeated matching failures. Installing the package is not enough: configure the relevant jail, confirm its log source or systemd backend, and check its status. Review ban thresholds and trusted administration addresses so that legitimate users are not locked out.
Step 7: Keep Packages Updated
Refresh package lists, review available upgrades and apply security updates. On Ubuntu, check the unattended-upgrades configuration and logs if you use automatic security updates. Plan service restarts and required reboots, and confirm the application still works afterward. Distribution updates do not necessarily update software installed outside its package manager.
Step 8: Remove or Disable Unnecessary Services
Inspect running services and listening ports with systemctl --type=service --state=running and sudo ss -tulpn. Identify what each service supports before disabling or removing it. Avoid exposing databases or development tools publicly when they only need local access.
Step 9: Apply Least-Privilege Access
Give each administrator an individual account and only the permissions required for their work. Run applications with dedicated service accounts rather than root where supported. Review sudo access, unused users, SSH keys and file ownership. Avoid broad permission changes such as chmod 777 as a quick fix.
Step 10: Test Backups and Recovery
Keep copies of application files, databases and essential configuration outside the VPS, with appropriate access controls and retention. Provider snapshots can help with rollback, but are not a substitute for an independent backup. Test a restore and record how long recovery takes. Use database-consistent backups for active applications.
For the SSH configuration details, see Ubuntu’s OpenSSH guide; for host rules, see Ubuntu’s firewall documentation.
Monitoring and Logging Basics
Collect authentication, service and application logs, and review alerts on a schedule. Monitoring helps you notice changes that would otherwise go unchecked.
Review repeated login failures, unexpected successful logins, new administrator accounts and service configuration changes. These events are investigation leads; a log entry alone does not establish that an account has been compromised.
Compare resource use with the application’s normal workload. An unexpected spike may have a legitimate cause, so correlate it with logs, deployments and scheduled jobs before drawing a conclusion.
Define who reviews alerts and how to escalate a suspected incident. Retain enough logs to investigate it, and protect access to those logs because they can contain sensitive information.
“so be particularly careful when editing the configuration on a remote server.”
Verify Your Security Changes
Use a second SSH session for verification and keep your original session open until you finish. Record the expected result before you change a setting. If a check fails, investigate that setting rather than applying several unrelated fixes.
Check SSH Access and Configuration
Run sudo sshd -t to check SSH configuration syntax. Successful validation normally produces no output. This does not prove that your account, key or firewall rule works: open another connection with the intended account and check that its required sudo access still works.
If you changed authentication settings, review the effective configuration with sudo sshd -T. Included configuration files and conditional Match sections can affect the result for a particular connection. Check the relevant user and source-address conditions before assuming a line in the main file applies to everyone.
Compare Listening Services with Firewall Rules
Use sudo ss -tulpn to inspect listening TCP and UDP sockets and the associated processes. Identify each service before deciding whether its port should be reachable. A listener on a loopback address serves a different purpose from one bound to every network interface.
Compare that inventory with sudo ufw status verbose and your provider firewall. Check IPv6 rules as well as IPv4. For a web server, verify the intended HTTP and HTTPS endpoints from a separate network. For an administrative service, confirm that an allowed connection succeeds and that restrictions behave as expected. Do not scan systems you do not administer.
Inspect Fail2Ban and Authentication Logs
Use sudo fail2ban-client status to see which jails are active, then inspect the configured SSH jail by its actual name. An empty jail list needs investigation; it is not evidence that login protection is running. Confirm the log source and review the configuration rather than repeatedly entering incorrect credentials on a production server.
On Ubuntu with systemd, sudo journalctl -u ssh --since "1 hour ago" can help you review recent SSH service messages. Log locations, retention and access permissions vary. Check timestamps and the time zone when matching an event to a connection attempt. Avoid posting IP addresses, usernames, tokens or other sensitive log contents in public discussions.
Confirm Updates and Restore Results
After updates, inspect failed services with systemctl --failed and test the application’s normal login and main pages. Review unattended-upgrades logs if automatic security updates are enabled. Package installation can succeed while an application still needs a restart, configuration change or compatibility check.
Restore a backup into an isolated test environment rather than overwriting the production server to prove it works. Confirm that files, database data and essential configuration are present. Check whether the restored application can start, and document the backup date and any missing dependencies.
Keep an independent copy of the recovery instructions, including the authorized console route and the location of protected backups. A recovery document stored only on the failed VPS may be unavailable when you need it. Revisit the checks whenever you add an application, change administrator access or alter the server’s networking.
Review the Application Layer Separately
Host hardening does not replace application maintenance. A patched operating system can still host an outdated website plugin, an exposed administration page or an application with weak credentials. Keep an inventory of installed applications and identify how each one receives security updates.
Use separate credentials for different applications and restrict database users to the permissions they actually need. Avoid storing secrets in public web directories or source repositories. If you discover an exposed secret, remove the exposure and rotate the credential; deleting a visible copy alone does not invalidate it.
Test login, uploads, scheduled jobs and any payment or checkout integration after a significant security change. Access restrictions that accidentally block a legitimate workflow need a controlled adjustment, not a blanket removal of every protection. Document the exception, its reason and the person responsible for reviewing it.
Common VPS Security Mistakes
Many avoidable security problems begin with configuration and maintenance gaps. Review these common examples:
- Changing SSH settings before testing a working alternative login.
- Exposing unnecessary listening services or overlooking IPv6 and container ports.
- Leaving known security updates unapplied.
- Sharing administrator accounts or reusing passwords.
- Assuming that a backup works without testing a restore.
VPS Security Checklist
Use the checklist below after deployment and again after major configuration changes. Record the result of each check, the date and who will maintain it.
- Recovery console access and a tested non-root sudo login are available.
- SSH key access works and effective authentication settings have been reviewed.
- Only required services are reachable over IPv4 and IPv6.
- Host, provider and container firewall behavior has been checked.
- Fail2Ban jails are configured and reporting the expected status.
- Security updates and any required reboots are scheduled.
- Accounts, sudo rights and service permissions have been reviewed.
- Logs and alerts are collected and checked.
- An independent backup has been restored successfully in a test.
Additional Security Practices:
- Regularly review system logs and document authentication
- Use sufficiently strong and unique credentials for all accounts
- Regularly monitor for open/active ports and services
- Time-based audit of server access and permissions
- Always have an update and recovery process documented
Why VPS Security Is a Layered System
Security controls address different failure modes. Authentication limits who can sign in, firewall rules limit reachable services, and updates remove known software vulnerabilities.
Monitoring helps you detect unexpected activity, while backups support recovery after an outage or compromise. These controls work together; installing more tools does not make up for a weak configuration.
A recovery plan should cover a failed update, lost access and a compromised application. Document how to reach the recovery console, restore a backup and rotate affected credentials.
Why UltaHost Works for Secure VPS Deployments
An UltaHost VPS with root access lets you configure the operating system, firewall and authentication. That access gives you control; it also means that those settings need active maintenance.
Check which security and administration tasks are included in your specific plan. Agree who handles operating-system updates, application patches, monitoring and backups before relying on managed support.
A Linux VPS can run the standard administration tools described here. Package names and defaults vary by distribution, so use the documentation for the operating system installed on your server.
Conclusion
Keep security work on a schedule: review access, apply updates, inspect alerts and test restores. Recheck the relevant controls whenever you add a service or change the network configuration.
These ten steps provide a starting baseline for an Ubuntu VPS. Verify each change on your own server and document exceptions rather than treating a checklist as proof that every risk is covered.
FAQ
What is the first thing I should do after getting a VPS?
First confirm recovery console access and a working sudo account. Test SSH key access in a second session before restricting authentication or direct root login.
Is a firewall necessary for VPS security?
Use appropriate host and provider firewall rules to limit reachable services. UFW is one option on Ubuntu; container port mappings and IPv6 need separate review.
Why should I disable root login on my VPS?
Disabling root login reduces risk by enforcing sudo-based access, which limits direct administrative exposure and improves accountability.
How often should I update my VPS?
You should apply updates regularly, especially security patches, as outdated software is one of the most common causes of server compromises.
Do I need backups if my VPS is already secure?
Yes, backups are still essential because security also includes recovery. They ensure your data and system can be restored after failures or attacks.
