我今天正在和一个合作伙伴合作，我需要使用scp将file upload到我的服务器。 我在服务器的SSHconfiguration中closures了密码，所以我希望他们使用公钥authentication。 我在服务器上为它们生成了密钥对，并给了它们私钥并将公钥放在适当的authorized_keys文件中。
在他们解决了一堆问题之后，他们终于find了一个更有经验的系统pipe理员，他责备我这样处理关键的一代。 他说，通过给他们一个在我的系统上生成的私钥，我使他们能够对在同一台服务器上生成的其他密钥进行暴力攻击。
我甚至问他： “所以如果我有一个服务器上的帐户，我可以用密码login，但我想自动化一些东西，我在该系统上生成一个密钥对，然后给我一个强制其他的攻击媒介用户的密钥？“ 他说是的
我从来没有听说过，这是真的吗？ 任何人都可以指出我对这次袭击的讨论吗？
呃…不，在大多数情况下，这是不正确的，因为在系统上产生适当的随机性。 然而，如果开发者（在Linux的情况下，内核开发者）不注意确保随机性源是“好的”，则服务器在理论上可能产生具有偏差的随机性。 如果随机性存在偏差，则可以在服务器密钥上以快于暴力的时间执行攻击。 然而，这比理论上的问题要复杂得多 – 在实践中，RNG（随机数生成器）的弱点比对encryption软件的旁路攻击或访问服务器a的可能性要小得多不同的方式。
所以，长话短说，不，他是不正确的。 除了基本的encryption基础（默认生成DSA密钥RSA？）之外，一个ssh密钥不包含有关在同一系统上生成的任何其他ssh密钥的任何信息。
私钥的要点是对用户是私密的，只有用户才知道。 作为一个用户，我不希望其他人生成我的私钥，因为这意味着别人有权访问我的私钥，因此有机会采取行动，如果他们是在我的系统上，公钥的一半被设置为有效的证书。
从你的PoV你也有更多的责任。 您不仅需要保持系统安全，以便不恰当的公钥不能安装到位，而且还有责任保证您生成的私钥在整个生命周期中安全无虞。 如果使用给定的密钥对进行不合需要的操作作为authentication，并且用户知道其他人已经（或已经）有密钥的副本或密钥以不完全安全的方式被运输，则他们可以转身（正确地错误地），并说他们保持他们的副本完全安全，所以它必须是你的副本，在你的最后或运输中妥协。 这可能听起来像屁股覆盖，这是因为它是：从您的PoV和用户，因为你要确保谁负责正确标记。
所以，不pipe你的专家提出的问题是否有效（根据我的理解，这样的攻击在理论上是可能的，但据我所知，在下一代或几乎没有实际可行的情况下，除非在math或一般实施中出现新的严重漏洞发现（这是不太可能的）），无论是当戴着我的用户帽子，当我戴着我的pipe理员帽子，我更喜欢用户完全控制他们的私钥和pipe理员（当然还有地球上的其他人）允许在他们附近
即使你不同意以上的规定，关键的运输问题也不是一件容易的事情：你怎么可以100％确定私钥已经被有意的用户看到，而只有有意的用户并没有被存储（有意或无意）以不太安全的方式（例如留在电子邮件收件箱或临时文件中，使其从所述邮件中分离出来并且未encryption）。 如果您使用安全的传输方法，要求用户进行身份validation，那么如何安全地向用户获取该系统的身份validation详细信息？ 当然有许多方法可以使关键的运输事项“足够安全”（其中“足够”非常依赖于钥匙给予人们访问的东西），但是如果用户产生钥匙并分配公共部分，那么你在这个意义上来说，没有一个关键的分配问题需要担心（你只需要担心用户保持私人部分的安全，但没有什么能阻止一个真正的粗心的用户在那里不安全，所以这是一个问题无论你做什么）。
最后一个注意事项：如果你的私钥全部在同一个地方生成，那么这个问题可能是一个问题，就是如果这个地方后来发现有一个坏的密钥生成设置，就像去年在Debian / Lenny的OpenSSL包中发现的问题一样。 在这种情况下，你将有一个工作的工作撤销和重新生成大量的私钥。 这可能是外部专家对此事的关注的一部分。
我很确定这是BS。 私人应该随机生成。 所以只要这种随机性没有偏见，不同私钥之间就不可能有联系。
随机种子通常来自/ dev / random 。 除非你以某种方式改变了ssh-keygen来使用另一个随机种子（你会知道如果你是这样做的），那么任何人都不可能对这个键进行反击，以便找出如何生成一个新的键来破解你的系统。