 | Feedback |  |
These guidelines are not requirements and you are welcome to follow or ignore them. However, following these guidelines produces a better user experience, helps ensure your users' instances are secure, and can protect you.
To build a shared AMI, follow these guidelines:
![[Note]](images/note.png) | Note |
|---|---|
These guidelines are written for Fedora distributions, but the principles apply to any AMI. You might need to modify the provided examples for other distributions. For other distributions, review their documentation or search the AWS forums in case someone else has done it already. |
We recommend that your AMIs download and upgrade the Amazon EC2 AMI creation tools during startup. This ensures that new AMIs based on your shared AMIs will have the latest AMI tools.
To update the AMI tools at startup on Fedora
Add the following to rc.local:
# Update the Amazon EC2 AMI creation tools echo " + Updating ec2-ami-tools" wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm && \ rpm -Uvh ec2-ami-tools.noarch.rpm && \ echo " + Updated ec2-ami-tools"
Use this method to automatically update other software on your image.
| Note |
|---|---|
When deciding which software to automatically update, consider the amount of WAN traffic that the update will generate (your users will be charged for it) and the risk of the update breaking other software on the AMI. |
| Note |
|---|---|
The preceding procedure applies to Fedora distributions. For other distributions:
|
Using a fixed root password for a public AMI is a security risk that can quickly become known. Even relying on users to change the password after the first login opens a small window of opportunity for potential abuse.
To solve this problem, disable password-based logins for the root user. Additionally, we recommend you randomize the root password at boot.
To disable password-based logins for root
Open the /etc/ssh/sshd_config file with a
text editor and locate the following line:
#PermitRootLogin yes
Change the line to:
PermitRootLogin without-password
The location of this configuration file might differ for your distribution, or if you are not running OpenSSH. If this is the case, consult the relevant documentation.
To randomize the root password, add the following to your boot process:
if [ -f "/root/firstrun" ] ; then dd if=/dev/urandom count=50|md5sum|passwd --stdin root rm -f /root/firstrun else echo "* Firstrun *" && touch /root/firstrun fi
| Note |
|---|---|
This step assumes that a /root/firstboot file is bundled with the image. If file was not created, the root password will never be randomized and will be set to the default. |
| Note |
|---|---|
If you are using a distribution other than Fedora, you might need to consult the documentation that accompanied the distribution. |
If you plan to share an AMI derived from a public AMI, remove the existing
SSH host key pairs located in /etc/ssh. This forces SSH to generate new
unique SSH key pairs when someone launches an instance using your AMI, improving
security and reducing the likelihood of "man-in-the-middle" attacks.
The following list shows the SSH files to remove.
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
After configuring the AMI to prevent logging in using a password, you must make sure users can log in using another mechanism.
Amazon EC2 allows users to specify a public-private key pair name when launching
an instance. When a valid key pair name is provided to the RunInstances
API call (or through the command line API tools), the public key (the portion
of the key pair that Amazon EC2 retains on the server after a call to CreateKeyPair)
is made available to the instance through an HTTP query against the instance metadata.
To login through SSH, your AMI must retrieve the key value at boot and append it to
/root/.ssh/authorized_keys (or the equivalent for any other user
account on the AMI). Users will be able to launch instances of your AMI with a
key pair and log in without requiring a root password.
if [ ! -d /root/.ssh ] ; then
mkdir -p /root/.ssh
chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
curl http://169.254.169.254/2008-02-01//meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
cat /tmp/my-key >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys
rm /tmp/my-key
fi
This can be applied to any user account; you do not need to restrict it to root.
| Note |
|---|---|
Rebundling an instance based on this image includes the
key with which it was launched. To prevent the key's
inclusion, you must clear out (or delete) the
|
Disabling sshd DNS checks slightly weakens your sshd security. However, if DNS resolution fails, SSH logins will still work. If you do not disable sshd checks, DNS resolution failures prevent all logins.
To disable sshd DNS checks
Open the /etc/ssh/sshd_config
file with a text editor and locate the following line:
#UseDNS yes
Change the line to:
UseDNS no
| Note |
|---|---|
The location of this configuration file can differ for your distribution or if you are not running OpenSSH. If this is the case, consult the relevant documentation. |
Currently, there is no easy way to know who provided a shared AMI as each AMI is represented by a numeric user ID.
We recommend that you post a description of your AMI, and the AMI ID, in the Amazon EC2 developer forum. This provides a convenient central location for users who are interested in trying new shared AMIs.
The previous sections described how to make your shared AMIs safe, secure, and useable for the users who launch them. This section describes guidelines to protect yourself from the users of your AMI.
We recommend against storing sensitive data or software on any AMI that you share. Users who launch a shared AMI might be able to rebundle it and register it as their own. Follow these guidelines to help you to avoid some easily overlooked security risks:
Always delete the shell history before bundling. If you attempt more than one bundle upload in the same image, the shell history contains your secret access key.
Bundling a running instance requires your private key and X.509 certificate. Put these and other credentials in a location that is not bundled (such as the ephemeral store).
Exclude the ssh authorized keys when bundling the image. The Amazon public images store the public key used to launch an instance with its ssh authorized keys file.
| Note |
|---|---|
Unfortunately, it is not possible for this list of guidelines to be exhaustive. Build your shared AMIs carefully and take time to consider where you might expose sensitive data. |
The simplest way to prevent users from rebundling Paid AMIs that you create is to not provide root access to the AMI and to pay attention to security announcements that involve privilege escalations. Amazon EC2 requires you to have root access any AMI that you rebundle.
If you must provide root access to an AMI, Amazon EC2 tools are designed to protect the product code. Although this is effective, it is not guaranteed and users might create AMIs using other tools.
To ensure users cannot rebundle your paid AMIs, we recommend that you configure your application to check the instance metadata to verify that the product code is intact.
