多用户、多服务器、SSH 密钥管理

多用户、多服务器、SSH 密钥管理

情况如下。

我有 5000 台服务器,分为 100 个“组”。
每个“组”有 1 个 SSH 密钥对,允许访问组中的任何服务器。我有 60 个用户(有些是人类,有些不是)需要访问所有 5000 台服务器。这些用户都在不同的计算机上,有些是 PC(putty),有些是 Linux(ssh)。

手动:将新服务器添加到“组”似乎很简单。添加/更新用户将是一场噩梦。添加/更新新组将是一场噩梦。将组密钥同步到用户站将是一场噩梦。

ssh-agent/pageant 适用于单个用户、单个工作站,但似乎不可扩展。

是否有软件可以处理这种管理?也许是某种代理?或者基于自动服务器的密钥检索协议?

编辑

我感谢迄今为止所得到的帮助,但我认为我没有表达清楚或者没有理解这些建议。

更多信息:每台服务器都是远程系统,无法访问互联网,连接速度通常很慢。每台服务器在其 authorized_keys 文件中只有一个条目。我不需要或不需要单独的用户密钥。我只希望许多不同的人对每个组使用相同的密钥。现在我们正在使用密码身份验证,并在一张纸上保存每个组的密码列表。这对我们的团队有用。但是如果我们切换到基于密钥的身份验证,它将不起作用。

这些建议还有意义吗?如果有意义,您能否更具体地说明实施细节。

答案1

除了它将自己的密钥放到服务器上之外,我还需要它使用我提供的密钥。

有几个人向我提出过​​这个要求。我在最新版本中添加了一种指定密钥对的方法。

https://github.com/skavanagh/KeyBox/releases

https://github.com/skavanagh/KeyBox#supplying-a-custom-ssh-key-pair

如果您有任何问题请告诉我。谢谢!

答案2

查看用户化,管理用户帐户、SSH 密钥和 sudo 角色,并且不需要可能发生故障的中央目录服务器(将您锁定在所有实例之外.. 曾经有过这种情况。)

使用 AWS 的用户数据(在实例启动的高级选项卡下)进行部署非常容易,或者将其粘贴在自动扩展组的用户数据脚本中,或者在您手动启动实例时使用,这非常棒,因为它在您登录之前就可以工作。(或者您可以将单行代码粘贴到您的服务器控制台中,但这并不那么有趣......)

它支持 Chef、Puppet、Ansible、CloudFormation/CloudInit 和 TerraForm 进行部署,并且每个用户(开发人员/管理员/等)都可以获得自己的 Web 登录名来更新多个密钥(只需粘贴)。界面不错,非常轻松。

对于您的特定需求(即,通过断开连接/慢速网络连接将大量服务器分成单个组),我将使用自托管的 Userify Express,并将轮询时间设置得非常高(至少 90 秒),并创建虚假(非人类)用户——每个组一个。当然,您可以只使用真实的人类用户帐户,因为您只需在 Userify 中单击一下即可从一大组服务器或所有服务器中删除人类用户,然后用户自己只需更新密钥箱即可分发自己的密钥。Userify 只需要从服务器到您的 Userify 服务器的 https 访问(443 TCP)。

(尽管您可以像这样共享密钥,但让人类拥有自己的密钥更安全;将人类用户与个人帐户访问权限分离会破坏终端服务器上的日志记录和审计,尽管这听起来不像是一个问题,但大多数安全策略框架(如 HIPAA 和 PCI)都要求每个个人帐户访问权限只有一个人类用户,并禁止共享凭证。尽管如此,您可以在 Userify 中执行此操作,甚至将私钥分发给服务器组,但除了服务/系统/自动化帐户(如备份或配置管理系统(如 Ansible))外,不建议使用该方法。)(免责声明:我在 Userify 工作并帮助设计了原始的 Userify 模型。)

答案3

您可以考虑使用带有公钥的 LDAPhttp://code.google.com/p/openssh-lpk/

如果密钥被泄露,那么重新向用户发放密钥将变得容易得多。每个用户的私钥都可以由该用户管理,也可以保存到只有他们才能访问的存储中(例如主目录)。

答案4

似乎钥匙扣非常适合您的需求。

来自维基页面

Keyholder 是一组脚本,允许一组用户使用 SSH 密钥,而无需与组成员共享私钥。这是通过运行 ssh-agent 的锁定实例并在其前面运行 ssh-agent-proxy 来实现的。

一旦运行并配置了 ssh-agent-proxy,用户就可以通过设置SSH_AUTH_SOCK指向代理的套接字来进行身份验证,然后ssh-agent-proxy只允许用户使用根据其本地 unix 组成员身份授权使用的密钥进行身份验证。

配置如下:

---
group-name: ["ssh:key:fingerprint"]

并且密钥是单独存储的,只有root可以访问。

在服务器重新启动后,具有 root 权限的人员必须“武装”密钥持有者服务,然后具有适当组成员身份的任何人都可以使用存储在密钥持有者 ssh_agent 中的密钥。

更新:

自从我最初写下这个答案以来,keyholder 已经从 Wikimedia puppet 存储库中提取出来,并经过适当的处理,成为一个独立的项目。现在应该更容易使用,尤其是对于 debian 用户来说,因为 debian 打包脚本和元数据包含在一个单独的分支源存储库

相关内容