How to Disable Root Login on a VPS

Every automated attack against a Linux server tries root first — it's a guaranteed valid username with total power. Disabling direct root login removes that target and forces attackers to guess both a username and a key. Done carefully, it costs you nothing and closes a big door.

Why root login is risky

When root can log in over SSH, an attacker only needs one credential. Worse, if they succeed, they own the machine outright. The safer model: log in as an unprivileged user, then elevate to root with sudo only for the commands that need it — which also gives you an audit trail of who ran what.

Step 1: create a sudo user first

Do not skip this — if you disable root before you have another way in, you're locked out. Create a user and add them to the sudo group:

adduser deploy
usermod -aG sudo deploy

Our full create a non-root sudo user guide covers this in more depth, including passwordless sudo trade-offs.

Step 2: give the new user your SSH key

Copy your public key to the new account so you can log in with keys (see SSH key authentication):

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

That copies root's authorized keys to the new user. Alternatively use ssh-copy-id deploy@your-server-ip from your local machine.

Step 3: test the new user in a separate session

This is the critical safety step. Open a new terminal and log in as the new user:

ssh deploy@your-server-ip
sudo whoami   # should print: root

If sudo whoami returns root, your account has full admin rights and you're safe to lock down root.

{{SCREENSHOT}}

Step 4: disable root login over SSH

Edit /etc/ssh/sshd_config:

PermitRootLogin no

Validate and reload:

sudo sshd -t && sudo systemctl reload ssh

Keep the working session open, then try ssh root@your-server-ip from another terminal — it should be refused.

The middle ground: key-only root

If some automation genuinely needs root over SSH, allow it by key only, never by password:

PermitRootLogin prohibit-password

This blocks password-based root logins while permitting key-based ones. For most people, no is the right choice.

Lock the root password too (optional)

On a VPS you rarely need an interactive root password. You can disable password login for the root account entirely while keeping sudo su working:

sudo passwd -l root

Fits into a bigger picture

Disabling root is one item on the SSH hardening list. Pair it with the full harden SSH walkthrough, a UFW firewall, and fail2ban.

Auditing who used sudo and when

Once everyone logs in as themselves and elevates with sudo, you get something root-only setups can never have: an audit trail. Every sudo command is logged with the username, timestamp, and the exact command. Review it with:

sudo journalctl _COMM=sudo

Or on systems still writing to the auth log:

sudo grep sudo /var/log/auth.log

This is invaluable when something breaks and you need to know what changed, or when investigating a possible compromise. It's a concrete, practical reason to disable root login rather than a purely theoretical one — accountability. When several people administer a server, "who restarted the database at 3am?" becomes an answerable question instead of a mystery.

What about existing root cron jobs and services?

Disabling root *login* over SSH does not affect root-owned processes, cron jobs, or systemd services — those continue to run as root as before, because they don't authenticate over SSH. The change only blocks interactive and remote root logins. So you can safely disable root SSH without worrying that your scheduled backups or system services will stop. If you have automation that connects *in* to the server as root over SSH (for example a deploy tool), that's the one thing to migrate first: point it at your sudo user's key instead, then disable root login once it's confirmed working. Test the automation end-to-end in a staging run before flipping the switch on production, and keep the console handy as your fallback.

FAQ

How do I run admin commands after disabling root?

Log in as your sudo user and prefix commands with sudo, or run sudo -i for an interactive root shell. Everything root could do, sudo can too.

What if I get locked out?

Use your host's web console. Nxeon and most providers give you out-of-band console access so you can log in as root locally and fix sshd_config even if SSH is broken.

Is prohibit-password safe?

Yes — it allows root only via SSH keys, blocking password guesses. It's a reasonable choice when automation needs root, though a dedicated key-restricted user is cleaner.

Should I also disable the root password?

On a key-based VPS, locking the root password (passwd -l root) adds defence in depth without affecting sudo. It's optional but harmless.

A safe order of operations

The whole point is to never be without a way in, so do this in sequence and don't skip the test:

1. Create the sudo user: adduser deploy && usermod -aG sudo deploy.
2. Install your SSH key for that user so key login works.
3. Test in a new terminal: ssh deploy@host then sudo whoami must print root.
4. Only now set PermitRootLogin no and sudo sshd -t && sudo systemctl reload ssh.
5. Confirm ssh root@host is refused while your sudo user still works.

The single rule that prevents every lockout is: never disable an access method until you've proven the replacement works. Keep your original session open throughout, and remember your provider's web console is the ultimate fallback — you can log in locally as root and revert sshd_config even if SSH is completely broken. With that safety net in mind, this is a change you can make confidently on any server.

Removing the root target is a five-minute win that every server should have. For full root control on a fast NVMe VPS with a rescue console, see Nxeon VPS plans and our security page.