Why does AWS's Ubuntu AMI come with an "ubuntu" user instead of just allowing root login?

Question

AWS's Ubuntu image gets bootstrapped with your credentials being added to a user called ubuntu. After the machine comes up, you can SSH into your new box with the ubuntu user.

This user is a sudoer, and based on the sudoers file, this user can do pretty much anything that root can, as long as you preface a command with sudo, without any password being entered. This negates some of the benefits of sudo because there is no interactive password prompt. As far as I can tell, this also pretty much means that you should never run public-facing applications as this user, because if someone could find a way to execute shell commands via your application, they could take control of your system.

My real question is: why does this user exist? Why not just grant SSH access to the root account, with the expectations that someone would create unprivileged accounts to run an app? Doesn't having this ubuntu user just add confusion? I could see someone thinking "my systemd application isn't running as root, it's running as ubuntu, so I am safe".

Am I missing some purpose of this kind of user, which is not root, but is a passwordless sudoer?

Answer 1

I chatted with one of my friends who works on the EC2 team, and he gave me a really good explanation.

The main difference to be discussed here is between a user who can run sudo without a password and can gain all privileges with sudo (passwordless sudoer), and the root user itself. My initial thought was that these two users are essentially the same, but as my friend explains, compromising the passwordless sudoer is inherently harder than the root user, if the attack vector is through an application.

The reason for the additional difficulty is that to gain sudo privilieges as a sudoer, you need shell access. Without the shell, an application running as the passwordless sudoer is essentially just a normal user. However, this means that if the passwordless sudoer were running an application that can execute shell commands on behalf of the user (i.e. Jenkins or some other CI tool), then the system could still be compromised.

It's still probably safest to run applications as a non-sudoer, but for most cases, I imagine that the passwordless sudoer is safe enough.

Full context of the discussion: