What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The safest way to get root access to a Linux VPS is to connect with the provider-supplied account and SSH key, then run sudo -i. Only enable direct root@server logins when a specific workflow requires them, and use PermitRootLogin prohibit-password so root can authenticate with a key but not a password.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What root SSH access actually means
SSH access and root access are separate decisions. SSH authenticates you to the server; the account you authenticate as determines your initial privileges. A provider may give you a named administrative account, a distribution-specific default account, or a root-capable account. Once connected, an account with sudo rights can start a root shell without opening a direct root login over the network.
As an Amazon Associate I earn from qualifying purchases.
A direct root connection looks like ssh [email protected]. A safer administrative workflow looks like ssh [email protected], followed by sudo -i. The second method keeps the SSH daemon from accepting root connections while still giving an authorized administrator full control after login.
The SSH daemon’s PermitRootLogin setting controls whether root may log in and which authentication methods are allowed. Its effective value can be affected by the main configuration file, included snippets, user restrictions, and authentication settings elsewhere in the configuration.
Before you connect
- Server address: the VPS provider’s public IPv4 address, IPv6 address, or hostname.
- Exact username: use the account named in the provider’s provisioning instructions. Do not assume it is
root; many images create a named administrative account instead. - Private key: the private half of the SSH key pair associated with the VPS. Keep it on your computer and never paste it into a server or send it to another person.
- Network access: TCP port 22 must be reachable unless the provider or your administrator configured another SSH port.
- Recovery path: know whether the provider offers a web console, KVM, serial console, or rescue environment before changing SSH settings.
On a Unix-like workstation, restrict the private-key file before using it:
chmod 600 ~/.ssh/vps_ed25519On Windows, use the key format and permissions required by the SSH client you installed. The provider’s key filename and operating-system instructions take precedence over this example.
Recommended Free Tools
The recommended path: log in, then become root
- Start with the provider’s account and key. Run the command using the exact username, address, and private-key path supplied when the VPS was created:
ssh -i ~/.ssh/vps_ed25519 [email protected]If the key is in your SSH agent or in the default key location, the
-ioption may not be necessary. - Confirm which account you used. Run
whoamiandid. This prevents you from changing root’s files while believing you are working in a different account. - Open a root shell through sudo.
sudo -iThe prompt normally changes, and
whoamishould returnroot.sudo su -is an alternative, butsudo -iis clearer because it requests a login-style root shell directly. - Do administrative work, then leave the root shell. Run
exitonce to return to the named account and again to close SSH if necessary.
This approach preserves an auditable named login, avoids exposing root password authentication, and leaves PermitRootLogin no as a viable SSH policy.
Understanding PermitRootLogin
Ubuntu’s OpenSSH documentation defines PermitRootLogin as the setting that specifies whether root can log in using SSH. The three values below have materially different effects:
| Setting | Direct root SSH result | Security and operational meaning |
|---|---|---|
no |
Root cannot log in through SSH. | Use this when administrators can connect with named accounts and sudo. It removes a high-value username from the SSH login surface. |
prohibit-password |
Root may authenticate with public keys, but password and keyboard-interactive authentication are disabled for root. | This is the usual choice when a process genuinely requires root@server. It limits root access to possession of an authorized private key. |
yes |
Root authentication is broadly permitted, subject to the other SSH rules. | It is more exposed and should be used only for a documented operational reason. Do not combine it with a guessable or reused root password. |
without-password |
On configurations that support this legacy value, root password authentication is disabled while non-password methods may remain possible. | Prefer the current, explicit prohibit-password wording on systems whose OpenSSH version documents it. |
PermitRootLogin does not by itself enable public-key authentication. The daemon also needs to permit the relevant key method, and the key must be present in root’s authorized-key file. Conversely, setting PasswordAuthentication yes does not make root passwords work when PermitRootLogin no or a password-disallowing root mode is effective.
Inspect the effective SSH configuration first
Ubuntu and Debian commonly read the main file at /etc/ssh/sshd_config plus snippets under /etc/ssh/sshd_config.d/. A setting in an included file can explain why editing the main file appears to have no effect. Do not assume the first matching line you see is the value the daemon is using.
From your existing administrative session, inspect both locations:
sudo grep -RniE '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AllowUsers|DenyUsers|Include)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/nullAlso ask the daemon to render its parsed defaults:
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|denyusers'The rendered output is useful for spotting a global value, but rules inside a Match block can depend on the connection’s user, address, or other attributes. Read the surrounding configuration when a global check and an actual login attempt disagree.
PermitRootLogin: determines whether root is eligible for SSH and whether root password-style authentication is allowed.PasswordAuthentication: controls password authentication generally; changing it can affect every account.PubkeyAuthentication: must allow public-key authentication for key-based logins.AllowUsersandDenyUsers: can permit or block a user even when the authentication method and key are correct.Includeand snippet files: identify additional files whose values and ordering matter.
Install a root public key correctly
If a direct root key login is required, place the public key in /root/.ssh/authorized_keys. Never copy the private key to the VPS. Each authorized key must remain a single line beginning with a key type such as ssh-ed25519 or ssh-rsa, followed by the encoded key and an optional comment.
From an existing sudo-capable session, create the directory with restrictive ownership and permissions:
Free tools Windows power users keep installed
One-click scans. No signup required.
sudo install -d -m 700 -o root -g root /root/.ssh
sudo touch /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keysAppend the public-key line using a method that does not alter its contents. For example, if you uploaded the public key to a temporary file, review it first and then append it:
cat /tmp/root-key.pub
sudo sh -c 'cat /tmp/root-key.pub >> /root/.ssh/authorized_keys'
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keysRemove the temporary copy when it is no longer needed. Check the enclosing directory as well as the file:
sudo stat -c '%A %U:%G %n' /root/.ssh /root/.ssh/authorized_keysThe expected modes are 700 for /root/.ssh and 600 for authorized_keys, both owned by root. A permissive directory, wrong owner, line wrapping, a key copied from the wrong computer, or a mismatched username can cause the server to reject an otherwise valid key.
Enable key-only direct root SSH
Complete this section only when your workflow specifically needs to connect as root. Keep your current SSH session open throughout the change.
- Open the configuration with an administrative editor:
sudoedit /etc/ssh/sshd_config - Set or update the relevant global directives. A restrictive example is:
PermitRootLogin prohibit-password PubkeyAuthentication yesDo not add
PasswordAuthentication yesmerely to make root login work. If password authentication is not needed for any account, keeping itnoreduces exposure. If another policy requires passwords for non-root users, understand that the global setting affects them too and use the provider’s documented per-user orMatchconfiguration carefully. - Search every included snippet for a second
PermitRootLogin, authentication setting, or user allow/deny rule. Resolve conflicting directives rather than assuming the last line in the main file wins. - Validate before restarting:
sudo sshd -tNo output normally means the syntax check passed. Treat any error as a stop condition; correct it before touching the running service.
- Restart the service using the name provided by your distribution. On many Ubuntu and Debian systems:
sudo systemctl restart sshSome distributions use a service unit named
sshd, so check the image’s documentation rather than blindly substituting a command. - Open a second terminal and test the new path while the first session remains connected:
ssh -i ~/.ssh/vps_ed25519 [email protected]After login, run
whoamiandid -u; the expected results arerootand0. - Only after the second connection succeeds should you close the original session. If the test fails, use the still-open session to restore the previous known-good configuration.
Why a root password usually fails
A password prompt does not prove that root password authentication is allowed. The server may prompt and then reject the password because PermitRootLogin is no or prohibit-password, because PasswordAuthentication is disabled, or because a provider image disables root passwords independently. Enabling a password for root also creates a much larger attack surface than a key restricted to your device.
If you need an administrator with a password for an emergency, create or use a named account according to your provider’s recovery procedure, connect through the console, and return the SSH policy to its restrictive state afterward. Do not leave a temporary root password enabled as a substitute for installing a key.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Recover access when the SSH key is lost
If the private key is gone, changing SSH settings from your laptop is impossible because you cannot authenticate. Use the VPS provider’s web console, KVM, serial console, or rescue environment. Console availability and labels differ by provider, so follow the console procedure for the specific VPS.
DigitalOcean’s documented recovery procedure illustrates the important sequence for Ubuntu 22.04 and later or Debian 12 and later: from the Recovery Console, edit both /etc/ssh/sshd_config.d/50-cloud-init.conf and /etc/ssh/sshd_config and set PasswordAuthentication yes when password recovery is necessary. Restart SSH from the console, log in as root with the reset password, and install a replacement public key in /root/.ssh/authorized_keys or in the named administrator’s key file.
Once the replacement key works from a normal SSH client:
- Remove or disable the temporary recovery password.
- Set
PasswordAuthentication noagain if that was your previous policy. - Use
PermitRootLogin noandsudo -i, or retainPermitRootLogin prohibit-passwordonly if direct root keys are required. - Run
sudo sshd -t, restart SSH, and verify a second connection before leaving the console. - Revoke the lost key anywhere else it was authorized, including other servers, repositories, automation systems, or local agents.
If the configuration is syntactically broken or the network service will not restart, the provider’s rescue environment can let you mount the VPS disk and repair the files offline. Keep a copy of the last known-good configuration before making a recovery edit.
Troubleshoot “permission denied” and refused keys
| Symptom | Likely cause | What to check |
|---|---|---|
| Password is requested and then rejected for root. | Root password login is disabled by PermitRootLogin, PasswordAuthentication, or a provider image policy. |
Inspect the effective values with sshd -T. Use a key or connect with a sudo-capable named account instead. |
| The client offers a key but the server refuses it. | Wrong username, wrong private-key file, missing public key, malformed line, wrong ownership, or overly permissive modes. | Confirm the address and account; use verbose client output such as ssh -v; verify the matching public key and the 700/600 permissions. |
Changes in sshd_config appear ignored. |
An included file or Match block supplies the effective value, or the service was not restarted. |
Search /etc/ssh/sshd_config.d/, run sshd -T, validate with sshd -t, and restart the correct service unit. |
| Named account works but root does not. | PermitRootLogin no, an AllowUsers/DenyUsers rule, or a missing root key. |
Use sudo -i unless direct root is essential. Otherwise check all three controls and the root key file. |
| You closed the only working session and cannot reconnect. | A bad syntax change, restrictive rule, firewall change, or lost key removed remote access. | Use the provider’s recovery console, KVM, serial console, or rescue workflow; repair and validate SSH from there. |
Client-side verbose output identifies which keys are offered, but it does not reveal every server-side policy decision. When the client says the key was accepted and the session still closes, inspect server authentication logs through the console or distribution-specific journal.
Direct root SSH versus sudo
| Decision factor | Named account plus sudo -i |
Direct root with a key |
|---|---|---|
| Security exposure | Root is not an SSH login target; the named account and its key must be compromised before sudo can be attempted. | The globally recognizable root username is exposed, although prohibit-password removes root password authentication. |
| Auditability | Commands can be associated with the named account and sudo event. | Multiple operators may appear as the same root identity unless external session logging is configured. |
| Automation compatibility | Scripts must connect as the named account and invoke sudo, sometimes requiring non-interactive sudo policy. | Some bootstrapping or rescue tools expect a root SSH connection and work more directly. |
| Recoverability | Another administrator can disable one named key without changing root access. | A lost or revoked root key can remove the only direct administrative path. |
| Portability | Works on distributions that provide a sudo-capable account, but the account name and sudo policy vary by image. | Uses the conventional root account, but the permitted root-login modes and configuration layout vary by OpenSSH version and distribution. |
| Operational risk | Requires one extra command, sudo -i, before privileged work. |
A configuration mistake can lock out every remote administrator, so a second-session test is essential. |
For ordinary administration, choose the named account and sudo. Choose direct root only for a defined requirement such as an automation system that cannot use sudo or a recovery workflow that explicitly demands root SSH, and use a dedicated key rather than reusing a personal key.
After access works: reduce the chance of another lockout
- Keep at least one tested sudo-capable named account in addition to any direct root key.
- Store an encrypted backup of each private key and record which VPS uses each public key.
- Keep a second administrative SSH session open while editing or restarting the daemon.
- Run
sshd -tbefore every restart and test a fresh connection afterward. - Document the provider’s console and rescue path, including whether it requires a separate password or two-factor authentication.
- Remove stale keys from
authorized_keysand revoke keys belonging to former administrators. - Use a firewall, rate limiting, and monitoring appropriate to the VPS, but do not change firewall or SSH ports during the same untested change as an authentication-policy edit.
- Keep the operating system and OpenSSH packages updated through the distribution’s normal security channel.
Root access is a privilege boundary, not merely a different SSH username. The durable setup is one you can explain, test from a second session, and recover through an out-of-band console if the network path fails.
Quick Recap
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.
