[ec2-beta] document: EC2 Ubuntu sudo Guide
Michael Greenly
mgreenly at gmail.com
Sat Mar 7 19:04:32 GMT 2009
I finally got around to trying to rebuild my images using the Ubuntu EC2
beta images. I use Capistrano to script the process of building my AMIs and
inside those scripts I use 'put' to upload erb translated configuration
files to instance. I'm fairly certian that there's no way to make
Capistrano 'put' work with 'sudo'? So I'm wondering if anyone has any
suggestions?
Some of the things I've considered are....
uploading to temp files and then sudoing in to move them to there final
destination. (this is most likely)
rewriting my scripts to do the translation locally and then using the rsync
hack below.
enabling root logins while the servers being configured and then disabling
it when I'm done.
Any one have any other options?
Does anyone have really good justification for being forced into sudoing
through the ubuntu user? I can come up with a few fantasy scenearios where
it offers a small amount of additional protection but this AMI is one of the
few taking this approach and it ceritanly makes all of my scripts a lot
uglier?
On Thu, Feb 26, 2009 at 10:14 PM, Eric Hammond <ehammond at thinksome.com>wrote:
>
> The latest official Ubuntu beta images do not allow ssh directly to the
> root account, but instead provide access through a normal "ubuntu" user
> account.
>
> I have attached a first draft of a document which describes how to use
> ssh and rsync to remotely manage an EC2 instance in this mode.
>
> Questions, feedback, and corrections welcomed.
>
> --
> Eric Hammond
> ehammond at thinksome.com
>
>
>
> Using sudo, ssh, rsync on the official Ubuntu beta EC2 images
>
>
> author: Eric Hammond
> <ehammond at thinksome.com>
> update: 2009-02-26
>
>
> The latest official Ubuntu beta images 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 the instance, you need to ssh to it as "ubuntu"
> instead of as "root". For example:
>
> ssh -i KEYPAIR.pem ubuntu at 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 beta
> 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 current official Ubuntu beta images 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
>
> sudo perl -pi.orig -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
>
>
> SSH SUDO
>
> To automate a remote command as root from an external system,
> connect to "ubuntu" and use sudo:
>
> ssh -i KEYPAIR.pem ubuntu at 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.
>
> To set this up, send the following helper script to the instance
> first (one time step):
>
> ssh -i KEYPAIR.pem ubuntu at HOSTNAME \
> 'sudo tee /usr/local/bin/su-rsync >/dev/null <<"EOM"
> #!/bin/sh
> user="$1"; shift
> command="rsync $@"
> sudo su "$user" -c "$command"
> EOM
> sudo chmod 755 /usr/local/bin/su-rsync'
>
> Then, you can rsync files in from external systems using commands
> like:
>
> rsync -Paz \
> --rsh "ssh -i KEYPAIR.pem" \
> --rsync-path "/usr/local/bin/su-rsync root" \
> LOCALFILES \
> ubuntu at HOSTNAME:REMOTEDIR/
>
> The --rsh option specifies how to connect to the EC2 instance using
> the correct keypair. The --rsync-path option uses the above helper
> script to become 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 (default on the official Ubuntu beta 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
> beta images:
>
> ssh -i KEYPAIR.pem ubuntu at 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.
>
> --
> 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/20090307/0b14112e/attachment-0002.htm
More information about the Ec2-beta
mailing list