从服务器管理员接收私钥：确定吗？

我要访问远程SFTP服务器。管理员为我创建了一个用户，并为我生成了一个公共/专用密钥对。然后，他安全地向我发送了私钥文件，我将其用于身份验证。我认为这样做不好，我应该成为生成密钥对并将其提供给他的人。但是，如果我仅使用此密钥登录该服务器，而没有其他服务器，则无法想到有什么不好的原因。有什么原因吗？

authentication ssh-keys private-key

— 马修斯
source

安全卫生差，一个。服务器管理员应该了解得更多，并且不应“培训”用户以期望从外部来源获取私钥。

— wmorrell '16

他还给谁呢？始终认为，可能发生的最坏情况是什么？

— mckenzm

我实际上并不认为那有那么糟。下面有一个类似的例子（Eric Towers），为用户提供了一个“初始密码”，然后需要立即更改它。从个人经验来看，第100次向用户解释什么键可能有点乏味-管理员仍然是人类。将私钥提供给您是懒惰的-是的，但是没有什么可以阻止您自己替换它。从本质上讲，在他/她将其发送给您之后，您无需再次打扰sysadmin（除非他们选择关闭文件的写许可权……然后让他们烦恼）。

— 雷

@matthiash这个问题适合该站点，但是，就像FYI一样，还有一个信息安全站点可以解决其他安全问题。

— topher

我还要指出的是，AWS也是如此。创建实例时，不将公钥上传到该实例，则会为您生成一个密钥对，并下载私钥。

— GnP '16

Answers:

就像您说的那样：公钥认证的整个概念是，私有密钥仅应为所有者所知，而相应的公钥则可以被广泛传播。身份验证的安全性取决于私钥的安全性，而不取决于公钥的安全性。

别人为您提供私钥的事实会自动使其遭到破坏。（您不知道该其他管理员是否仍然具有可用于模拟您的副本。）

— 鲁比恩
source

让我们假设最好的服务器管理员，并假设生成新的密钥对会更好，因为他不相信用户没有统一的私钥。也许服务器管理员认为，用户的私钥很旧，并且多年来受到损害。与U2F相同，联盟或供应商不信任用户生成密钥，这就是U2F设备随附预创建密钥的原因！

— cornelinux

管理员应帮助用户生成并保护私钥。

— Alex

你完全正确。但是通常管理员比计算机对人类更好，-）

— cornelinux

管理员仍然可以冒充您。

— user253751 '16

我认为您正在将一个狭窄示例的理论实践与现实和更大范围相混淆。无论如何，您必须信任管理员，因为他可以控制系统，并且可以避免完全使用密钥。给出私钥在现实世界中会发生，因为最终用户要么不知道如何制作密钥，要么不知道如何安全地制作密钥。

— JamesRyan

对于该密钥，组织没有不可否认性。IE，如果有人使用“您的”键对该系统进行了侮辱性或破坏性的操作，则管理员不能将责任全部归咎于您。因为把它交给你的人也有钥匙。它可能对您来说并不坏，因为它可以为您提供防御，但如果发生了任何不好的事情，对于控制服务器的组织来说将是可怕的。

您可能可以使用提供的密钥中的写入特权，以更新授权的密钥，添加密钥，以及删除提供的密钥。

— Zoredache
source

实际上，管理员可能期望用户在首次使用时更改其密钥，就像管理生成的第一密码一样。

— 埃里克·塔

正如一位伟人曾经说过的，“期待”。首次使用更改通常对于密码来说是必需的，但对于公钥加密则从来没有必要-这就是重点。

— womble

@EricTowers是，即使可能需要与当代SFTP（甚至SSH，除非你愿意凑齐一起的东西你自己）的实现？

— CVn

这个答案给人的印象是，通过sftp进行的操作已在某处的日志中签名，并由该密钥端到端保护。事实并非如此，管理员甚至可以在不使用密钥的情况下篡改操作或日志。

— JamesRyan

@marcelm：我之所以说“经常是必要的”，而不是“总是在所有情况下绝对是强制性的，没有例外”，是有原因的。实际上，作为确实定期请求（并接受）密码哈希和公钥的人，我知道，比起公钥，要有人提供散列密码（带有安全盐和所有内容）的障碍要大得多。如果您具有SSH客户端，则您具有密钥生成工具。能够以crypt许多有趣的形式呼唤（2）的事物不能说相同的话。

— womble