我被要求尝试/探索的一项新事物是设置一台服务器，基本上可以让 200 到 300 人通过 ssh 连接到单个用户来运行任务。他们可能只需要每天执行一次或几次。问题是他们每个人都可以连接任意数量的设备。如果他们每个人都有 3 或 4 个设备拥有公共 ssh 密钥，我们可能会在 autorized_keys 文件中获取最多 1000 个密钥。考虑到它实际上只是一个文本文件，1000 个密钥可能会对性能造成影响。
有没有办法将密钥拉到数据库或其他东西中，而不是authorized_keys文件中？
出于好奇，对于 1000 个用户来说，这可能不是什么大问题，但它让我好奇，像 github 这样的人如何能够处理 500,000 个用户[电子邮件保护]用户。我知道我个人有 3 个不同的密钥与我的帐户相关联，并且我知道很多人有多个密钥。我不习惯这种规模的东西，所以真的很好奇。LDAP 是否能够高效地管理这些？或者甚至是某种 ssh 网关？
答案1
只有当您有超过 1,000,000 个条目时，您才真正需要一个数据库。每个键都非常小（甚至不到一千字节）。只要文件小于 20 兆字节，读取文件就很简单（我们这里说的是毫秒）。您更大的问题是负载平衡。如果您有数百个并发用户，那么您很快就会遇到资源问题。
您的用例（1000 个密钥）将产生大约 400 千字节的 ssh 密钥文件。没什么大不了的。我的蹩脚脚本花了 30 毫秒来读取该文件。将其解析时间增加一倍或三倍，这仍然不是什么大问题。
在读取文本文件成为问题之前，您将需要另一台服务器来处理负载。
在服务器领域，大是相对的。解析文本文件时，500,000 不算什么。例如，我的 id_rsa.pub 文件是 400 字节。一点也不大。将其乘以 500,000。我们得到 190 兆字节。这相对较大，但不是太大。我编写了一个简单的 NodeJS 脚本来读取 174 兆字节的文件，整个过程不到 2 秒。这是在普通（非服务器级）硬盘（7200 RPM）上，甚至不在 RAID 中。
SSH 不必每次都读取整个文件，并且文件可能会被缓存到内存中。无论哪种情况，对于像 SSH 访问这样的一次性过程来说，几秒钟的加载时间并不是什么大问题。
GitHub 的妙处在于用户实际上没有 SSH 访问权限。用户只能推送代码，无法直接连接到服务器。这当然是一个安全问题，但肯定也是一个性能问题。
我很确定像 github 这样的地方有几台服务器来处理负载。