我有一个客户，由于他们对 GDPR 的解释，现在要求我们每 90 天更改一次密码。这对于我们为他们开发的基于 Web 的系统来说没问题，因为我们可以实施这些规则。但他们还要求我们更改用于访问服务器的 SSH 密钥的密码，这很不妥。
- 是否可以更改现有 SSH 密钥的密码？
如果没有，我们可以使用什么工具来处理这个问题？我在想：
a. 创建新密钥。b
. 将所有公钥分发给现有服务器。c
. 删除现有公钥。d
. 存档旧私钥。我在这里读过一些关于 Puppet 的帖子，但据我了解，它们的目的只是解决在服务器之间分发公钥的问题，而不是每隔 n 天创建新密钥？我是否应该进一步研究 Puppet？
在密码保留和 ssh 密钥方面，社区标准是什么？您是如何做到的？
答案1
客户错了，不明白他们在说什么。更改私钥上的密码是一种很坏想法，因为它具有非常违反直觉的安全特性。
通常，用户认为更改后的密码“不再是秘密”。它们可能会成为低价值网站、在线昵称、笑话的妙语等的一次性密码，而写有这些密码的任何纸张都可能成为暴露的废品。
对于用于加密私钥的密码，事情不是这样的！密码必须保密永远除非与密钥相关的所有特权都已被撤销（以下内容不适用于 ssh 密钥，但如果密码不仅用于签名，还用于接收私人消息，那么永远真的意味着永远)。这是因为加密的私钥文件可能已被攻击者获取或存储在某个地方（例如备份中），攻击者将来可能会获取该文件。如果密码被泄露，则该文件会被泄露。
从某种意义上说，一个在其生命周期内经历了 N 次密码的私钥的安全性是 1/N，因为知道以下任何人如果攻击者有权访问加密的私钥文件，过去的密码足以泄露密钥。
现在回到你的问题。
如果客户没有抓住这个“ssh 密码”的误解并深陷其中，正确的做法就是永远不要向他们提起这件事，自己遵循密钥处理的最佳实践。但是既然他们已经提起了，你可能必须做些什么来让他们满意。你可以试着解释加密私钥的密码短语与密码的安全属性有何不同，但考虑到客户在这里对很多事情的看法是多么错误（密码过期通常是一个坏主意），我怀疑这不会起作用。
剩下的任务就是让系统自动化，以便分发新密钥。我会强烈反对你不能集中自动化生成新密钥的系统，因为私钥不应该在机器之间移动相反，您应该有流程/提醒/脚本，以便您这边需要访问权限的员工/承包商可以轻松生成新的私钥并发布相应的公钥，并让您使用的公钥分发系统（Puppet 或其他）将这些推送到他们需要访问的系统。
此外：可能说服客户放弃这一点的一件事是提到从根本上没有办法强制要求新私钥具有与旧私钥不同的密码，甚至根本没有密码。
答案2
第一个问题的答案：“是否可以更改现有 SSH 密钥的密码？”是。使用 openssh 非常简单ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
问题在于密码位于私钥文件中，这是一种不支持到期日期的简单格式。此外，ssh 中基于密钥的身份验证概念的很大一部分是私钥不是集中管理的，它应该只存在于用户的工作站上，这使得在私钥上强制执行密码到期策略几乎不可能。
相反：在我之前所处的每个环境中，密码策略都针对用户帐户对象，而不是针对用于访问该帐户的方法。当密码过期或帐户被锁定时，所有访问方法都会被锁定，包括 ssh 密钥。
当您需要提高帐户安全性时，请添加多因素身份验证。
但我很好奇其他人是如何解决您的合理担忧的。
答案3
一种可能或可能不够的方法是使用 SSH 用户 CA，它允许您设置签名密钥的有效期。无论您在密钥签名周围设置什么自动化功能，都可以拒绝签名超过 90 天。然后，将您的用户 CA 的公钥添加到 /etc/ssh/sshd_config 中的 TrustedUserCAKeys 并将 AuthorizedKeysFile 设置为 none。
答案4
你可以使用类似的工具Hashicorp 的 Vault 用于创建短期签名的 SSH 密钥。每个用户每天（或大约）都会收到一个新密钥。您可以使用您目前使用的任何服务器（例如 LDAP 服务器）向 Vault 进行身份验证以获取证书。
设置这个的工作量并不大，但根据我的经验，比@Mark在他的评论中提到的要大。你基本上是用一个问题（无知的客户要求）代替另一个问题（分片管理）。
但它确实支持其他一些场景，例如轻松生成内部 X509 证书以及在文本文件中管理数据库密码和应用程序机密。您可以判断工作量和投资回报率。
还要注意的是，开源版本没有 DR 功能（它拥有其他所有功能）。