[ec2-beta] "ubuntu" passwordless sudo

[Paul Cullum]

Just some thoughts related to what is "Just Enough".  Adding the 
"ubuntu" as part of creating an instance implies to some degree that my 
system will have users or that it won't have users that might conflict 
with the ubuntu user.   Creating an instance is just the first step of 
me configuring an instance to my needs. 

One of my EC2 uses involves launching the instance an running a script 
to install some packages, creating some users (that won't have shell 
access), mounting an EBS home partition, and negotiating remote rsync 
connections to the instance.  This has been somewhat portable across a 
variety of AMIs that I've tried.  I had sort of settled on alestic 
Intrepid AMIs but signed up to try the Canonical AMIs.

1. The initial setup makes it harder to script automated usage.
2. The ubuntu user is something I have work around since there is a UID 
collision with my existing UIDS that I don't have with the alestic or 
other AMIs that I've tried.  Once my instance is configured there are 
other users but I don't really need the ubuntu user.

EC2 is flexible and while people may use it much the same way as a 
physical instance. Setting up accounts, configuring the system software 
and then rebundling.  Others may also just use it as a "transient" part 
of an automated script that starts with a simple generic up-to-date AMI 
every single time.  This second usage can be complicated by setup menus 
or extra user accounts.

Just some thoughts.

Paul

Eric Hammond wrote:
> Jamie:
>
> I had proposed the same (crazy) strategy of letting "ubuntu" use sudo
> without a password back when we were discussing the approach for the
> first official beta AMI.  I also described it again 11 hours ago in a
> response to one of Mark's post to this list, but apparently I didn't hit
> "reply all" so Mark was the only one who saw it :)
>
> What I like about this approach is that it is a compromise between the
> security evils of connecting as root all the time and the usability
> evils of having to jump through hoops to set or remember random
> passwords for lots of instances.
>
> We might even consider disabling all root ssh logins on the images.
> Users would always ssh in as "ubuntu" and then use sudo to perform
> privileged operations, even running an initial tasksel if they desire.
>
> One use case which I haven't talked about on the public list is that we
> need to continue supporting the automatic configuration of an instance
> by external scripts which ssh in.  Folks who take this approach
> currently write their code to ssh in as root to perform various software
> installation and configuration.  (Non-interactive first ssh to root was
> intended to be supported on the beta AMI but seems to be not working.)
>
> Over the last number of years I have written a fair amount of code which
> connects through ssh to a normal account and uses passwordless sudo to
> set up an Ubuntu system.  It's not always easy (especially with rsync)
> but it's always possible.
>
> Requiring this approach would cause people who are using automated
> external configuration to have to modify some code which might be a
> barrier to switching, but it does feel clean.
>
> This is actually the approach I had originally considered when I started
> building Ubuntu AMIs for EC2, but I didn't feel like I had the clout to
> convince EC2 people to do things my way.  Perhaps Canonical does :)
>
> --
> Eric Hammond
> ehammond at thinksome.com
>
>
>
> Jamie Strandboge wrote:
>   
>> With these things in mind, I'll put out there a (perhaps crazy) idea and
>> suggest setting up the user totally differently:
>>
>> a) setup a long random password for the ubuntu user, or perhaps simply
>> lock the account (passwd -l ubuntu)
>> b) setup up /etc/sudoers to not prompt for a password at all
>> ('Defaults:ubuntu !authenticate' and 'ubuntu ALL=(ALL) ALL')
>> c) move /root/.ssh/authorized_keys aside to disable ssh key root logins
>> after the first login
>>
>> In this scenario, the 'ubuntu' account should be safe (ie, you can't
>> 'su' into it from another account or login via ssh with a password), and
>> this gets the spirit of the Ubuntu non-root user back: specifically
>> normal access is non-root and there is a log audit trail for privileged
>> operations.
>>
>> Jamie
>>     
>
>
>