How to enable root login on your Linux Cloud Server

You can unlock the root account, and if needed, enable direct root SSH login on your Linux Cloud Server. This is useful when an application or installer specifically requires the root user rather than sudo. It applies to all one.com unmanaged Cloud Server (VPS) products running Linux.

Before you start, make sure you have:

  • A running Cloud Server with a Linux distribution installed.
  • Access to your server via SSH or the oneHome Web console, using your default sudo user. See Connect to your Linux Cloud server via SSH if you haven't done this yet.
  • Your sudo user's password, to authorize the steps below.
  • Why you might need root access

    By default, a new Cloud Server is provisioned with a non-root user (administrator by default) that has full sudo permissions, rather than a root account with a set password or direct root SSH login. This is deliberate: it follows common Linux hardening practice and reduces exposure to automated brute-force attacks against the well-known "root" username. For most day-to-day administration, running commands with sudo is sufficient and is the recommended approach.

    That said, some applications, installers, or scripts explicitly require the true root user, for example checking for $EUID -eq 0, rather than a sudo-elevated shell, and refuse to run correctly under sudo alone.

  • When you might need this

    Typical situations where you'd need this:

    • Installing software with an installer that mandates a root shell.
    • Running third-party install scripts that reject sudo and require literal root.
    • Working with legacy applications or tooling designed only for root.
    • Recovering access if your sudo user's account gets locked, deleted, or its sudoers configuration breaks. A root password is your fallback path back into the server.
    • Repairing the system in rescue mode, for example a broken bootloader or filesystem issue, where working inside a chroot means sudo's usual mechanisms may not be reliably available.
    • Migrating a full server or syncing a complete backup with rsync or scp as root, so file ownership and permissions transfer exactly across the whole system.
    • Running interactive setup tools, such as dpkg-reconfigure or some database configuration wizards, that expect a genuine root login environment (HOME=/root, full root PATH), which sudo <command> alone doesn't fully replicate.
    • Managing root-owned cron jobs, or letting a monitoring or backup agent install itself as a root-owned systemd service.


Step-by-step instructions

  • Part 1: set a root password (required first step)

    This is the required first step, and gives you a root shell without opening up SSH.

    1. Connect to your Cloud Server via SSH or the Web console, using your default sudo user.
    2. Set a password for the root account:
       sudo passwd root
    1. Enter and confirm a strong new password when prompted.
    2. You can now switch to the root user from your current session at any time:
       su -

    If you only need a root shell or want to run individual commands as root, you don't need to go any further; su - and sudo already cover that without exposing SSH.

  • Part 2: enable direct root login via SSH (optional)

    Only do this if something specifically requires you to log in as root over SSH, rather than switching to root after connecting.

    1. Open the SSH server configuration file:
       sudo nano /etc/ssh/sshd_config
    1. Find the line starting with PermitRootLogin. It may be commented out with a #, or set to no or prohibit-password.
    2. Change it to:
       PermitRootLogin yes
    1. Save and close the file.
    2. Restart the SSH service to apply the change:
       sudo systemctl restart sshd
    1. You can now connect directly as root:
       ssh root@<your-server-ip>

    To use an SSH key instead of a password for root login, add your public key to /root/.ssh/authorized_keys.


Good to know

Enabling direct root SSH login increases your server's attack surface 
"root" is a well-known username that automated bots specifically target with brute-force login attempts. If you enable it, restrict SSH access to trusted IPs via Firewall / IP Access Rules, and use a strong, unique password or SSH key authentication. Once you no longer need direct root SSH login, revert PermitRootLogin back to no or prohibit-password.

  • Important notes

    • Managing and securing root access is entirely within your guest OS and is your responsibility. This falls outside the platform-managed layer of your unmanaged Cloud Server. 
       
    • A redeploy reinstalls the OS from scratch, which resets the root account to its default locked state and PermitRootLogin back to its default value.
  • Troubleshooting

    If the steps above don't work, here are a few other things to check:
     

    • "passwd: Authentication token manipulation error"
      Check that the filesystem isn't full or mounted read-only (df -h).
       
    • Root login still refused after changing PermitRootLogin
      Confirm you restarted the SSH service (sudo systemctl restart sshd), and check for a conflicting override file in /etc/ssh/sshd_config.d/.
       
    • "Permission denied (publickey)" when connecting as root via SSH
      If your server only accepts key-based authentication, add your SSH key to /root/.ssh/authorized_keys, or make sure password authentication is also permitted if that's how you intend to log in.
       
    • Locked out after editing sshd_config
      Use the Web console in oneHome, which doesn't require SSH, to fix the configuration file and restart the SSH service.


Related articles:

Was this article helpful?

Can’t find what you are looking for?

Start a chat

It's the quickest way to get in touch, every day of the year.

Give us a call

Available on weekdays from 10am to 2pm (UTC).