更新：更正了关于AuthorizedKeys文件权限的段落。如果您经常阅读此博客，您可能会使用名为SSH的小工具，尤其是它无处不在、最流行的OpenSSH实现。也许你足够聪明，只使用公钥/私钥，从而保护自己免受字典攻击。如果您这样做了，那么您知道为了配置对新主机的访问，您需要为该主机提供一个公用密钥的副本（通常通过将其写入磁盘）。如果您有许多主机，管理密钥可能会很痛苦，特别是当您需要更新其中一个密钥时。如果DNSSEC能帮忙呢？威廉·纽海塞尔（William Neuheisel）的CC BY 2.0图像OpenSSH的6.2版提供了一个特性，允许远程主机以自定义方式检索公钥，而不是~/.ssh/目录中的典型授权密钥文件。例如，您可以收集一组用户的密钥，这些用户需要访问单个服务器（例如，LDAP服务器）上的多台计算机，并让所有主机在需要尝试登录的用户的公钥时查询该服务器。这就节省了对每台主机上授权密钥文件的大量编辑。缺点是有必要信任这些主机从中检索公钥的源。私有网络上的LDAP服务器可能是值得信任的（如果得到适当的维护），但是对于运行在云中的主机，这并不实际。DNSSEC在这里很有用。没错：既然我们可以验证来自DNS服务器的响应，我们就可以在DNS记录中安全地存储公钥了！所以假设我们管理example.com网站想让Alice和Bob访问该域中的foo、bar和baz机器。我们将把它们各自的公钥存储在名为alice的TXT[1]记录中_pubkey.example.com网站还有鲍勃_pubkey.example.com网站. 完全准确地说，这些记录属于哪个区域并不重要，但我在这里考虑我们只有一个域。要求如下：这些机器需要运行OpenSSH服务器版本6.2或更高版本他们还需要一个DNSSEC验证解析器（我们将使用未绑定的主机）Alice和Bob的密钥长度必须少于256个字符（ECDSA或Ed25519密钥可以使用）DNSSEC需要在域上正确设置example.com网站（惊喜！）Alice和Bob生成的密钥如下：foo:~$ssh keygen-t ecdsa或者像这样：foo:~$ssh keygen-t ed25519然后按照说明操作。当然，它们将提供一个非空的密码短语。然后他们会给我们（或者管理区域文件的人示例.com)公钥文件，可能如下所示：ssh-ed25519 AAAAC3N…VY4A=爱丽丝@福我们可以去掉评论爱丽丝@福然后使用其余的值在域中创建一个名为alice_pubkey的TXT记录示例.com. 然后，检索密钥非常简单：foo:~$未绑定主机-t TXT alice_pubkey.example.com网站爱丽丝_pubkey.example.com网站有TXT记录"ssh-ed25519 aaaaaac3n…"使用-v，unbound host将显示签名是否已验证foo:~$未绑定主机-v-t TXT alice_pubkey.example.com网站爱丽丝_pubkey.example.com网站有TXT记录"ssh-ed25519 aaaaac…"（不安全）使用-D，它将实际检查签名：foo:~$未绑定主机-D-v-t TXT alice_pubkey.example.com网站爱丽丝_pubkey.example.com网站有TXT记录"ssh-ed25519 aaaaaac3n…"（安全）如果不存在记录，它将显示：foo:~$未绑定主机-D-v-t TXT charlie_pubkey.example.com网站查理_pubkey.example.com网站没有TXT记录（安全）请注意，由于NSEC，没有记录也被标为"安全"。让我们准备解析这个输出。sshd_config手册页显示sshd需要一个特定的用户来运行将检索公钥的程序。这是遵循特权分离的最佳实践。让我们将该用户命名为pubkeygrab，并在foo、bar和baz上创建一个帐户，只授予它工作所需的权限，而无需更多：foo:~$useradd-m-d/var/empty-s/sbin/nologin pubkeygrab然后创建脚本pubkeygrab.sh，并存储在每台机器上。显然，我们将确保只有root用户可以编辑它：foo:~$cat/usr/local/bin/pubkeygrab.sh#!/垃圾箱/垃圾箱用户=$1/usr/sbin/unbound host-v-D-t TXT${USER}_pubkey.example.com网站\\|/usr/bin/grep-v"无TXT记录"\\|/usr/bin/grep'（安全）$'\\|/usr/bin/sed's/*"\（.*\）"（安全）$/\1/'现在我确信很多读者会对这个shell脚本的风格或效率有什么看法，我只是这样写的，以强调需要采取的步骤：它检索一个TXT记录，如果该记录不存在，则不输出任何内容如果未绑定的主机尚未确认记录是否正确地由DNSSEC签名，则它不输出任何内容如果上面的操作成功，它将过滤掉文本，只返回公钥它不试图做任何复杂的事情，因为复杂性是安全的敌人（或者至少，这是我与一些人分享的观点）它可以处理多个记录我相信你会编写你自己的程序来完成上述任务。只是要确保它只在你想用的时候才起作用。确保至少在以下情况下不会返回任何内容是至关重要的：对应用户的记录不存在记录未签名或签名不正确根键的本地副本（/var/unbound/根.key，此处）已损坏。如果你发现更多的案例，你会得到额外的分数。既然您已经阅读了上面的警告，请在foo、bar和baz上的/etc/ssh/sshd_config中添加以下内容：授权密钥命令/usr/local/bin/pubkeygrab.shAuthorizedKeysCommander pubkeygrab重启sshd。检查用户alice和bob是否也存在于每台机器上。请注意，上述更改也将适用于所有现有用户。现在您可以转到您的CloudFlare帐户，选择域示例.com，并创建TXT记录alice_pubkey和bob_pubkey。将它们各自的公钥粘贴到值字段中。不久之后，爱丽丝和鲍勃就可以登录了。叫查理也试试。如果上面的方法适用于Alice和Bob，但是对于Charlie来说失败了，那么恭喜您，您已经将CloudFlare变成了SSH的PKI。如果删除TXT记录，Alice和Bob的访问权限应该被撤销，并且一旦TXT记录的TTL过期，他们将无法登录。但是，请注意，当pubkeygrab.sh为空，则sshd将还原为通常的AuthorizedKeysFile参数以查找公钥。如果Alice和Bob厚颜无耻，想在你删除他们的TXT记录后保留他们的访问权限，他们只需在禁止他们之前随时将他们的公钥复制到该文件中。如果您不想这样做，请确保AuthorizedKeysFile参数指向Alice和Bob无法写入的位置。我希望这能说明DNSSEC是多么有趣，我们很快就会有更多关于这个话题的新闻。是的，最好有一个专用的记录，而不是重载TXT记录。↩︎