![公共 SSH 密钥过多/过多](https://linux22.com/image/545103/%E5%85%AC%E5%85%B1%20SSH%20%E5%AF%86%E9%92%A5%E8%BF%87%E5%A4%9A%2F%E8%BF%87%E5%A4%9A.png)
我被要求尝试/探索的一项新事物是设置一台服务器,基本上可以让 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 这样的地方有几台服务器来处理负载。