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

28

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

是否可以更改现有SSH密钥上的密码？
如果没有，我们可以使用任何工具来处理此问题吗？我在想：

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

我在这里阅读了一些有关Puppet的帖子，但是据我了解，它们的目的只是解决在服务器之间分配公钥而不是每隔n天创建新密钥的问题。我应该进一步研究Puppet吗？
关于密码保留和ssh密钥，社区标准是什么？你怎么做呢？

puppet ssh-keys gdpr

— D先生
source

7

关于信息安全，似乎可以更好地讨论该主题。基本问题在那里已经有了答案。

— Gerald Schneider

31

GDPR实际上不需要这样做。如果有的话，GDPR要求您遵循最佳做法。今天的最佳做法是不要使密码过期。在20世纪初，强制密码到期是一种最佳做法，但是在GDPR提出之前就已经声名狼藉。

— MSalters

2

SSH可以使用证书，也许可以用来实现类似的目的？

— Edheldil

是的，就像@Edheldil所说的那样，请使用证书而不是原始密钥，因为您可以向它们添加到期日期。搜索有关此的netflix解决方案；他们共享了内部设置，在其中使用有效期为5分钟的证书进行ssh身份验证（这仅适用于身份验证，打开的连接保持打开状态）。

— Patrick Mevzek '18年

9

@GeraldSchneider，基本问题是“我的顾客是个白痴。我该如何用最少的精力为他们提供想要的东西？”。这是一个ServerFault问题，而不是InfoSec问题。

— 马克

35

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

通常，用户认为他们已将其更改为“不再秘密”的密码。它们可能会成为低价值网站，在线句柄/昵称，笑话打孔线等的一次性密码，并且任何在其上书写它们的纸张都可能成为暴露的废话。

对于用于加密私钥的密码短语，它不是这样工作的！除非已撤销与该密钥相关的所有特权，否则该密码短语必须永远保持秘密（并且以下内容不适用于ssh密钥，但是如果该密码短语用于的密钥不仅用于签名，还用于接收私人消息，则永远意味着永远）。这是因为存在这样的可能性，即加密的私钥文件已被攻击者获取或存储在将来可能被攻击者获取的某个位置（如备份中）。如果密码短语曾经被泄露，那么它就会被泄露。

从某种意义上说，在其生命周期内经过N个密码短语的私钥是安全的1 / N，因为如果攻击者可以访问加密的私钥文件，则对过去密码短语中任何一个的了解都足以危害密钥。。

现在，回到您的问题。

如果客户没有误解并误解“ ssh密码”，那么正确的做法就是永远不要向他们提出，并遵循最佳实践来自己处理密钥。但是，既然有了它们，您可能需要做一些事情才能满足他们。您可以尝试解释加密私钥的密码短语如何具有与密码不同的安全性，但是鉴于客户在这里的很多事情有多严重（密码过期通常是一个坏主意），我怀疑这种做法是否可行。

剩下的任务是使分配新密钥的系统自动化。我强烈不建议您使集中生成新密钥的系统自动化，因为绝不能在机器之间移动私钥。相反，您应该拥有流程/提醒/脚本，以使身边需要访问权限的员工/承包商可以生成新的私钥并发布相应的公钥，并使公钥分发系统（Puppet或其他方式）易于使用。您可以将它们推送到他们需要访问的系统。

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

— R ..
source

10

如上所述，执行此操作的正确方法是手动操作，向该客户收取人工费用可能具有足够的威慑力。

— 主教

3

向客户推销“不要这样做”的一种好方法是说“当然，员工更新密钥的过程必须包括绝对保证将永久删除旧密钥，以确保旧的公钥/私钥对不会落入错误的手。如果您不能保证这一点，那么我们将无法继续执行该计划。”

— Max Williams

19

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

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

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

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

但是我很好奇其他人为解决您的有效顾虑做了什么。

— 鲁比恩
source

6

同样，如果PW旋转是为了防止pw的盗窃/暴力破解，则密钥旋转应包括旋转密钥而不是旋转密钥，以防止密钥丢失/被盗。如果攻击者使用旧密码抓住了您的旧私钥，他们仍然可以进入

— BlueCacti

@BlueCacti尽管应该注意的是，如果原始密码/短语已经基于大量熵的选择过程，则强制密码轮换实际上是没有意义的。将一个可能花费一百万年的密码更改为蛮力来更改另一个可能花费相同数量的密码，实际上并没有任何改善。

— code_dredd

@code_dredd我不是在这里讨论密码轮换的使用。我也很反对。关于OP的问题，我只想指出，在这种情况下，旋转密钥比旋转密钥更有意义

— BlueCacti

@BlueCacti我只是在说几句话以补充您所说的内容。我什么都没讨论。

— code_dredd

2

+1用于多因素身份验证。然后使用众所周知的应用程序/插件生成代码。这样，您可以告诉客户密码每X秒更改一次。在这里包括链接作为可能的实现，而不是任何形式的认可。 digitalocean.com/community/tutorials/…–

— Philippe

6

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

— 丹布莱克
source

当您更改私钥上的密码时，公钥不会更改，是吗？那么，如何检查密码已更改？

— Edheldil

你不能如您所建议，私钥密码短语的更改对公钥的影响为零。他们甚至可以完全删除自己的密码。您只能检查整个公钥是否已更改。

— guzzijason

6

一种可能或可能不足的可能性是使用SSH用户CA，它允许您设置签名密钥的生存期。无论您采用哪种密钥签名自动化方式，都可以拒绝签名超过90天。然后，将您的用户CA的公钥添加到/ etc / ssh / sshd_config中的TrustedUserCAKeys，并将AuthorizedKeysFile设置为none。

— 标记
source

2

您可以使用Hashicorp的保险柜之类的工具来创建短暂的，签名的SSH密钥。每个用户每天都会（或如此）获得一个新密钥。您将使用今天使用的任何东西（例如LDAP服务器）向Vault进行身份验证以获取证书。

设置此功能的工作并不艰巨，但以我的经验，它的作用要大于@Mark在其评论中提到的内容。您基本上是用另一个问题（分片管理）替换一个问题（无端的客户要求）。

但是它确实支持其他一些情况，例如轻松生成内部X509证书以及管理数据库密码，文本文件中的应用程序机密。您可以判断工作量和投资回报率。

另请注意，开源版本不具有DR功能（它具有其他所有功能）。

— ixe013
source

1

您可以使用包含基于时间的一次性密码（TOTP）的密钥代理。现在，您的“密码”每分钟更改一次。

_{但是，这里的其他人都是对的：这很愚蠢。}

— 麦可
source