All Products
Search
Document Center

Elastic Compute Service:Avoid root logon for Linux instances

Last Updated:May 15, 2026

Use ecs-user instead of root to reduce attack surface and enable auditable privilege escalation.

Security risks

The root account has unrestricted system permissions. If root credentials (password or SSH key) are compromised, an attacker gains full server control. Consequences include:

  • Data destruction: delete business data, logs, and backups.

  • Malware installation: install ransomware, mining programs, or back doors.

  • Sensitive information theft: steal business code, customer data, and payment information.

  • Lateral movement: use the server as a launchpad to attack other servers in your internal network.

  • Erasing operational traces: modify or delete log files, making security event investigation difficult.

Best practices

Create instances with ecs-user for daily logon. This limits the attack surface and ensures all privileged operations go through sudo, leaving a clear audit trail.

Console

On the Instance Buy page, set Logon Username to ecs-user.

The ecs-user user is supported only on specific Linux image versions. If your image does not support it, create the ecs-user user and grant sudo permissions. See Multi-user remote logon.

API

Call RunInstances or CreateInstance with ImageOptions.LoginAsNonRoot set to true. The instance then uses ecs-user instead of root, and the root password cannot be reset.

If you do not have a key pair, call CreateKeyPair to create one.

Compliance

Check: find Linux instances using root logon

  1. Go to ECS Insight.

  2. Select the Security tab and click Use of Non-root Users for Logons to Linux ECS Instances to view instances using root logon.

Block: prevent root account operations such as instance creation

Use a RAM policy to block root account operations such as creating Linux instances. Apply the policy at the organization or account level.

  • Enterprise users:

    1. Log on to the Resource Directory console with your Alibaba Cloud account. In the navigation pane, click Control Policies. Create a custom policy and paste the following JSON content.

      This policy denies root identity operations such as creating instances, attaching system disks, and replacing system disks.

      {
          "Version": "1",
          "Statement": [
              {
                  "Action": [
                      "ecs:RunInstances",
                      "ecs:CreateInstance",
                      "ecs:ReplaceSystemDisk",
                      "ecs:AttachDisk",
                      "ecs:InvokeCommand"
                  ],
                  "Resource": "*",
                  "Condition": {
                      "Bool": {
                          "ecs:LoginAsNonRoot": [
                              "false"
                          ]
                      }
                  },
                  "Effect": "Deny"
              }
          ]
      }
    2. In Resource Directory, select an appropriate node and attach the policy. The policy blocks the specified operations for all accounts in the directory.

  • Non-enterprise users:

    1. Log on to the RAM console with your Alibaba Cloud account. In the navigation pane, click Permission Policy. Create a custom policy with the same content.

    2. Attach the policy to RAM users, RAM user groups, or RAM roles. See Manage access policies.

Fix: disable root account logon

  1. Create a regular user for SSH logon. See Multi-user remote logon.

  2. Log on to the instance as root or a regular user.

  3. Disable root SSH logon. Run the following script to modify the SSH configuration:

    #!/bin/bash
    # Back up the original configuration file
    cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_$(date +%F)
    
    # Disable SSH logon for the root user: Change the PermitRootLogin parameter to no
    sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
    
    # Restart the SSH service for the configuration to take effect
    # Note: The SSH service name may vary by distribution (for example, sshd or ssh). Modify it as needed.
    systemctl restart sshd || service sshd restart
  4. Verify the change. Keep the current session open and open a new terminal. Confirm that root logon fails and that your regular user can log on and run sudo commands. Then disconnect all sessions.

    After verification, the check result may not update immediately. You can ignore this delay.