拥有一个每 90 天使 SSH 密钥过期的系统

Question

我有一个客户，由于他们对 GDPR 的解释，现在要求我们每 90 天更改一次密码。对于我们为他们开发的基于 Web 的系统来说，这很好，因为我们可以实施这些规则。但它们也要求我们更改用于访问服务器的 SSH 密钥的密码，这并不好。

1. 是否可以更改现有 SSH 密钥的密码？

2. 如果没有，我们可以使用任何工具来处理这个问题吗？我在想：

   一种。创建新密钥。
   湾 将所有公钥分发到现有服务器。
   C。删除现有的公钥。
   d. 存档旧私钥。

   我已经在这里阅读了一些关于 Puppet 的帖子，但据我所知，他们的目的只是解决在服务器之间分发公钥而不是每 n 天创建新密钥的问题？我应该进一步研究 Puppet 吗？

3. 在密码保留和 ssh 密钥方面，社区标准是什么？你怎么做呢？

Answer 1

客户在这里错了，不明白他们在说什么。更改私钥的密码是一个非常糟糕的主意，因为它具有非常违反直觉的安全属性。

通常，用户认为他们已更改的密码“不再是秘密”。它们可能成为低价值网站的一次性密码、在线句柄/昵称、笑话的妙语等，任何写有它们的纸张都可能成为暴露的废料。

对于用于加密私钥的密码，它不是这样工作的！密码必须永远保密，除非与密钥关联的所有权限都已被撤销（以下内容不适用于 ssh 密钥，但如果密码不仅用于签名，还用于接收私人消息，则永远真的意味着永远）。这是因为加密的私钥文件可能已被攻击者获取或存储在将来可能被攻击者获取的某处（如备份中）。如果密码被泄露，那么它就会被泄露。

从某种意义上说，在其生命周期中经历了 N 个密码短语的私钥是安全的 1/N，因为如果攻击者可以访问加密的私钥文件，那么知道任何一个过去的密码短语就足以破坏密钥.

现在，回到你的问题。

如果客户没有抓住这个“ssh 密码”的误解并深入研究它，那么正确的做法就是永远不要向他们提出这个问题，并遵循自己处理密钥的最佳实践。但是现在他们已经做到了，您可能必须做一些事情来满足他们。您可以尝试解释加密私钥的密码短语如何与密码具有不同的安全属性，但考虑到客户对这里很多事情的错误程度（密码过期通常是一个坏主意），我怀疑这是否可行。

这留给您自动化分发新密钥的系统的任务。我强烈建议您不要自动化集中生成新密钥的系统，因为永远不应在机器之间移动私钥。相反，你应该有流程/提醒/脚本，让你这边的员工/承包商可以轻松地生成新的私钥并发布相应的公钥，并拥有公钥分发系统（Puppet 或其他）您使用将这些推送到他们需要访问的系统。

此外：可能说服客户放弃这一点的一件事是，从根本上没有办法强制新私钥具有与旧私钥不同的密码，甚至根本没有密码。

Answer 2

第一个问题的答案：“是否可以更改现有 SSH 密钥的密码？” 是是的。使用 openssh 就这么简单ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

问题是密码在私钥文件中/上，这是一种不支持到期日期的简单格式。ssh 中基于密钥的身份验证概念的很大一部分是私钥不是集中管理的，它应该只存在于用户的工作站上，这使得对私钥强制执行密码过期策略几乎是不可能的。

取而代之的是：在密码策略针对用户帐户对象而不是用于访问所述帐户的方法之前，我所在的每个环境中。当密码过期或帐户锁定时，所有访问方法都会被锁定，包括 ssh 密钥。

当您需要更高的帐户安全性时，添加多因素身份验证。

但我很好奇其他人做了什么来解决您的合理担忧。

Answer 3

一种可能足够也可能不够的可能性是使用 SSH 用户 CA，它允许您设置签名密钥的生命周期。无论您对密钥签名进行何种自动化处理，都可能会拒绝签名超过 90 天。然后，将您的用户 CA 的公钥添加到 /etc/ssh/sshd_config 中的 TrustedUserCAKeys 并将 AuthorizedKeysFile 设置为 none。

Answer 4

使用AuthorizedKeysCommand可以在服务器端实现一些到期机制。从简单的检查文件时间戳到更复杂的事情。