我们正在尝试制作一个安全的 AMI 以分发给我们的一位客户（运行 Linux/CoreOS）。一旦我们的客户部署了我们的 AMI，重要的是他们不能获得 shell 访问权限（例如不能通过 SSH 进入）。
从表面上看，这似乎是一个非常容易解决的问题：只需确保只有我们的密钥在 authorized_keys 文件中即可。但是，当我们的客户部署我们的 AMI 时，他们必须提供自己的密钥对，然后将关联的公钥插入到盒子上的 authorized_keys 文件中，使他们能够通过 SSH 进入盒子。
我知道 Amazon 通过 169.254.169.254 上的 HTTP 使主机操作系统可以访问公钥（和用户元数据）（信息如下：http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。在互联网和 CoreOS 文件系统上进行的一些调查表明 /usr/bin/coreos-metadata 实际上访问了这个 IP，大概是为了密钥对，但我搞不清楚到底是什么启动了该可执行文件或如何禁用它。我甚至考虑过删除可执行文件权限或将其完全删除，但文件系统的这一部分在 CoreOS 上是只读的（甚至对 root 也是如此）。
显然，上述行为会破坏我们采取的任何安全措施。我们可以做些什么来防止这种情况发生？
答案1
cloud-init正在执行此操作。禁用sshd运行（AMI 构建的一部分），然后运行脚本代码，将您的密钥放在登录用户下（建议使用不同的用户），启动ssh。我还建议使用不同的端口号，以便轻松确认一切正常。