A frustrating issue with building a public Amazon AMI is the authorize key that you use to build and modify the instance must be removed (which removes your own access to the instance.) The private key must be removed before it is shared.
It’s like the old problem, which comes first the chicken or the egg. So you remove the key but now you can’t login to your own system. You can only rebuild an EC2 from the ami image. Beyond that, you only do an rm to delete the file but the block of key data is still there in the EBS disk image. Someone could easily unpack the block and undelete the file to restore the authorize key file, connect to your private instances and run up your AWS bill or worse.
What’s the solution? Using additional EBS connections to create an image. Here is the procedure:
- Create a new 1gb EBS volume, attach, and mount it on the running instance, say under
/keys Use the Amazon EBS guide to format and attach the EBS volume
- Copy your authorized_keys to the /keys on the new EBS
- Delete all sensitive files and all
authorized_keys (from the primary EBS) Also delete the bash.history file and any other logs or passwords.
sudo chmod 660 /root/.bash_history
- Exit Putty terminal windows and using Filezilla save empty history files to /root/.bash_history and /home/ec2-user/.bash_history
- Delete /tmp files
- Do not snapshot the live EBS volume as it still contains the deleted files and you don’t want to make them public in the new AMI. Instead,
- Create a new EBS volume, attach, and mount it on the running instance, say under
- Copy the root file system over to the new EBS volume. This only copies the current view of the undeleted files and does not copy the blocks containing the deleted files or any other modified file information. The command might look something like:
rsync -axvSHAX --exclude 'ebsimage' / /ebsimage/
- Copy you authorize_keys back to your primary EBS
- unmount and detach the new EBS volume.
- Create an EBS snapshot of the new EBS volume.
- Register the EBS snapshot as a new AMI.