服务器管理员给我发送了一个要使用的私钥。为什么?

Tob*_*oby 75 security ssh administration key-authentication

我应该访问服务器,以便将公司的临时服务器和实时服务器链接到我们的部署循环中。他们这边的管理员设置了两个实例,然后在服务器上创建了一个用户,供我们通过 SSH 登录。我已经习惯了这么多。

在我看来,现在会发生的是我将我的公钥发送给他们,该公钥可以放在他们的授权密钥文件夹中。然而,他们通过电子邮件向我发送了一个文件名id_rsa,该文件名包含-----BEGIN RSA PRIVATE KEY-----在文件中。这是正常的吗?

我环顾四周,可以找到大量关于从头开始生成和设置我自己的密钥的资源,但没有服务器的私钥开始。我应该使用它为自己生成一些密钥还是?

我会直接问系统管理员,但不想显得白痴,浪费我们中间的每个人的时间。我是否应该忽略他发给我的密钥并要求他们将我的公钥放在他们的授权文件夹中?

Wil*_*ard 115

在我看来,现在会发生的是我将我的公钥发送给他们,该公钥可以放在他们的授权密钥文件夹中。

现在应该发生的事情“在你的脑海中”是正确的。

电子邮件不是安全的通信渠道,因此从适当安全的角度来看,您(和他们)应该考虑私钥已泄露。

根据您的技术技能和您想成为的外交家,您可以做几种不同的事情。我会推荐以下之一:

  1. 生成您自己的密钥对并将公钥附加到您发送给他们的电子邮件中,内容如下:

    谢谢!由于电子邮件不是私钥的安全分发方法,您能否将我的公钥放在适当的位置?它附上了。

  2. 感谢他们并询问他们是否反对您安装自己的密钥对,因为他们发送的私钥在通过电子邮件发送后应被视为已泄露。

    生成您自己的密钥对,使用他们第一次发送给您的密钥登录,并使用该访问权限编辑authorized_keys文件以包含新的公钥(并删除与泄露私钥对应的公钥。)

一句话:你不会看起来像个白痴。 但是,很容易让另一个管理员看起来像个白痴。良好的外交可以避免这种情况。


编辑回应来自 MontyHarder 的评论:

我建议的行动方案都没有涉及“在不告诉其他管理员他做错了什么的情况下修复问题”;我只是巧妙地做到了,没有把他扔到公共汽车下面。

不过,我会补充一点,我会跟进(礼貌),如果细微的线索不拾起:

您好,我看到您没有回复我关于电子邮件是不安全渠道的评论。我确实想确信这种情况不会再次发生:

你明白我为什么要强调私钥的安全处理吗?

最好的事物,

托比

  • 并不是说另一个管理员“可以看起来像个白痴”。那是另一个管理员做了一些愚蠢的事情。我只能想到一种情况,在这种情况下,应该在机器之间共享私钥,那就是通过相同的名称(循环 DNS 解析等)访问服务器池并且必须提供相同的 SSH 主机密钥,以便自动化流程将接受他们就是那个名字。在这种情况下,同一个人将成为所有服务器的管理员,并在没有外部参与的情况下处理传输。 (27认同)
  • @zwol 在我的工作中,我们有一种“不责备”的理念,即理解我们会犯错,但将不犯两次同样的错误列为重中之重。但是为了不犯两次同样的错误,你必须知道这是一个错误,这就是为什么我不能对建议 OP 只是修复问题的答案进行投票,而不告诉其他管理员他做错了什么。我选择将_错误_称为“白痴”,而不是因为您概述的原因而准确地称呼管理员名称。(但我不确定你的结论括号是否表达了有意义的区别。) (21认同)
  • +1 最佳答案。我要补充一点:要特别小心,因为这个系统管理员已被证明是无能的。最好在*何时*(而不是*如果*)后盖住你的后背,他/她会永远搞砸服务器。 (9认同)
  • @LightnessRacesinOrbit,我怀疑您可能对“外交”的含义没有完全理解。你有没有试过在一本好的词典里把它清理干净,比如韦伯斯特第三新国际词典? (8认同)
  • 谢谢。我使用了一些微妙的措辞,并发送了我的公钥。一切看起来都已解决,但我现在将取消他发给我的密钥的授权。 (2认同)
  • 这是一个愚蠢的错误,但这是每个人都犯过一次(希望永远不会再犯)的那种愚蠢错误。这并不意味着另一个系统管理员是白痴。(如果你指出错误并且他们坚持他们没有做错任何事情,那么可以得出结论说他们不知道如何做他们的工作是公平的。但这仍然与白痴不一样...... .) (2认同)
  • 另请注意,根据您的威胁模型,您可能必须考虑这样一个事实,即电子邮件可能被中间人攻击并且附加的公钥被篡改。 (2认同)

Dmi*_*yev 33

我是否应该忽略他发给我的密钥并要求他们将我的公钥放在他们的授权文件夹中?

是的,这正是你应该做的。私钥的全部意义在于它们是私有的,这意味着只有您拥有您的私钥。由于您从管理员那里收到了该密钥,因此他也拥有它。所以他可以随时冒充你。

密钥是否通过安全通道发送给您无关紧要:即使您亲自收到了您的私钥,也不会改变任何事情。虽然我同意通过电子邮件发送敏感的加密密钥是蛋糕上的樱桃的评论:您的管理员甚至不会假装有某种安全策略到位。

  • 而且由于 OP 无法知道管理员的机器有多安全(从故事来看,大概非常不安全),他应该假设私钥也(或将要)泄露给其他人。通过电子邮件发送私钥只是信息安全无知的一个额外事实。 (6认同)
  • @MaxRied 我指的是`/var/log/secure` 或[类似](http://xkcd.com/838/),我很确定空间技巧不会骗过这个。 (4认同)
  • @MaxRied 如果有适当的安全日志,这可能很难做到。有了你的私钥,他甚至不需要模拟日志。这就像拥有重置密码的能力与知道密码的能力。 (3认同)

小智 14

在我看来,管理员似乎为您生成了一个私钥/公钥对,将公钥添加到了 authorized_keys 并将私钥发送给您。这样,您只需将此私钥用于与服务器的 ssh 会话。无需自己生成密钥对或向管理员发送公钥到您可能损坏的(总是认为最坏的情况:P)私钥。

但是,我不会相信通过未加密邮件发送给您的私钥。

我的方法是:使用私钥登录一次,将您自己的公钥添加到服务器上的authorized_keys(替换原始公钥)并丢弃此电子邮件私钥。然后,您可以感谢管理员,他/她/它为您提供了私钥,但您不希望此类信息/密钥不要通过电子邮件发送(/根本不发送)。

  • @kasperd *我*可以想象的原因是一个过度劳累的系统管理员,他认为通过电子邮件发送私钥的风险被试图向不太懂技术的用户解释如何正确生成密钥对的麻烦以及将公钥发回。 (19认同)
  • @mattdm 那……完全合乎逻辑,但又令人恐惧。一个无法生成密钥对并将公钥发送给我的人可能不会用我给他的私钥做得更好。 (4认同)
  • @Toby 我可以想象他们发送私钥的唯一原因是他们不了解他们正在使用的工具。您可以在命令行上使用 `-i` 来选择要使用的私钥。 (3认同)