Skip to main content

How to Enable Root Login on Your VM (BYOVM)

# How to Enable Root Login on Your VM (BYOVM)

Elestio'

Elestio’s BYOVM (Bring Your Own VM) featureworkflow requires **rootdirect root-level SSH access**access to yourthe server.

target
Somehost. Many cloud providers disable or restrict root login by defaultdefault; asthis adocument misguided security measure. This guide explainsoutlines how to safely re-enable it andwhile whymaintaining ita isstrong safesecurity toposture. do
so when SSH key authentication is in place.

---

Architectural

##Requirement Why Elestio Requiresfor Root Access

Elestio installsperforms low-level system provisioning and manageslifecycle softwaremanagement directly on yourthe server.host. This includes:


-

    Writing files to `/root/`configuration and state under /root/ other privileged paths

    Installing and managing system directories

    - Installing packages and systemdaemons services
    - Configuring

    Modifying networkingnetwork configuration, firewall rules, and firewalls

    kernel-adjacent
    -settings Running

    Executing privileged operationsdeployment duringand deploymentorchestration tasks


    Non-

    Relying on a non-root users — even thoseuser with `sudo`sudo —is areintentionally notavoided sufficientdue because:


    to
    - `sudo`

      Inconsistent sudo availability variesand betweenbehavior across distributions and providers

      cloud
      -images Many configuration

      Hard dependencies on root-owned paths are(e.g., hardcoded/root, tosystem-level `/root/`

      configs)
      - Privilege

      Increased operational complexity from privilege escalation adds(TTY unnecessaryrequirements, complexityenvironment differences, edge cases)

      Higher failure surface during automated provisioning

      From an automation and failurereliability pointsstandpoint, direct root access is deterministic and reduces ambiguity.


      ---

      Security

      ## Is EnablingModel: Root LoginAccess awith Security Risk?

      **No — as long as password authentication is disabled.**

      Elestio keeps password login **disabled at all times** and uses **SSH keyKeys authentication exclusively**. This means:

      - No password can ever be used to log in as root, even if

      Enabling root login is enabled

      not -inherently Onlyinsecure someonewhen whoimplemented holdscorrectly. Elestio enforces the correctfollowing 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 SSHkey key can connect - Brute-force and credential-stuffing attacks are completely ineffective
      Blocking Blockingthe root while still allowing key-based SSH loginaccess onto anotheran enabled user providesdoes nonot meaningfulmaterially improve security. benefitAny —compromise anof attacker who compromisessuch a sudoeruser accounttrivially can simply `sudo su`escalates to root anyway.(sudo su). The realtrue protectionsecurity boundary is the SSH key,private key, not the username.
      ---
      ## Step 1 —1: Remove theProvider-Imposed Provider'sRestrictions Root Block in `authorized_keys`
      Some providers (notably AWS EC2, Google Cloud, and others)GCP) inject a forced command at/root/.ssh/authorized_keys theto start of theprevent root `authorized_keys`login: file that immediately terminates any root SSH session:
      ``` 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 Runmust thisbe commandremoved. **Execute as a privileged non-root sudoer**user (e.g. `ubuntu`, `ubuntu, ec2-user`user): to strip it out:
      ```bash sudo sed -e "s/echo;sleep 10;exit 142//g" -i /root/.ssh/authorized_keys ```Validate:
      Then verify the file looks clean:
      ```bash sudo cat /root/.ssh/authorized_keys ```Expected
      state: It should now contain only the plainraw public key lines, withentries, no `command="..."` prefix.prefix.
      ---
      ## Step 22: —Configure AllowSSH RootDaemon Login in `sshd_config`
      CheckInspect the current SSHconfiguration: daemon configuration:
      ```bash sudo grep -i "PermitRootLogin"PermitRootLogin /etc/ssh/sshd_config ```Enforce
      the Ifcorrect itpolicy: shows `PermitRootLogin no` or `PermitRootLogin forced-commands-only`, change it to:
      ```bash sudo sed -i 's/^.*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config Semantics ```
      ` prohibit-password`password ✅ (also written as `without-password` on older systems) means: - Root login viaallows) SSH key →authentication **allowed** ✓ -❌ Root login via(blocks) password →authentication **blocked** ✓
      This is the safest settingrecommended and whatsecure Elestiobaseline requires.configuration.
      ---
      ## Step 3 —3: Reload the SSH DaemonService
      Apply Applychanges without terminating the change without dropping your currentactive session:
      ```bash sudo systemctl reload sshd || sudo service ssh reload ```
      ---
      ## Step 44: — TestValidate Root Access
      From your local machine,environment: test that root login now works with your SSH key:
      ```bash ssh -i /path/to/your/keyprivate_key root@YOUR_SERVER_IProot@<server_ip> ```A
      successful Youconnection should getyield a root shell.shell Ifimmediately. it still fails, see the troubleshooting section below.
      Provider Behavior Matrix ---
      ## Provider-Specific Notes
      |Provider ProviderRoot |Access Default rootNotes status | Non-root user | |---|---|---| | AWS EC2 (Ubuntu) |Blocked BlockedRequires viaauthorized_keys `authorized_keys`fix | `ubuntu` | | AWS EC2 (Amazon Linux) |Blocked Requires authorized_keys fix Google Cloud Blocked Requires authorized_keys fix Azure Blocked Controlled via `authorized_keys`sshd_config | `ec2-user` |DigitalOcean Enabled No action required Hetzner Enabled No action required Vultr Enabled No action required Linode (Akamai) Enabled No action required | Google Cloud | Blocked via `authorized_keys` | varies | | DigitalOcean | Root enabled by default | — | | Hetzner | Root enabled by default | — | | Azure | Blocked via `sshd_config` | `azureuser` | | Vultr | Root enabled by default | — | | Linode / Akamai | Root enabled by default | — |
      For **AWS EC2** and **GoogleGCP, Cloud**, Step 1 (the `authorized_keys` fix) is almost always requiredmandatory in additionmost tocases. Step 2.
      ---
      Troubleshooting ##Root Troubleshootinglogin
      still **Stilldenied getting `Permission denied` after the steps above?**
      Check iffor thereoverride isfiles: a drop-in sshd config file overriding the main one:
      ```bash sudo grep -r "PermitRootLogin"PermitRootLogin /etc/ssh/sshd_config.d/ ```Ensure
      all Ifinstances found, edit the relevant file andare set itto: toPermitRootLogin `prohibit-password`.password
      **GettingForced `Please “login as user "ubuntu"`ubuntu” message andIndicates thenthe disconnected?**provider-injected
      The `authorized_keys` blockrestriction is still present. RepeatRe-run Step 1 and verifyre-validate the/root/.ssh/authorized_keys. file contents again.
      **SSH key not accepted forEnsure root?**
      Make sure your publicthe key isexists presentand inpermissions `/root/.ssh/authorized_keys`:are
      correct: ```bash sudo cat /root/.ssh/authorized_keys ```
      If itmissing: is missing, copy it from the non-root user:
      ```bash 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 ---
      ## Quick Reference — All Steps in OneExecution Block
      ```bash # 1. Remove providerprovider-enforced root blockrestriction from authorized_keys sudo sed -e "s/echo;sleep 10;exit 142//g" -i /root/.ssh/authorized_keys
      # 2. AllowEnable root login via SSH key only sudo sed -i 's/^.*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
      # 3. FixNormalize any drop-in overrides (if present) sudo sed -i 's/^.*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config.d/*.conf 2>/dev/null || true
      # 4. Reload SSH daemon sudo systemctl reload sshd || sudo service ssh reload ```
      Once root SSH access is confirmed, you can proceed with connecting your VM to Elestio at: **https://dash.elest.io/vm/byovm**
      Back to top