如何安全管理EC2管理的密钥对的私钥？

为了启动EC2实例，您需要一个密钥对。您如何处理拥有该密钥对私钥的工程师离开公司的情况？在实例启动后立即添加单个ssh访问并取消对初始密钥对的授权是否可行？

当员工或承包商离开公司时，您需要禁用他们对公司资源的任何特权访问。这包括（但不限于）您的ssh关键问题：

1. 从所有正在运行的实例上的所有authorized_keys文件中删除公共ssh密钥。用新生成的公共ssh密钥替换它们，该密钥仅应具有访问权限的人员知道。

2. 删除部门中已知的EC2中的所有密钥对条目，以使新实例无法使用这些密钥对启动。将它们替换为新的密钥对条目，如果您使用的是相同的名称，则可以使用相同的名称

您提出的另一种方法也不错，也是我使用的一种方法：禁用初始ssh密钥，并为每个开发人员添加单独的公共ssh密钥，以便他们可以使用其常规的私人ssh密钥登录。可以执行此操作以登录共享帐户，也可以让每个开发人员获得自己的个人用户帐户（我更喜欢）。

员工离职后，您不仅需要清理正在运行的服务器，还需要清理将ssh密钥添加到新服务器的过程。而且，当一名员工加入时，您需要做相反的事情：向正在运行的服务器添加ssh密钥并更新新的服务器进程。

要在许多服务器上维护许多ssh密钥，可能需要做更多的工作，但这就是自动化的地方。

您永远不要将此私钥提供给最终用户。应当为最终用户提供他们自己的登录方式，例如公钥认证（使用其OWN密码保护的私钥），然后进行LDAP授权。

分发ec2提供给您的私钥将使您无法取消供应用户。这正是所有安全和合规性法规完全禁止使用共享凭据的原因。

当您允许使用共享凭据时：

• 无法使用日志来了解谁是主机的真实身份
• 如果不取消对所有用户的取消配给，就无法取消对用户的配给（包括紧急访问，这是EC2私钥的真正用途）

请参阅有关访问凭证轮换的 Amazon文档。

如果您不想重新启动所有内容，或者只是重新启动所有内容，请使用诸如puppet或solid ssh脚本之类的东西运行并替换旧密钥的所有实例。