我建议您采用“每个用户一个 ssh 密钥”模型。它易于最终用户使用，向用户解释简单，并且很可能满足安全要求。

易用性非常重要。如果安全机制太难使用，人们会想办法绕过你的安全机制。一个好用的、相当好的安全机制，远胜于一个难用的、理论上高度安全的安全机制（因为在实践中，如果不好用，它可能就没有你那么安全了）期望人们找到绕过安全机制的方法，以便他们可以完成工作）。

我认为“每个用户的客户端计算机一个 ssh 密钥”是个坏主意。这听起来像一团糟。坦率地说，这听起来像是 IT 失控，以某种方式给安全带来了坏名声，让人们讨厌 IT 部门。你的意思是我必须为每个客户端生成一个单独的 SSH 密钥，并管理它们？一切都是为了一个不明确的安全利益？啊! 我不想负责把这个卖给用户。

我建议从“合规预算”的角度考虑这些决定。您的员工将忍受一定数量的令人讨厌的合规要求（例如，安全要求）强加给他们。在某种程度上，他们将遵循这些任务。然而，如果它变得太多，最终他们会感到恼火，并且只会做任何他们必须做的事情来完成他们的工作，即使这违反了所有安全原则。因此，施加过多的要求或过多的不便可能会适得其反。因此，在对用户施加任何类型的安全要求或与安全相关的不便之前，请仔细考虑。想象一下，您在实施授权方面的预算非常有限。这是花费您有限的“合规预算”的最佳项目吗？

在相关的说明中，我认为“每个用户的客户端计算机一个 ssh 密钥”的好处非常小。我不明白为什么任何人都应该关心我可以用笔记本电脑登录的帐户，而不是我的台式机。这只是微观管理吗？谁在乎？是我，不管怎样。如果你相信我，你就相信我，不管我用的是哪台机器，对吧？我不清楚这是一件大事，以至于你会让你的用户生活得更难。

PS你提到了一些关于管理非人类拥有的特权的事情。我不太明白那指的是什么。您提到了调用 SSH/SCP 的脚本，但谁在调用这些脚本？如果是一个人，那么大概那个人正在授权该活动，对吧？如果它不是由人调用的，那么我什至不清楚它是如何工作的（根据我的经验，这样的脚本无法访问你的 SSH 私钥，因为它们不知道你的密码并且不是附加到任何允许他们访问您的 SSH 私钥的 ssh-agent 会话）。我不知道我是否遗漏了该声明中的重要内容。

我很难认为多对多方法的用户体验是可以接受的。试图记住哪个 pub/priv 密钥对与哪个系统相关的混乱似乎过于繁琐。

在管理和用户体验方面，一对多密钥方法的精神似乎是最好的。我说精神是因为我认为如果你的用户和系统数量非常少，管理部分很快就会变得困难。您正朝着集中式访问管理解决方案前进，那么为什么不一路走下去呢？设置一个 LDAP 服务器（AD/OpenLDAP/这个线程有一些想法），为您的用户定义角色，让这些角色访问他们需要的服务器/系统，并根据需要为用户分配角色。这使您可以通过简单的角色更改来配置/取消配置对许多系统的访问，并将所有审计日志保存在一个中央位置。

随着您的组织在数量和复杂性方面的增长，这是一个值得认真思考解决方案的可扩展性和实用性的好问题。