We are trying to make a secured AMI for distribution to one of our customers (running Linux/CoreOS). Once our customer deploys our AMI, it is important that they cannot obtain shell access (e.g cannot SSH in).
On the surface, this seems like a very simple problem to solve: just make sure that only our keys are in the authorized_keys files. However, when our customer deploys our AMI, they are forced to provide their own key pair, and then the associated public key is inserted into the authorized_keys file on the box, enabling them to SSH into the box.
I know that Amazon makes the public key accessible (and user metadata) to the Host OS via HTTP on 169.254.169.254 (info here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html). Some sleuthing around the Internet and the CoreOS filesystem suggests that the /usr/bin/coreos-metadata actually accesses this IP, presumably for the keypair, but I can't figure out what is actually kicking off that executable or how to disable it. I even thought about removing executable privileges or remove it entirely, but that part of the filesystem is read-only on CoreOS (even to root).
Obviously the above behavior trumps whatever security measures we put in place. Is there anything we can do to prevent this from happening?
Best Answer
cloud-initis doing this. Disablesshdfrom running (part of your AMI build), then have script code run that puts your keys in place under the login user (a different one is suggested), start upssh. I also suggest a different port number as an easy way to confirm you have things working right.