How to Secure Your VPS with Full Root Access

A Virtual Private Server (VPS) gives you greater control over your hosting environment. With full root access, you can install software, configure services, manage users, run databases, deploy applications and customize the operating system to suit your requirements.

That flexibility comes with an important responsibility: you are responsible for securing the operating system and the services running on it.

An exposed SSH service, an outdated application, a weak administrator password or a misconfigured firewall can create an opportunity for attackers to compromise your server. If an attacker obtains root privileges, they may be able to access sensitive files, modify system settings, install malicious software or disrupt your applications.

Securing a VPS does not require making every possible security change at once. It requires establishing sensible controls, understanding what is exposed to the internet and maintaining the server consistently.

In this guide, we explain how to secure a VPS with full root access, from the first login to ongoing monitoring and recovery planning. The practical commands use Ubuntu and Debian as examples; AlmaLinux, Rocky Linux and other distributions may require different commands and configuration paths.

What Does Full Root Access Mean?

Root is the administrative account on a Linux system. It has extensive privileges to manage the operating system, access files, change permissions, install packages, configure services and create or remove user accounts.

On a VPS with full root access, you normally have the ability to make these changes without relying on a hosting provider to perform each task.

This is useful for developers and businesses that need to run custom applications, deploy Docker containers, configure databases or install software that is not available in standard shared hosting.

However, root privileges also increase the consequences of mistakes.

For example:

• An incorrect firewall rule can prevent you from accessing the server.

• A command executed with excessive privileges can delete important files.

• A compromised root session may give an attacker control over the entire server.

• An insecure application running with root privileges may expose the operating system to greater risk.

The goal is not to avoid root access altogether. It is to use it deliberately and introduce controls that reduce the likelihood and impact of compromise.

1. Secure Your Hosting Provider Account First

Your server's security begins before you log in to Linux.

The hosting provider's control panel or account may allow you to create servers, access recovery consoles, modify network rules, manage snapshots or reset credentials. Someone who compromises that account may be able to bypass some of your operating-system protections.

Start by securing the account used to manage your VPS.

Use strong authentication

Use a unique, strong password for the hosting account. Enable multi-factor authentication (MFA) wherever it is available.

MFA adds another authentication step, helping reduce the risk of an attacker gaining access with a stolen password alone.

Restrict access to the control panel

Give access only to people who need it. Review authorized users, remove access when team members leave and avoid sharing administrator credentials.

If the provider supports separate user roles, use the least privileged role that allows each person to complete their responsibilities.

Protect recovery options and API keys

Keep account recovery details current and protect API tokens, recovery codes and other administrative credentials.

An API token with permission to create servers, change firewall settings or access snapshots should be treated as a sensitive credential. Remove tokens that are no longer used and limit permissions where supported.

Why this matters: A secure Linux server is only one part of the security picture. Provider-account security, recovery access and network-level controls also need attention.

2. Update the Operating System and Installed Software

Fresh VPS installations still require maintenance. Security vulnerabilities are discovered in operating systems, web servers, databases, programming runtimes and third-party applications.

Installing updates helps address known vulnerabilities and improves system stability.

Ubuntu's official security guidance recommends regularly updating system software and describes options for automated security updates. Read the Ubuntu Server security suggestions.

Update an Ubuntu or Debian VPS

Connect to your server and run:

sudo apt update
sudo apt upgrade

The first command refreshes the package information. The second installs available upgrades for installed packages.

Review prompts and service changes rather than blindly confirming every action on a production system. Some changes may require a service restart or a server reboot.

After updates, check whether a reboot is required and plan it appropriately for production applications.

Enable automatic security updates where appropriate

On Ubuntu and Debian systems that support the package, unattended-upgrades can automate selected updates.

For example:

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

Review its configuration and logs after setup. Automatic update policies should reflect your application's compatibility, maintenance windows and recovery arrangements.

See the Ubuntu automatic updates guide for configuration details.

Do not forget application dependencies

Updating the operating system does not necessarily update every application you run.

Also review:

• Node.js and Python runtimes.

• PHP and its extensions.

• Web server software such as Nginx or Apache.

• Databases such as MySQL, MariaDB or PostgreSQL.

• Docker Engine and container images.

• Application frameworks and third-party dependencies.

• Hosting control panels and other installed services.

For production applications, test significant dependency updates in staging where practical. Use supported software versions and have a recovery plan before making major changes.

3. Create a Non-Root Administrative User

One of the most important VPS security practices is to avoid using the root account for routine administration.

Instead, create a separate user account and grant it administrative privileges through sudo.

This allows you to run privileged commands when necessary without using a root session for every task.

For Ubuntu or Debian, an example is:

sudo adduser adminuser
sudo usermod -aG sudo adminuser

Replace adminuser with your chosen username.

If you are already logged in as root, you can run the equivalent commands without the sudo prefix. On AlmaLinux or Rocky Linux, administrative group configuration may differ; consult the relevant distribution documentation.

Test the account

Before changing your SSH configuration, make sure the new account can log in and use administrative privileges.

ssh adminuser@SERVER_IP

Replace SERVER_IP with your server's IP address.

Once connected, check that sudo works:

sudo -v

If necessary, test a root shell:

sudo -i

You should only continue to the next steps after confirming that the administrative account works.

Important: A non-root user with unrestricted sudo privileges can still make system-wide changes. The benefit is controlled privilege elevation and better separation of routine activity from administrative actions, not the elimination of administrative power.

4. Secure SSH with Public-Key Authentication

SSH, or Secure Shell, is commonly used to administer Linux servers remotely.

If SSH is accessible from the internet, it will often receive automated connection attempts. Strong authentication and sensible access restrictions reduce the risk of unauthorized login.

Generate an SSH key pair

On your own computer, open a terminal and run:

ssh-keygen -t ed25519 -a 100

Follow the prompts and protect your private key with a passphrase.

The command creates a private key and a public key. The public key can be copied to the server, but the private key must remain under your control.

Do not upload your private key to a website, share it in a ticket or store it in a publicly accessible directory.

Copy the public key to your VPS

If your system supports ssh-copy-id, run:

ssh-copy-id adminuser@SERVER_IP

This installs the public key for the specified user, assuming you can authenticate to the server using an available method.

If ssh-copy-id is unavailable, follow the relevant operating system instructions to add the public key to the user's ~/.ssh/authorized_keys file with appropriate ownership and permissions.

Test key-based access

Open a new terminal window and connect using the administrative account.

ssh adminuser@SERVER_IP

Confirm that you can authenticate using the intended key and that administrative commands still work. Do not disable your existing access method until the new one is verified.

Ubuntu's official OpenSSH Server documentation provides further guidance on key generation, installation and SSH configuration.

5. Disable Direct Root Login Over SSH

Once you have verified your administrative account and SSH key, consider disabling direct root login over SSH.

You will still be able to perform authorized administrative tasks using sudo, but remote SSH connections will not authenticate directly as root.

On many Ubuntu installations, SSH configuration snippets can be stored in /etc/ssh/sshd_config.d/. Other distributions and preconfigured VPS images may use different configuration arrangements.

For Ubuntu or Debian systems that support the configuration directory, one possible approach is to create a file such as:

sudo nano /etc/ssh/sshd_config.d/00-vps-hardening.conf

Add:

PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication no

These settings enable public-key authentication, disable direct root login and disable SSH password authentication.

Do not apply this configuration until key-based access for your administrative user has been tested. If you depend on password-based SSH authentication, enabling these settings before installing and testing the key could lock you out.

Check the configuration before reloading SSH

Run:

sudo sshd -t

If the command reports an error, correct it before continuing.

You can inspect effective settings on supported OpenSSH systems with:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication'

Review your existing configuration and any included files. Some cloud images or provider configurations set authentication options earlier in the configuration process, which may take precedence.

If you use MFA through PAM or keyboard-interactive authentication, review those settings separately before disabling them. Authentication requirements should be configured as a complete system rather than copied blindly from a template.

After verifying the settings, reload the appropriate SSH service. On many Ubuntu and Debian systems:

sudo systemctl reload ssh

Other distributions may use the service name sshd.

Keep your current SSH session open. Open another terminal and confirm that you can still connect and use sudo before closing it. Also make sure you understand how to reach the provider's recovery console in case SSH access is lost.

6. Configure a Firewall and Allow Only Required Ports

A firewall helps control which network connections can reach your VPS.

A server should generally expose only the services required for its purpose. For example, a public website may need HTTP and HTTPS access, while administrative services and databases should remain restricted.

Ubuntu provides the Uncomplicated Firewall (ufw) as a user-friendly interface for managing host firewall rules. See the Ubuntu firewall guide.

Example firewall configuration

On a suitable Ubuntu or Debian system using UFW, first ensure that your current SSH port is allowed.

For a server using the default SSH port:

sudo ufw allow OpenSSH
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

This permits the OpenSSH profile, denies other incoming connections by default and allows outbound connections unless additional rules restrict them.

The order and exact rules should be planned before enabling the firewall. If your SSH service uses a different port, allow that port instead. If you connect through a provider console, VPN or restricted management network, configure those access paths appropriately.

Open only the ports your applications need

Common examples include:

These are common defaults; applications can use other ports.

Use sudo ss -tulpn to inspect services listening on the system, then verify whether each needs to be reachable from outside.

Remember that a cloud provider may also offer a separate network firewall. Host-level rules and provider-level firewall rules need to work together.

If your hosting control panel or security tooling manages the firewall, follow its supported configuration method rather than enabling competing firewall managers blindly.

7. Remove Unnecessary Services and Restrict Network Exposure

Every service listening for incoming connections is something you should understand and manage.

An application may install supporting services that you do not need in production. Leaving unnecessary services running increases the amount of software you must maintain and the number of potential exposure points.

Review listening ports

Run:

sudo ss -tulpn

Review the processes and ports shown.

For each service, determine:

• What application owns it?

• Does the website or application need it?

• Should the service be reachable from the internet?

• Can it listen only on localhost or a private network?

• Is authentication enabled where required?

Protect databases and caches

A common mistake is to allow public access to a database simply because the application needs to connect to it.

If the application and database run on the same server, the database may be able to listen on localhost. If they run on separate servers, use a private network, firewall restrictions and appropriate database authentication.

Do not assume that a database is secure just because it requires a password. Reducing network exposure is an important additional layer of protection.

Disable services carefully

Before disabling or removing a service, confirm what depends on it. Removing a package or stopping the wrong service can interrupt applications or make the server harder to administer.

The aim is not to eliminate every service. It is to keep only what you need, configure it appropriately and maintain it.

8. Apply the Principle of Least Privilege to Applications

A secure VPS uses root privileges only when required.

Your website, API, scheduled jobs and background workers should normally run as dedicated non-root users or accounts appropriate to the chosen platform.

For example, a Python web application and a Node.js API can each run under their own service accounts with access to only the files and resources they need.

Use appropriate file permissions

Avoid making application directories writable by every user.

Commands such as chmod -R 777 grant broad permissions and can allow unintended users or processes to modify files. Instead, set appropriate ownership and permissions for your application, web server and deployment process.

Protect environment variables and secrets

Database passwords, API tokens, SSH private keys and other secrets should not be committed to Git or placed in publicly accessible directories.

Restrict access to environment files and use a suitable secret-management mechanism where available. If a secret is exposed, revoke or rotate it rather than merely deleting the visible copy.

Be careful with Docker privileges

Containers can help isolate application dependencies, but they do not automatically secure a server.

Avoid running application processes as root inside containers when it is unnecessary. Protect the Docker daemon and its socket. Membership in the docker group can provide privileges effectively equivalent to root on the host, so do not treat it as an ordinary unprivileged user group.

Review the permissions, mounts, exposed ports and capabilities granted to each container.

9. Strengthen SSH Further with Access Restrictions and MFA

SSH keys and disabling direct root login are strong starting points, but additional controls may be appropriate for sensitive production environments.

Restrict SSH by source IP where practical

If administrators connect from a known office network or VPN, consider limiting SSH access to those sources using your firewall.

This can reduce exposure to random connection attempts. However, ensure the rule accounts for legitimate changes in administrator IP addresses and includes a recovery path.

Consider multi-factor authentication

For servers that handle important business data, SSH MFA may provide an additional layer of protection.

The configuration depends on the authentication method and environment. Test the complete login flow before enforcing it, especially if the setup uses PAM or keyboard-interactive authentication.

Consider intrusion-prevention tools

Tools such as Fail2ban can monitor selected logs and temporarily block addresses that repeatedly trigger configured failures.

They are an additional control, not a replacement for secure keys, restricted access, updates and firewall rules. Configure and test the applicable jail rather than assuming installation alone provides the intended protection.

Do not rely on changing the SSH port alone

Moving SSH to a non-standard port may reduce some automated scanning noise, but it does not replace strong authentication or access restrictions. If you change the port, update firewall rules and verify access before ending your current session.

10. Set Up Backups and a Recovery Plan

Security controls reduce risk, but they cannot guarantee that your server will never experience data loss or compromise.

A backup strategy gives you a way to recover from accidental deletion, a failed update, a compromised application, a storage problem or other serious incident.

Back up the data that matters

Depending on your application, that may include:

• Application files and deployed code.

• Databases and transaction records.

• Uploaded files and user-generated content.

• Configuration files necessary for restoration.

• Critical infrastructure and deployment documentation.

Do not assume that a copy of the server's main files contains everything required to recover the application.

Keep backups separate from the live server

Where possible, maintain a copy in separate storage or a separate failure domain. Protect backup access with appropriate permissions and use encryption where necessary.

If an attacker compromises the VPS, backups stored only on that same server may be affected too.

Test restoration

A backup is not proven useful simply because a backup job completed.

Periodically restore data to a test environment. Confirm that the application starts correctly and that important records and functions are available.

For business-critical applications, document who is responsible for restoration and how long recovery is expected to take.

Understand the difference between snapshots and backups

A provider snapshot can be useful before an upgrade or risky system change, but a snapshot is not automatically a complete backup strategy. Its coverage, retention, accessibility and failure domain depend on the provider's implementation.

Use additional backups where necessary and verify the specific recovery options available with your hosting plan.

SteboHost's VPS and Cloud Hosting page describes full root access and on-demand snapshots for its VPS plans. Check the current plan terms and ask about scheduled backup retention if you need automated daily backups.

11. Monitor Logs, Resources and Suspicious Activity

You cannot manage the security of a VPS effectively if you do not know what is happening on it.

Monitoring helps you detect unexpected service changes, repeated authentication failures, resource exhaustion and other warning signs.

Check system logs

On many Ubuntu and Debian systems, SSH activity can be inspected using:

sudo journalctl -u ssh --since "24 hours ago"

Some distributions use sshd as the service name, and log locations vary. Investigate unusual failures, unfamiliar successful logins and unexpected service restarts.

Do not assume every failed SSH attempt means the server has been compromised; internet-facing servers commonly receive automated login attempts. Focus on unusual patterns and successful access that you cannot explain.

Monitor system resources

Useful commands include:

df -h
free -h
uptime

These provide a quick view of disk use, memory and system load.

Also monitor CPU, application response time, network traffic and the health of important services. Set alerts for thresholds that could affect availability, such as a nearly full disk or a stopped application.

Review user accounts and authorized keys

Periodically review which users have administrative privileges and who has SSH keys installed.

Remove access that is no longer required, rotate credentials after personnel or access changes, and investigate keys you cannot identify.

Maintain an incident response process

If you suspect a compromise, preserve relevant logs and evidence, restrict unauthorized access, rotate affected credentials from a trusted environment and investigate how the attacker gained access. Restoring a backup without fixing the underlying weakness may allow the compromise to happen again.

12. Secure the Website and Services Running on the VPS

Securing the operating system is only one part of a complete server security plan.

An application can still be vulnerable even if SSH, the firewall and system updates are configured correctly.

Use HTTPS for public websites and APIs

Configure TLS certificates for public web applications and make sure renewal is monitored. Protect administrative interfaces and sensitive application traffic with suitable authentication.

HTTPS protects traffic in transit, but it does not make vulnerable application code safe.

Harden the web application

Keep frameworks, plugins and dependencies updated. Remove test applications and unused components from production. Validate input, enforce authentication and authorization, and restrict access to administrative functions.

Separate production and testing

Avoid exposing development services, debug endpoints or temporary test environments to the public internet without appropriate controls.

Use separate credentials for testing and production, and make sure test data does not expose sensitive real-world records.

Understand what the hosting provider protects

A provider may monitor physical infrastructure, the network or host availability while the customer remains responsible for the operating system, packages, application configuration and access controls.

Clarify the division of responsibility so that essential tasks are not overlooked.

VPS Security Checklist Before Going Live

Before making a newly configured VPS publicly available, review these areas.

This checklist is a starting point, not a guarantee of complete security. Requirements vary according to the operating system, workload, data sensitivity and exposure of the services.

Common VPS Security Mistakes to Avoid

Using root for every task. Root access should be reserved for operations that require elevated privileges.

Disabling password access before testing SSH keys. This can lock you out of a remote server. Verify a working alternative first.

Opening too many ports. A service should not be publicly reachable just because it has a listening port.

Ignoring operating system and application updates. A secure initial configuration can deteriorate if known vulnerabilities remain unpatched.

Relying entirely on the provider's infrastructure security. Provider-level monitoring cannot replace correct configuration of the guest operating system and applications.

Treating snapshots as the only recovery mechanism. Check snapshot retention and scope, maintain appropriate backups and test restoration.

Running every application as root. A compromised application running with extensive privileges can cause more damage.

Assuming a firewall blocks every attack. A firewall controls network traffic, but it does not fix vulnerable applications, stolen credentials or malicious software already running on the server.

How SteboHost Fits into VPS Security

A VPS with full root access is suitable for workloads that need control over the operating system, software stack and deployment process. That control also means the server administrator must take responsibility for ongoing security and maintenance.

SteboHost's VPS and Cloud Hosting options list full root access, dedicated CPU and RAM, and on-demand snapshots. The service information also distinguishes infrastructure monitoring from operating-system maintenance, which remains the customer's responsibility on a self-managed VPS.

Before choosing a configuration, consider the operating system, memory, CPU, storage, network exposure and recovery needs of the application. If you do not want to manage security patches and system administration yourself, ask about managed support and clarify exactly which responsibilities it covers.

You can review the SteboHost hosting options to compare hosting approaches and decide which environment fits your technical requirements.

Conclusion

Full root access gives you the freedom to configure a VPS around your applications, but it also places important security decisions in your hands.

A secure VPS begins with a protected hosting account, timely updates, a non-root administrative user, secure SSH authentication and a properly configured firewall. Application isolation, protected backups and consistent monitoring help strengthen the server further.

Security is an ongoing process. Review access regularly, keep software supported, test recovery procedures and investigate unusual activity. Make changes carefully, especially when configuring SSH or firewall rules, because a mistake can interrupt legitimate access.

The objective is not to make administration more complicated. It is to establish dependable controls that let you use root access confidently while reducing avoidable risks to your applications and data.

For businesses and developers who need full control over their environment, explore SteboHost's VPS and Cloud Hosting and assess the server resources and support arrangements against your security requirements.

Frequently Asked Questions

1. Is a VPS with full root access secure?

A VPS can be secured effectively, but full root access does not provide automatic protection. Security depends on the operating system, authentication, firewall configuration, updates, application permissions, monitoring and recovery procedures.

2. Should I disable root login on my VPS?

Disabling direct root login over SSH is generally a sensible practice after verifying that a separate administrative account can connect and use sudo. Keep a tested recovery path in case an SSH configuration error prevents remote access.

3. Are SSH keys safer than passwords?

SSH public-key authentication can reduce risks associated with weak or reused passwords. Protect the private key, use a passphrase where appropriate and remove old authorized keys when they are no longer needed.

4. Which ports should be open on a VPS?

Only open ports required by your applications and management processes. A public web server commonly needs ports 80 and 443, while SSH access should be appropriately restricted. Databases and internal services should generally remain private unless there is a specific, securely configured requirement for remote access.

5. Is a firewall enough to protect my VPS?

No. A firewall reduces network exposure but does not replace authentication controls, security updates, secure application configuration, restricted privileges, backups or monitoring.

6. How often should I update my VPS?

Check for security updates regularly and apply important patches promptly using a process suitable for your workload. Automated updates can help, but production systems still require monitoring, testing where appropriate and planned reboots when necessary.

7. Do I need backups if my VPS provider offers snapshots?

Yes, you should assess whether snapshots meet your recovery requirements and maintain additional backups where needed. Confirm scope, retention, storage separation and restoration options rather than assuming a snapshot provides complete disaster recovery.

8. Can I run Docker containers as root on my VPS?

Docker containers can run processes as root, but doing so is not necessary for every application. Use non-root container users where practical and restrict Docker daemon access because control of the daemon can grant extensive privileges on the host.

9. Should I change the default SSH port?

Changing the port may reduce automated scanning noise, but it is not a substitute for secure authentication and firewall restrictions. If you change it, update firewall rules and test the new connection before closing your existing session.

10. Who is responsible for security on a self-managed VPS?

The customer is generally responsible for managing the operating system, SSH access, software updates, application configuration, service permissions and recovery arrangements. The provider's responsibilities may cover underlying infrastructure and network operations. Always confirm the precise division of responsibility in the service agreement.

Further Reading

• Ubuntu Server security suggestions

• Ubuntu OpenSSH Server documentation

• Ubuntu firewall documentation

• Ubuntu automatic updates guide

• SteboHost VPS and Cloud Hosting