sch*_*azi 7 ssh brute-force-attacks public-key
我今天和一个合作伙伴一起工作，我需要使用scp. 我在服务器的 SSH 配置中关闭了密码，所以我希望他们使用公钥身份验证。我在服务器上为他们生成了密钥对，并给了他们私钥并将公钥放在适当的authorized_keys文件中。
在他们设置工作遇到了一系列问题之后，他们终于让一个更有经验的系统管理员参与进来，他责骂我以这种方式处理密钥生成。他说，通过给他们一个在我的系统上生成的私钥，我使他们能够对同一台服务器上生成的其他密钥进行暴力攻击。
我什至问他“所以如果我在服务器上有一个帐户，我可以用密码登录，但我想自动化一些东西，我在那个系统上生成一个密钥对，那么这是否会给我一个攻击向量来强制其他人用户的钥匙？” 他说是的。
我从来没有听说过这个，是真的吗？任何人都可以指出我对这次攻击的讨论吗？
嗯...不，由于系统上适当的随机性生成，这在绝大多数情况下都是不正确的。但是，如果开发人员（在 Linux 的情况下，内核开发人员）不注意确保随机性源“良好”，则理论上服务器可能会产生具有偏差的随机性。如果随机性存在偏差，则可以在比蛮力更快的时间内对服务器密钥执行攻击。然而，这更像是一个理论问题而不是实际问题——在实践中，RNG（随机数生成器）的弱点比对加密软件的旁道攻击或获得对服务器的访问权限的攻击可能性要小得多不同的方式。
所以，长话短说，不，他是不正确的。除了基本的加密基础（DSA 密钥是否默认生成？RSA？），一个 ssh 密钥不包含有关在同一系统上生成的任何其他 ssh 密钥的任何信息。
私钥的要点是它对用户是私有的，并且只有用户知道。作为用户，我不希望其他人生成我的私钥，因为这意味着其他人可以访问我的私钥，因此有机会采取行动，如果他们是我在将该密钥的公共部分设置为有效凭据的系统上。
从你的 PoV，你也有更多的责任。您不仅需要确保系统安全，以免将不适当的公钥安装到某个地方，而且您有责任在整个生命周期中确保您生成的私钥安全。如果使用给定的密钥对作为身份验证采取了不受欢迎的操作，并且用户知道其他人拥有（或拥有）密钥的副本，或者密钥以不太安全的方式传输，那么他们可以转身（正确或错误地）并说他们将他们的副本完全安全地保存着，因此必须是您的副本在您的最终或运输过程中受到损害。这听起来可能只是屁股覆盖，这是因为它是：来自您的 PoV 和用户，因为您正在确保谁对正确标记的内容负责。
因此，无论您的专家提出的担忧是否有效（根据我的理解，此类攻击在理论上是可能的，但据我所知，在下一代中几乎无法实现或几乎没有实现，除非数学或一般实现中出现新的严重漏洞发现（这有点不太可能）），无论是戴着我的用户帽子还是戴着我的管理员帽子，我都希望用户完全控制他们的私钥和管理员（当然还有地球上的其他人）允许在他们附近的任何地方。
即使您不同意上述观点，密钥传输问题也远非微不足道：您怎么能 100% 确定私钥已被预期用户看到并且只有预期用户看到并且没有被存储（有意或无意）以不太安全的方式（例如留在电子邮件收件箱或临时文件中，因为它与所述邮件分离并未加密）。如果您使用要求用户进行身份验证的安全传输方法，您如何获取身份验证详细信息？是系统安全地给用户？对于大多数用途，当然有一些方法可以使密钥传输“足够安全”（其中“足够”很大程度上取决于密钥让人们访问什么），但是如果用户生成他们的密钥并分发公共部分，那么你从这个意义上讲，根本不需要担心密钥分发问题（您只需要担心用户保持私有部分的安全，但是没有什么可以阻止真正粗心的用户在那里不安全，所以这是一个问题无论你做什么）。
最后一个注意事项：如果您的私钥都在同一个地方生成，那么可能会出现问题的一件事是，如果后来发现该地方的密钥生成设置不正确，就像去年在 Debian/Lenny 的 OpenSSL 软件包中发现的问题一样. 在这种情况下，您将有一项工作来撤销和重新生成许多私钥。这可能是您的外部专家对此事的关注的一部分。