Skip to main content

How to Enable Root Login on Your VM (BYOVM)

Elestio’s BYOVM (Bring Your Own VM) workflow requires direct root-level SSH access to the target host. Many cloud providers disable or restrict root login by default; this document outlines how to safely re-enable it while maintaining a strong security posture.

Architectural Requirement for Root Access

Elestio performs low-level system provisioning and lifecycle management directly on the host. This includes:

  • Writing configuration and state under /root/ other privileged paths

  • Installing and managing system packages and daemons

  • Modifying network configuration, firewall rules, and kernel-adjacent settings

  • Executing privileged deployment and orchestration tasks

Relying on a non-root user with sudo is intentionally avoided due to

  • Inconsistent sudo availability and behavior across distributions and cloud images

  • Hard dependencies on root-owned paths (e.g., /root, system-level configs)

  • Increased operational complexity from privilege escalation (TTY requirements, environment differences, edge cases)

  • Higher failure surface during automated provisioning

From an automation and reliability standpoint, direct root access is deterministic and reduces ambiguity.

Security Model: Root Access with SSH Keys

Enabling root login is not inherently insecure when implemented correctly.

Elestio enforces the following security guarantees:

  • Password authentication is permanently disabled

  • Only SSH key-based authentication is permitted

  • Root login is restricted to key-based access (prohibit-password)

Implications

  • No password-based login is possible under any circumstances

  • Attack vectors such as brute-force or credential stuffing are eliminated

  • Access is strictly limited to holders of the corresponding private key

Blocking the root while allowing SSH access to an enabled user does not materially improve security. Any compromise of such a user trivially escalates to root (sudo su). The true security boundary is the SSH private key, not the username.

Step 1: Remove Provider-Imposed Restrictions

Some providers (notably AWS and GCP) inject a forced command /root/.ssh/authorized_keys to prevent root login:

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"ubuntu\" rather than the user \"root\".';echo;sleep 10;exit 142"

This must be removed.

Execute as a privileged non-root user (e.g., ubuntu, ec2-user):

sudo sed -e "s/echo;sleep 10;exit 142//g" -i /root/.ssh/authorized_keys

Validate:

sudo cat /root/.ssh/authorized_keys

Expected state: only raw public key entries, no command="..." prefix.

Step 2: Configure SSH Daemon

Inspect the current configuration:

sudo grep -i PermitRootLogin /etc/ssh/sshd_config

Enforce the correct policy:

sudo sed -i 's/^.*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
Semantics

  • prohibit-password

    • ✅ (allows) SSH key authentication

    • ❌ (blocks) password authentication

This is the recommended and secure baseline configuration.

Step 3: Reload SSH Service

Apply changes without terminating the active session:

sudo systemctl reload sshd || sudo service ssh reload
Step 4: Validate Root Access

From your local environment:

ssh -i /path/to/private_key root@<server_ip>

A successful connection should yield a root shell immediately.

Provider Behavior Matrix
Provider Root Access Default Notes
AWS EC2 (Ubuntu) Blocked Requires authorized_keys fix
AWS EC2 (Amazon Linux) Blocked Requires authorized_keys fix
Google Cloud Blocked Requires authorized_keys fix
Azure Blocked Controlled via sshd_config
DigitalOcean Enabled No action required
Hetzner Enabled No action required
Vultr Enabled No action required
Linode (Akamai) Enabled No action required

For AWS and GCP, Step 1 is mandatory in most cases.

Troubleshooting
Root login still denied

Check for override files:

sudo grep -r PermitRootLogin /etc/ssh/sshd_config.d/

Ensure all instances are set to:

PermitRootLogin prohibit-password
Forced “login as ubuntu” message

Indicates the provider-injected restriction is still present.

Re-run Step 1 and re-validate /root/.ssh/authorized_keys.

SSH key not accepted

Ensure the key exists and permissions are correct:

sudo cat /root/.ssh/authorized_keys

If missing:

sudo cp ~/.ssh/authorized_keys /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
Consolidated Execution Block
# Remove provider-enforced root restriction
sudo sed -e "s/echo;sleep 10;exit 142//g" -i /root/.ssh/authorized_keys

# Enable root login via SSH key only
sudo sed -i 's/^.*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config

# Normalize any drop-in overrides
sudo sed -i 's/^.*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config.d/*.conf 2>/dev/null || true

# Reload SSH daemon
sudo systemctl reload sshd || sudo service ssh reload
Back to top