iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The safest way to obtain root access on a Linux VPS is to connect with the provider-supplied account and SSH key, then run sudo -i. This gives you a root shell without exposing root password authentication over the network. If a task genuinely requires logging in as root, configure PermitRootLogin prohibit-password so root can use a public key but not a password, install the key with strict ownership and permissions, validate the SSH configuration, and test a second connection before closing the first.
Direct root SSH is controlled by the SSH daemon’s PermitRootLogin setting. no blocks root SSH, prohibit-password permits key-based root login while disabling password and keyboard-interactive authentication, and yes permits broader root authentication. The exact result also depends on other SSH rules, included configuration files, the account name, and the key installed on the server.
Choose the access method before changing SSH
Root access means unrestricted control of the operating system. A root shell can replace system files, remove user accounts, change firewall rules, or destroy data without the safeguards that apply to an ordinary account. For routine administration, use a named account with sudo:
ssh -i /path/to/private_key user@server
sudo -iThe first command follows the normal OpenSSH pattern: the private-key file, the provider-assigned username, and the VPS hostname or IP address. The second command starts a root login shell locally after SSH authentication has already succeeded. This approach keeps direct root SSH disabled while still allowing authorized administrators to perform root tasks.
Use direct root@server login only when a tool, recovery process, or automation workflow specifically requires it. If you enable it, use a public key and keep password authentication disabled.
What you need before connecting
- The VPS hostname or public IP address.
- The exact initial username supplied by the VPS provider. It may be a distribution-specific account or another administrative user.
- The private key that matches the public key provisioned on the VPS.
- A local OpenSSH client, available by default on most Linux and macOS systems and through current OpenSSH packages on Windows.
- A provider web console, recovery console, KVM, serial console, or rescue environment if you might need to recover from a bad SSH change.
Do not guess the username. A valid key presented to the wrong account is rejected because SSH checks that account’s authorized_keys, not the key file belonging to another user.
Recommended Free Tools
Recommended path: connect, then become root
- Open a terminal and use the provider’s exact connection details:
ssh -i /path/to/private_key username@your-server-address- Accept the host-key prompt only after checking that the address is the VPS you intended to reach. If the host key unexpectedly changed, stop and verify the server rather than deleting the warning automatically.
- After login, obtain a root shell:
sudo -isudo su - is an alternative, but sudo -i is the clearer administrative form because it requests a login-style root environment through sudo. Your prompt should change to a root prompt, and commands such as id -u should return 0.
id -u
whoamiThis method avoids exposing a root password to SSH and leaves the daemon’s direct-root policy restrictive. If sudo -i reports that the user is not permitted, the provider account lacks sudo authorization; use the provider’s documented administrative account or console to grant it rather than attempting random SSH settings.
Understand the SSH settings that control root login
The SSH server reads /etc/ssh/sshd_config and may also load snippet files from /etc/ssh/sshd_config.d/. Ubuntu’s OpenSSH documentation defines PermitRootLogin as the setting that specifies whether root can log in using SSH. The important values are:
| Setting | Root SSH behavior | When it fits |
|---|---|---|
no |
Direct root SSH is blocked. | Preferred when administrators can use a named account and sudo. |
prohibit-password |
Root may authenticate with public keys, but password and keyboard-interactive authentication are disabled. | Best choice when direct root key login is unavoidable. |
yes |
Allows root authentication methods permitted by the rest of the SSH configuration, including password authentication if enabled. | Use only for a documented operational requirement and a tightly controlled key policy. |
without-password |
An older spelling used by some configurations for key-only root access. | Treat it as a legacy equivalent and prefer the current prohibit-password spelling when editing configuration. |
PermitRootLogin does not operate in isolation. PasswordAuthentication, PubkeyAuthentication, AllowUsers, DenyUsers, account lock state, firewall rules, and the key files all affect the result. A password prompt followed by “permission denied” can occur when passwords are enabled globally but root login is set to no or without-password.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Inspect the effective configuration first
Before editing, search the main file and every included snippet for the relevant directives. Do not assume the value visible near the bottom of /etc/ssh/sshd_config is the value being applied.
sudo grep -RniE '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AllowUsers|DenyUsers|Include)'
/etc/ssh/sshd_config /etc/ssh/sshd_config.d/ 2>/dev/nullReview each matching line, including files such as cloud-init snippets. Distribution packages and image provisioning systems can place authentication policy in an included file. Also check whether an AllowUsers rule names the account you intend to use or a DenyUsers rule excludes it.
Where supported by your OpenSSH version, ask the daemon to render its effective settings for the server process:
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|denyusers'If your distribution’s sshd binary does not support that query, rely on the file review and the daemon’s documented configuration behavior. Never edit a setting and immediately close your only working session.
Enable direct root SSH with a key
Perform these steps from an existing administrative session obtained with the provider account and key, not from an unverified remote shell.
1. Install the public key for root
Create root’s SSH directory if necessary and place the public key that corresponds to your local private key in /root/.ssh/authorized_keys. You can append it from a trusted administrative account:
sudo install -d -m 700 -o root -g root /root/.ssh
sudo sh -c 'cat /home/username/.ssh/authorized_keys >> /root/.ssh/authorized_keys'
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keysReplace the source path with the actual location of the public key, and avoid blindly copying another user’s entire file if it contains keys that should not receive root privileges. A safer approach is to open the file and add only the intended public-key line. The key must be a complete, unwrapped line beginning with its key type, such as ssh-ed25519 or ssh-rsa, followed by the base64 data and an optional comment.
2. Set a restrictive root-login policy
Edit the active SSH configuration:
sudo editor /etc/ssh/sshd_configSet or uncomment:
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yesIf an included snippet also defines these directives, update the policy in the file that actually controls the effective result. Keep an administrative account listed in any AllowUsers rule. Setting PasswordAuthentication no globally affects every SSH account, so confirm that all required users have working keys before applying it.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →3. Validate before restarting
Ask the daemon to check syntax without replacing the running service:
sudo sshd -tNo output normally indicates that the syntax check passed. An error identifies the file and line that must be corrected. Do not restart SSH until this check succeeds.
4. Restart without losing your safety net
Keep the current SSH window open. Restart the service using the name provided by your distribution:
sudo systemctl restart sshSome distributions use a different unit name, such as sshd; use the service name documented for that operating system. If the restart fails, the existing daemon may continue serving the old configuration, but you should inspect the service status and logs from the console or current session rather than guessing.
5. Test a second connection
Open a new terminal and test the exact root command while the original administrative session remains connected:
ssh -i /path/to/private_key root@your-server-addressAfter login, verify the identity:
whoami
id -uBoth checks should identify root and user ID 0. Test the named administrative account as well. Only after both paths work should you close the original session.
Key files, ownership, and permissions
Public-key authentication can fail even when the key text is correct if SSH considers the directory or file insecure. For root, the expected locations are /root/.ssh and /root/.ssh/authorized_keys. DigitalOcean’s troubleshooting guidance specifies mode 700 for the .ssh directory and mode 600 for authorized_keys. Keep both owned by root:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemssudo chown -R root:root /root/.ssh
sudo chmod 700 /root/.ssh
sudo chmod 600 /root/.ssh/authorized_keysCheck that the file is readable by root, contains the exact public key matching the private key you select locally, and has no accidental line breaks. On the client, use the matching private key explicitly with -i; selecting a different key can produce the same refusal as a server-side permission problem.
Recover access after losing a key
If the private key is gone, changing SSH settings from a normal SSH session is impossible. Use the VPS provider’s web console or recovery environment. A console gives access independently of the network SSH daemon, allowing you to repair the configuration and install a replacement key.
Recovery with a provider console
- Open the provider’s Recovery Console, KVM, serial console, or rescue workflow and authenticate through that channel.
- Inspect
/etc/ssh/sshd_configand the files in/etc/ssh/sshd_config.d/for rules that block the account or authentication method. - For Ubuntu 22.04 or later and Debian 12 or later, DigitalOcean’s documented password-recovery procedure requires setting
PasswordAuthentication yesin both/etc/ssh/sshd_config.d/50-cloud-init.confand/etc/ssh/sshd_configwhen those files are present and controlling the server. - Run
sshd -t, restart SSH, and log in through SSH with the reset password only long enough to install a replacement public key. - Place the replacement key in the correct account’s
authorized_keys, restore strict ownership and modes, setPasswordAuthentication noagain, validate, and restart SSH. - Test the new key in a second session before ending the console session.
Password recovery is an emergency bridge, not a permanent configuration. Revoke password access as soon as the replacement key works. If the provider has no console or rescue facility, contact its documented support or recovery channel; without an out-of-band path, a lost key and a blocked SSH daemon cannot be repaired remotely.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot common root SSH failures
“Permission denied” after a password prompt
Check the root policy first. PasswordAuthentication yes does not override PermitRootLogin no or a key-only root mode such as prohibit-password or without-password. If the intended policy is key-only, stop trying passwords and test with the correct private key.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →The key is offered but refused
- Confirm that you are connecting as
root, not the provider’s initial username. - Confirm the server address and the private-key path supplied to
-i. - Compare the public key derived from the private key with the line in
/root/.ssh/authorized_keys. - Check root ownership and modes
700for/root/.sshand600forauthorized_keys. - Look for malformed line wrapping, an accidental quotation mark, or a key copied into the wrong account.
- Check
AllowUsers,DenyUsers, and any distribution-specific access restrictions.
Configuration changes appear ignored
Search the snippet directory as well as the main file. Cloud-init or package-provided files can contain an authentication directive you did not edit. Run sshd -t, restart the correct service, and test a new connection. Existing sessions do not prove that the restarted daemon will accept new settings.
The SSH service will not restart
Run sudo sshd -t again and correct the reported syntax error. Keep the current session open while fixing it. If the service is down or the only account is locked out, use the provider’s recovery console rather than repeatedly restarting a malformed configuration.
You lost every remote route
Use the provider’s recovery console, KVM, serial console, or rescue environment. From there, restore a known-good SSH configuration, install a valid key, validate it, and restart SSH. The recovery channel is also where you can inspect firewall or network changes that prevent the daemon from being reached at all.
Direct root SSH versus sudo from a named account
| Factor | Named account plus sudo -i |
Direct root SSH with a key |
|---|---|---|
| Security exposure | Root login can remain disabled; SSH identifies the administrator before privilege escalation. | Exposes the root account as a network login target, even when password authentication is disabled. |
| Authentication | Provider or administrator account key, then sudo authorization. | Root’s own authorized_keys and the daemon’s root-login policy. |
| Recoverability | Usually easier to repair because another administrative identity remains available. | A misplaced root key or restrictive rule can remove the primary remote path. |
| Portability | Works across distributions that provide sudo or an equivalent administrative mechanism. | Depends on the distribution’s OpenSSH defaults, included snippets, and root-account policy. |
| Operational risk | Lower when the working SSH session stays open during changes. | Higher; always validate and test a second connection before closing the first. |
For most VPS administration, the first column is the better default. The second is justified when an automation system or recovery procedure explicitly requires a root SSH identity and you can maintain a provider-console fallback.
Quick Recap
Operational checklist
- Connect with the exact provider-supplied username, address, and private key.
- Try
sudo -ibefore changing root SSH policy. - Inspect both
/etc/ssh/sshd_configand/etc/ssh/sshd_config.d/. - For direct root access, prefer
PermitRootLogin prohibit-passwordand key authentication. - Install the key in
/root/.ssh/authorized_keyswith root ownership, directory mode700, and file mode600. - Run
sshd -tbefore every restart. - Keep the current session open and verify a second SSH connection.
- After emergency password recovery, install a new key and set
PasswordAuthentication noagain. - Keep a provider recovery console or equivalent out-of-band route available.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
