[ec2-beta] document: EC2 Ubuntu sudo Guide

[Michael Greenly]

>
>
> Well, the use of a non-root 'admin' user is just part of the standard
> Ubuntu setup. I don't think that this should ever change for an AMI
> image of Ubuntu (provided by Ubuntu or Canonical, that is), unless it
> has already changed as part of the base OS, that is. Given that the
> AMIs are 'post-installation', the choice of the administrative user
> has already been made, and it's 'ubuntu' rather than your own name ...


I disagree.  It shouldn't do something different than every other AMI unless
there' s some advantage.  On any machine that supports logins with a
password there are arguably some advantages in going that route but when you
don't allow password authentication the only advantage I'm aware of is that
sudo provides some logging.

Except that 'sudo su' works and that steps right past all the logging.

I'm just hoping that the people who made the decision to deviate from the
norm can point me to some literature that describes why it was a good idea?
If changes that effect security are being made without adequate planning
that concerns me.



> Perhaps I'm missing something in this conversation here; what are you
> using the Ubuntu AMI images for? Do you want to run them directly, or
> use them as the base for your own images? If you are going to
> customise and make your own images, then if you find something you
> don't like, change it :-)


The Ububut AMI's don't do anything themselves.  They have no services
preconfigured.  So they're always the base for a customized configuration.


>
> > Reading Eric's notes and the comments below it seems that extra
> > security is being added at the wrong level.
>
> If there's something *specific* to EC2 about your suggestion, then
> it's relevant. Obscuring the ssh port in this way doesn't seem to be
> especially specific to EC2 -- it is of some value, but is essentially
> only security by obscurity (not that there's anything wrong with that,
> used as an extra layer -- just don't use it as the only layer of
> defence!). All SPA does in terms of information theory is increase the
> amount of secret data that must be known/presented before getting that
> all-important shell prompt.


My personal preference is to run SSH on non standard ports and to limit
connections to known hosts.

As a side note, in case this hasn't occurred to any else.  Elastic IPs make
it very easy to limit in bound connections to specific IP addresses.  You
create an transient server to act as an intermediate.  You only bring the
transient server from a fresh AMI when you need to make connections.  This
means that it usually isn't up and gives attackers very little time to
target it.  Then you configure the applicaiton server to only accept
connections from the IP address assigned to the transient server.



>
> > Hopefully fwknop support can be built in by default - ideally it'd
> > become the AWS's recommended (Linux) practice :)
> > Of course people (Canonical?) may not want admin's to have to run some
> > SPA/fwknop client script before ssh'ing, in which case perhaps a
> > Ubuntu server config option could be 'fwknop protected ssh login'?
>
> fwknop doesn't seem to be packaged for either Debian or Ubuntu yet, so
> that's the first step. No point considering it for official AMIs if it
> isn't even packaged for the OS yet :-)
>
> -jim
>
> --
> Ec2-beta mailing list
> Ec2-beta at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ec2-beta
>



-- 
Michael Greenly
http://blog.michaelgreenly.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/mailman/private/ec2/attachments/20090308/9bfb7b2f/attachment-0002.htm