The official Ubuntu images for EC2 do not allow ssh directly to the root account, but instead provide access through a normal “ubuntu” user account. This practice fits the standard Ubuntu security model available in other environments and, admittedly, can take a bit of getting used to if you are not familiar with it.
This document describes how to work inside this environment using the “ubuntu” user and the sudo utility to execute commands as the root user when necessary.
SSH
First, to connect to an instance of an official Ubuntu image for EC2, you need to ssh to it as “ubuntu” instead of as “root”. For example:
ssh -i KEYPAIR.pem ubuntu@HOSTNAME
Note that existing EC2 documentation and tools like the EC2 Console and Elasticfox assume that all EC2 instances accept connections to root, so you’ll have to remember this change.
If you accidentally ssh to root on one of the official Ubuntu images, a short message will be output reminding you to use “ubuntu” instead.
SUDO
When logged in under the “ubuntu” user, you can run commands as root using the sudo command. For example:
sudo apt-get update && sudo apt-get upgrade -y
Note that sudo clears the environment variables before running the command. If you need to have them set, then use the sudo -E option.
SUDO PASSWORD
The official Ubuntu images for EC2 are configured so that no password is required for sudo from the “ubuntu” user. Yes, this sacrifices a bit of security from standard Ubuntu operation, but any published hardcoded password would be more insecure, and randomly assigned passwords quickly become unmanageable when running many instances, in addition to preventing some types of remote automation described below.
Note that this policy does not allow logging in to the “ubuntu” user without a password. The password is disabled for login and not required for sudo. Login is done through the usual EC2 ssh keypair management as described above.
If you wish to increase security in this area, set the ubuntu user password and adjust the /etc/sudoers file.
sudo passwd ubuntu
sudo perl -pi -e 's/^(ubuntu.*)NOPASSWD:(.*)/$1$2/' /etc/sudoers
Make sure you set the password successfully first and remember it. If you change the sudoers file first, you will be stuck with no root access on that instance.
ROOT SHELL
If you want to switch to a root shell once you are logged in to the “ubuntu” user, simply use the command:
sudo -i
This is generally not recommended as it loses the enhanced logging of commands used as root and you risk accidentally entering commands when you did not intend to use root.
SSH SUDO
To automate a remote command as root from an external system,
connect to “ubuntu” and use sudo:
ssh -i KEYPAIR.pem ubuntu@HOSTNAME 'sudo apt-get install -y apache2'
RSYNC
Now for the trickiest one. Sometimes you want to rsync files from an external system to the EC2 instance and you want the receiving end to be run as root so that it can set file ownerships and permissions correctly.
rsync -Paz --rsh "ssh -i KEYPAIR.pem" --rsync-path "sudo rsync" LOCALFILES ubuntu@HOSTNAME:REMOTEDIR/
The --rsh option specifies how to connect to the EC2 instance using the correct keypair. The command in the --rsync-path option makes sure rsync is running as root on the receiving end.
The -Paz options are just some of my favorites. They aren’t a key part of this rsync approach.
In order for this method to work, the “ubuntu” user must be able to sudo without a password (which is the default on the official Ubuntu images as described above).
ROOT SSH
Finally, if you wish to circumvent the Ubuntu security standard and revert to the old practice of allowing ssh and rsync as root, this command will open it up for a new instance of the official Ubuntu images:
ssh -i KEYPAIR.pem ubuntu@HOSTNAME 'sudo cp /home/ubuntu/.ssh/authorized_keys /root/.ssh/'
This is not recommended, but it may be a way to get existing EC2 automation code to continue working until you can upgrade to the sudo practices described above.
SEE ALSO
For more information on recommended sudo practices in Ubuntu, please refer to:
https://help.ubuntu.com/community/RootSudo
Comments? Questions?
[Updated 2009-04-30: Simplified rsync instructions.]
Follow Eric Hammond on Twitter
I think this is worth mentioning: If specifying the identity file and username on the command line gets boring, create a ~/.ssh/config with
Host HOSTNAME
User ubuntu
IdentityFile /path/to/KEYPAIR.pem
and then you'll be able to use 'ssh HOSTNAME'.
Nice tip! You can also use wildcards in the config file to match all standard EC2 external hostnames as in:
If you run an ssh-agent, you can also add your EC2 keypair key using something like:Then it doesn't matter what hostnames you use.
Just FYI, for anyone who thinks this increases security, you're still using a shared account with full privileges. This is no different than using a shared root account.
But it does make it easier to start using named accounts because you can simply remove the ubuntu user and not worry about any other configuration (such as changing PermitRootLogin in ssh_config).
Paul: I assume by "this" you mean the way that the official Ubuntu images are configured with an ubuntu user who can sudo without a password.
The only change that you need to apply to get to the full default Ubuntu security mode is to set a password for the "ubuntu" user as described in the "SUDO PASSWORD" section above.
Even if you don't require a password to sudo, using a normal user prevents some accidental disasters that can happen if you sit with a root shell in front of you.
The ubuntu user is there to give you secure access to the EC2 instance after initially running it. It is completely up to the owner how to configure the system from that point.
If you plan to have multiple human users, I agree that it's a good idea to create multiple user accounts.
As a side note, the official Ubuntu images currently have "PermitRootLogin yes" in sshd_config. This allows them to give a message to the user who tries to connect as root, redirecting them to "ubuntu@" (something I think is going to be fairly common with new users of these AMIs).
Thank you for the great tips!
Any idea how to get ssh with passwords enabled? (no identity-file)
ie: ssh ubuntu@host
Hi Eric
The perl to rewrite /etc/sudoers flies in the face of visudo.
I don't mind, but others might :-)
Terry
I'm getting
ssh_exchange_identification: Connection closed by remote host
when trying to connect to an canonical AMI through a ssh tunnel (I'm on a Mac behind a firewall). Everything works fine without the tunnel. I guess i have to make some changes to the ssh config. But whicht?
Thanks in advance
Gerd
Björn: Yes, it is possible to enable ssh with passwords through appropriate sshd configuration changes, though it does reduce security a bit depending on the passwords chosen. In cases where this is required, I recommend "sudo apt-get install denyhosts" to improve protection against dictionary attacks.
Terry: Yeah, I guess the Perl command does make some assumptions about the state of the /etc/sudoers file and if those assumptions are not accurate, you could be prevented from doing a sudo to fix it.
It might be more appropriate to send the output to a temporary file and run a check before moving it back into place, say:
visudo -c -f /tmp/sudoers && mv /tmp/sudoers /etc/sudoers
Gerd: It's difficult to debug somebody else's ssh problems as there are so many potential factors involved. You might try listing all of the information you think might be relevant in as much detail as possible on the EC2 Ubuntu support group and see if anybody has the time to help debug it: http://ec2ubuntu-group.notlong.com
Hi Eric
If disabling root and using ubuntu is a recommended sudo practice, is there a reason the alestic images are root-enabled?
I'm sure there is a discussion on this somewhere with all the pros, cons and flames. But I'd like to hear your rationale and can't seem to find it anywhere.
Thanks,
Anoop
Anoop: When I first started building public images for Ubuntu on EC2 back in 2007 I had wanted to follow the Ubuntu standard of using a normal user with sudo to root. However, my primary audience at the time was EC2 users and not Ubuntu users. I figured the images would get faster adoption if they followed the EC2 standard of ssh to root with keypairs, especially since many of the users would never read any documentation and would simply think that the image was broken if it didn't allow ssh as root.
When Canonical started work on building images, I pushed for the Ubuntu standard of non-root login, thinking that their audience would contain more existing Ubuntu users and the rest of the population would be swayed to accept the change by the official nature of the Canonical name.
If I continue publishing images into the distant future, I may switch to the Ubuntu standard, but it would only be for new AMIs (obviously) and there would be advance notice and opportunity for discussion on the ec2ubuntu group.
On my long running personal and company EC2 instances, I always add normal user(s) and use them for further access.
A quick note on Elasticfox:
On recent versions (I'm using 1.7.000112), it's easy to change the user that's used for SSH connections. Click the "Tools" button in the upper right corner of the window, and set "SSH User" to "ubuntu" (or whatever).
You can set it back to "root" to connect to other instances as needed (although it's a pain if you have to do that a lot).
Thank you Eric. I am a beginner and the information on your website has helped me tremendously in learning and understanding a lot of important concepts around EC2 and Ubuntu.
Thanks again
Ramesh
Wow. So in trying to add a new user to the sudoers file I inadvertantly created another entry for the 'ubuntu' user without the NOPASSWD directive. This means I have lost access to root privileges on this instance.
Can anyone think of a way for me to get back root access? I would love not to have lost hours of work because of a typo.
brandon:
Sure. "stop" the original EBS boot instance, detach the root EBS volume from the original instance, attach it to a different instance, edit the sudoers file, move the volume back, and restart the instance.
If you're running instance-store instead of EBS boot, then you might be out of luck. Yet another reason to run EBS boot instances.