3

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?

BadApple
  • 33
  • 1
  • 3
  • I haven't tried it, but create another user, give it sudo access for managing stuff, and revoke sudo access to the main account that AWS will be granting access to? – ceejayoz Aug 31 '16 at 13:27
  • Another option - use the sshd `AllowUsers` directive to only allow ssh access via a user that's separate from the default built-in user. – EEAA Aug 31 '16 at 13:52
  • Stop instance, detach volume, attach to a different instance, mount, modify authorized_keys, sudoers, etc., unmount, detach, reattach, restart... owned. Or I can just make a snapshot of the volume if I just want to see the files. Encryption? Well, the key has to be there somewhere. I would assert that this has no technical solution, and it doesn't actually sound like a technical problem -- it sounds like a concern to be addressed contractually... or by running your software in your own VPC, peered with the customer's VPC, where they can access it securely with identical performance. – Michael - sqlbot Sep 01 '16 at 01:52
  • 1
    All really good points. I ended up making a new user, then using AllowUsers to disable the default user. As an added layer of protection, I added a script to run on boot that blitzes the authorized_keys file of the default user and replaces it with a default key. With these stated I understand that there is no way to fully protect a volume mounted into a foreign VPC. We do have contractual terms in place to prevent this, so those will have to suffice. – BadApple Sep 01 '16 at 23:34

1 Answers1

2

cloud-init is doing this. Disable sshd from 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 up ssh. I also suggest a different port number as an easy way to confirm you have things working right.

Skaperen
  • 1,094
  • 2
  • 11
  • 23
  • Another idea: make the cloud-init default user point to a non-existent account. You could also set the shell to /bin/false. http://cloudinit.readthedocs.io/en/latest/topics/examples.html – dmourati Sep 01 '16 at 02:19