在团队中管理 SSH 密钥的最佳实践是什么？

Question 1

在我的公司，我们使用 LDAP 在所有机器上拥有一组一致的帐户，然后使用配置管理工具（在我们的例子中目前是 cfengine）authorized_keys在所有服务器上为每个用户分发文件。密钥文件本身（连同其他系统配置信息）保存在 git 存储库中，因此我们可以看到密钥何时来来去去。cfengine 还使用sudoersLDAP 目录中的用户和组分发一个文件，该文件控制谁有权在每个主机上以 root 身份运行什么。

我们的生产服务器完全禁用密码验证，因此 SSH 密钥验证是强制性的。政策鼓励为每台笔记本电脑/台式机/其他设备使用单独的密钥，并在所有密钥上使用密码，以减少笔记本电脑丢失/被盗的影响。

我们还有一个堡垒主机，用于访问生产网络上的主机，这使我们能够在该网络周围制定非常严格的防火墙规则。大多数工程师都有一些特殊的 SSH 配置来使其透明：

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

在此设置中，添加新密钥或删除旧密钥需要一些仪式。我认为，添加新密钥最好是一个留下审计线索并可供所有人查看的操作。但是，由于涉及的开销，我认为人们有时会在不再需要旧密钥时忽略删除它，而且除了在员工离职时进行清理外，我们没有真正的方法来跟踪这一点。这还会在新工程师入职时产生一些额外的摩擦，因为他们需要生成新密钥并将其推送到所有主机，然后才能完全投入工作。

然而，最大的好处是每个用户都有一个单独的用户名，这使得我们在需要时可以轻松进行更细粒度的访问控制，并为每个用户提供一个显示在审计日志中的身份，这在尝试将生产问题追溯到系统管理员操作时非常有用。

在这种设置下，让自动化系统对生产主机采取行动是很麻烦的，因为它们“众所周知的” SSH 密钥可以作为替代访问路径。到目前为止，我们只是让这些自动化系统的用户帐户只具有完成工作所需的最低限度的访问权限，并接受恶意用户（必须已经是具有生产访问权限的工程师）也可以使用应用程序的密钥半匿名地执行相同的操作。

Answer

在我的公司，我们使用 LDAP 在所有机器上拥有一组一致的帐户，然后使用配置管理工具（在我们的例子中目前是 cfengine）authorized_keys在所有服务器上为每个用户分发文件。密钥文件本身（连同其他系统配置信息）保存在 git 存储库中，因此我们可以看到密钥何时来来去去。cfengine 还使用sudoersLDAP 目录中的用户和组分发一个文件，该文件控制谁有权在每个主机上以 root 身份运行什么。

我们的生产服务器完全禁用密码验证，因此 SSH 密钥验证是强制性的。政策鼓励为每台笔记本电脑/台式机/其他设备使用单独的密钥，并在所有密钥上使用密码，以减少笔记本电脑丢失/被盗的影响。

我们还有一个堡垒主机，用于访问生产网络上的主机，这使我们能够在该网络周围制定非常严格的防火墙规则。大多数工程师都有一些特殊的 SSH 配置来使其透明：

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"

在此设置中，添加新密钥或删除旧密钥需要一些仪式。我认为，添加新密钥最好是一个留下审计线索并可供所有人查看的操作。但是，由于涉及的开销，我认为人们有时会在不再需要旧密钥时忽略删除它，而且除了在员工离职时进行清理外，我们没有真正的方法来跟踪这一点。这还会在新工程师入职时产生一些额外的摩擦，因为他们需要生成新密钥并将其推送到所有主机，然后才能完全投入工作。

然而，最大的好处是每个用户都有一个单独的用户名，这使得我们在需要时可以轻松进行更细粒度的访问控制，并为每个用户提供一个显示在审计日志中的身份，这在尝试将生产问题追溯到系统管理员操作时非常有用。

在这种设置下，让自动化系统对生产主机采取行动是很麻烦的，因为它们“众所周知的” SSH 密钥可以作为替代访问路径。到目前为止，我们只是让这些自动化系统的用户帐户只具有完成工作所需的最低限度的访问权限，并接受恶意用户（必须已经是具有生产访问权限的工程师）也可以使用应用程序的密钥半匿名地执行相同的操作。

Question 2

我个人喜欢这样的想法：每个员工在专用的 ssh 堡垒机上拥有一个密钥，并在该堡垒机上拥有一个基本用户帐户。该用户帐户有 1 个 ssh 密钥，可授予他们需要使用的所有服务器的访问权限。（这些其他服务器也应被防火墙隔离，以便只启用堡垒机的 ssh 访问）

然后，在他们的日常工作机器、笔记本电脑、平板电脑等上，他们可以自行选择使用一个或多个密钥。

作为该网络上的系统管理员，您需要保管最少数量的密钥（每个开发人员一个），可以轻松监控通过网络的 ssh 访问（因为所有访问都通过堡垒机路由），并且如果开发人员想要多个密钥或只是一个在他们的机器之间共享的密钥，这不是什么大问题，因为您只有一台机器需要更新。（除非堡垒的 ssh 密钥被泄露，但说实话，这比用户密钥被泄露的可能性要小得多）

Answer

我个人喜欢这样的想法：每个员工在专用的 ssh 堡垒机上拥有一个密钥，并在该堡垒机上拥有一个基本用户帐户。该用户帐户有 1 个 ssh 密钥，可授予他们需要使用的所有服务器的访问权限。（这些其他服务器也应被防火墙隔离，以便只启用堡垒机的 ssh 访问）

然后，在他们的日常工作机器、笔记本电脑、平板电脑等上，他们可以自行选择使用一个或多个密钥。

作为该网络上的系统管理员，您需要保管最少数量的密钥（每个开发人员一个），可以轻松监控通过网络的 ssh 访问（因为所有访问都通过堡垒机路由），并且如果开发人员想要多个密钥或只是一个在他们的机器之间共享的密钥，这不是什么大问题，因为您只有一台机器需要更新。（除非堡垒的 ssh 密钥被泄露，但说实话，这比用户密钥被泄露的可能性要小得多）

Question 3

我曾经遇到过这样的情况：需要为一个由 40 名开发人员组成的团队提供对大约 120 个远程客户服务器的 SSH 密钥访问权限。

我通过强制开发人员通过单个“跳转主机”进行连接来控制访问。从该主机，我生成私钥/公钥并将其推送到客户服务器。如果开发人员需要从笔记本电脑进行访问，他们可以在本地系统上使用相同的密钥对。

Answer

我曾经遇到过这样的情况：需要为一个由 40 名开发人员组成的团队提供对大约 120 个远程客户服务器的 SSH 密钥访问权限。

我通过强制开发人员通过单个“跳转主机”进行连接来控制访问。从该主机，我生成私钥/公钥并将其推送到客户服务器。如果开发人员需要从笔记本电脑进行访问，他们可以在本地系统上使用相同的密钥对。

Question 4

我听说过但自己没有用过的一种方法是让每个用户都有一个软件包（例如 .deb、.rpm），其中包含他们的 ssh 公钥配置以及他们想要自定义的任何点文件（.bashrc、.profile、.vimrc 等）。这些文件已签名并存储在公司存储库中。这个软件包还可以负责创建用户帐户，或者它可以补充创建帐户的其他程序（cfengine/puppet 等）或 LDAP 等中央身份验证系统。

然后，这些包将通过您喜欢的任何机制（cfengine/puppet 等、cron 作业）安装到主机上。一种方法是使用依赖于每个用户包的元包。

如果您想要删除公钥，但不想删除用户，则每个用户的软件包都会更新。如果您想要删除用户，则删除软件包。

如果您有异构系统并且必须同时维护 .rpm 和 .deb 文件，那么我认为这有点烦人，尽管像 alien 这样的工具可能会让这变得更容易一些。

就像我说的，我自己没有这样做过。对我来说，这种方法的好处是它补充了中央 LDAP 系统和用户帐户的中央管理，因为它允许用户轻松更新他的软件包以包含他的 .vimrc 文件，例如，无需使用 puppet 等工具来管理该文件，因为用户可能无法访问这些文件。

Answer