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 (
administratorby default) that has fullsudopermissions, 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 withsudois 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 undersudoalone. -
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
sudoand 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
rsyncorscpas root, so file ownership and permissions transfer exactly across the whole system. - Running interactive setup tools, such as
dpkg-reconfigureor some database configuration wizards, that expect a genuine root login environment (HOME=/root, full rootPATH), whichsudo <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.
- Connect to your Cloud Server via SSH or the Web console, using your default sudo user.
- Set a password for the root account:
sudo passwd root
- Enter and confirm a strong new password when prompted.
- 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 -andsudoalready 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.
- Open the SSH server configuration file:
sudo nano /etc/ssh/sshd_config
- Find the line starting with
PermitRootLogin. It may be commented out with a#, or set tonoorprohibit-password. - Change it to:
PermitRootLogin yes
- Save and close the file.
- Restart the SSH service to apply the change:
sudo systemctl restart sshd
- 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, revertPermitRootLoginback tonoorprohibit-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
PermitRootLoginback to its default value.
- 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.
-
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.
-
"passwd: Authentication token manipulation error"
Related articles: