Allowing root access in AMIs created/derived from Amazon Linux AMIs

Short answer: Edit /etc/cloud/cloud.cfg and set disable_root: 0, and in /etc/ssh/sshd_config set PermitRootLogin to without-password.

There are a lot of people asking on the AWS forums, and elsewhere, about how to make AMIs derived from Amazon Linux AMIs, such that the users of the derived AMI can launch an instance and allow root user to login vi SSH.

But, the way Amazon Linux AMIs are configured, the root user is greeted with a message like 'Please login as ec2-user rather than root user' and the connection is terminated after 10 seconds.

The reasoning behind having such a setup is that, that allowing root user login from SSH opens up the instance to vulnerabilities. And at the same time the recommended solution is to login as ec2-user and do a `sudo su -` to gain root access.

I find it bogus to disallow root access over SSH and then allow ec2-user to access root account without any restrictions!!! And mind you, all access is using public/private keypairs generated and supposedly handled carefully by the user.

If anything, they should document how to deny root access to the ec2-user, if so desired by the AMI creator.

Okay, now the technical guts of how to fix this situation.

The reason behind that message upon root SSH login is that the file /root/.ssh/authorized_keys contains a 'command' prefix to the authorized key, similar to:

command="echo Please login as ec2-user user rather than root; sleep 10; exit 0" ssh-rsa AAP...

Even after you remove the 'command' and everything before the 'ssh-rsa', the /etc/ssh/sshd_config has a setting that will disallow root login.

And even if you fix all this, you will discover that when you bundle up an AMI from your instance (which is created from an Amazon Linux AMI) and launch the instance from this derived AMI, you will be back to square one, since the /root/.ssh/authorized_keys will again contain the same 'command=' prefix!

So here's how to fix this:

Launch an instance from Amazon Linux AMI, and do whatever customization you want. When you are ready to create an AMI (derived AMI) from this instance, run the following 4 commands, and the instances created from your derived AMI will not have this problem:

$ sudo perl -i -pe 's/disable_root: 1/disable_root: 0/' /etc/cloud/cloud.cfg
$ sudo perl -i -pe 's/#PermitRootLogin .*/PermitRootLogin without-password/' /etc/ssh/sshd_config
$ sudo perl -i -pe 's/.*(ssh-rsa .*)/\1/' /root/.ssh/authorized_keys
$ sudo /etc/init.d/sshd reload # optional command

  1. Ask the EC2 node configuration scripts installed on the AMI to not disable root login.
  2. Ask sshd daemon to allow password-less (but public-key based) root logins.
  3. Strip the 'command=...' prefix from root user's authorized_keys.
  4. Reload shd config for the sshd_config to take effect.

Commands 3 and 4 are really necessary only if you want to login into your current instance (created from Amazon Linux AMI) using root login. The first two commands are sufficient to allow SSH based root login into instances of your derived AMI.


  1. Thanks, it worked!
    I was not able to complete the last command, Aparently I do not have sshd installed:
    -bash: /etc/init.d/sshd: No such file or directory
    I beleive it is because I have Ubuntu 12.04 and these instructions are for an erlier version.
    So I just rebooted and it worked fine.

    1. In Ubuntu 12 AMI just change the last command to:

      # reload ssh


  2. What you say is right on the mark. It is extremely inconvenient that I have to log in with 'ec-user'. For puTTY it is fine, but anything done via sftp doesnt give me enough access privileges. I would love to be able to apply the cahnges you mentuion here, but I do not even have an '/etc/cloud' folder on my AMI. What else can I try?

  3. This comment has been removed by the author.

  4. This comment has been removed by the author.

  5. This comment has been removed by the author.

  6. Thank you Thank you for your blog ..I have been trying to give root access to the derived amis .. I followed other blog posts but they did not mention step 1 ...So I could give root acess only to the instance but not to instances in the derived amis... Plus the automated perl scripts save a lot of time :)

  7. This is a life-saver. Thanks a ton Gurjeet. :)