SSH 与 X.509 证书

作为开发人员或系统管理员，您可能习惯使用密钥对通过 SSH 连接到服务器。如果我告诉您有一种更好、更安全的方法来管理 SSH 访问，您会怎么想？想想 SSH 证书（不，它们与 TLS 证书不同）

对于大多数人来说，他们对证书的了解仅限于 X.509 数字证书格式（也称为 TLS/SSL 证书），浏览器使用该格式来启用 HTTPS。然而，X.509 证书并不是唯一存在的数字证书格式。还有 OpenSSH 创建的不太流行的 SSH 证书格式。

X.509 证书为浏览器到服务器的通信启用身份验证，而 SSH 证书为 shell（终端）到 *nix 服务器的通信启用身份验证。本文将简要讨论 SSH 证书是什么、为什么应该使用它们以及它们与 X.509 证书之间的主要区别。

什么是 SSH 证书？

解码后，OpenSSH 证书只是一个数据结构，其中包含公钥、名称和可选信息（例如到期日期和相关权限）。SSH 证书与 X.509 证书非常相似，但属性较少。

OpenSSH 证书是授予 SSH 访问权限的最安全方式。然而，它并没有被广泛使用，可能是因为开发人员根本不了解它。与大多数人对此持谨慎态度的典型 SSH 公钥/私钥设置相比，它还需要更多的前期工作。然而，一旦实施，好处大于麻烦，特别是当您有大量用户、主机和密钥需要管理时。

无需证书的 SSH 身份验证

发布了基于SSH证书的身份验证，但大多数人仍然使用密码或公钥进行SSH身份验证。

基于密码的 SSH 身份验证长期以来一直受到批评，因为人们倾向于使用不可避免的可预测且容易被破解的弱密码。

SSH 公钥身份验证提供了比密码更安全的替代方案，但它仍然很容易被滥用。通过公钥身份验证，所有客户端和服务器都必须拥有自己的公钥和私钥对。当客户端计算机尝试启动与服务器的 SSH 连接时，会发生两件事：

1. 客户端将尝试通过检查服务器的公钥是否在其文件中来确认它正在连接到受信任的服务器known_hosts。如果客户端无法识别服务器的公钥，则会抛出错误（如图所示），指出无法证明服务器的真实性，但询问是否应该连接：

   The authenticity of host 'xxx' can't be established.
   RSA key fingerprint is SHA256:kfcwi9X8T4nMRw1OM0xDXETGcqjU26/zbM+KqNB6CKw.
   Are you sure you want to continue connecting (yes/no)?

2. 服务器还将尝试通过检查用户的公钥是否存在于其authorized_keys文件中来对用户进行身份验证。通常，团队成员将其公钥发送给管理员，以便将其添加或部署到authorized_keys他们需要访问的每台服务器的文件中。当需要部署这些密钥的服务器超过 10 台时会发生什么？这就提出了基于公钥的 SSH 身份验证的第二个缺陷：密钥管理很容易变得乏味且浪费时间，并且对于大型组织来说不可扩展。

最后，由于密钥永不过期，SSH 公钥身份验证会使系统面临安全漏洞。例如，当开发人员离开公司时，他们的公钥应该从所有主机中删除......但我们都知道实际上情况并非如此。SSH academy称，在对 15000 台服务器进行的分析中，在授予实时生产服务器访问权限的 300 万个 SSH 密钥中，90% 不再使用。这种受损的密钥绑定可能会在很长一段时间内不被注意到，从而使系统遭受未经授权的访问。

一些商业和开源服务试图帮助解决这些关键管理危机。基本思想是您通过该服务维护密钥，当您删除密钥时，他们将从您的所有服务器中删除它。然而，危险在于该服务可能成为单点故障。如果攻击者捕获了对该服务的访问权限，他们就可以访问您的所有服务器。在最坏的情况下，如果您无法访问该服务，您也将无法访问所有服务器。

使用证书进行 SSH 身份验证

基于 SSH 证书的身份验证的工作方式与 X.509 证书类似，但实现要简单得多。通过基于 SSH 证书的身份验证，客户端和主机可以相互进行身份验证，从而消除了 TOFU。

首先，设置一个 SSH CA 服务器（也称为“在线 CA”），该服务器将容纳两个 SSH CA 密钥对：一个用于签署和验证主机证书的主机 CA 密钥对，一个用于签署和验证主机证书的用户 CA 密钥对。客户。对于 SSH，人们使用术语 CA（证书颁发机构）来互换指代签名密钥对和 SSH CA 服务器。

最佳实践是创建两个单独的 CA 密钥对以减少攻击面。如果私钥被泄露，您只需为主机或用户重新颁发证书，而不是同时为两者颁发证书。

生成主机 CA 和用户 CA 密钥对后，将所有主机配置为信任由用户 CA 的公钥签名的证书。您还需要将所有客户端配置为信任由主机 CA 的公钥签名的证书。

要向托管计算机颁发证书，您必须为所有主机服务器生成公钥-私钥对，并使用主机 CA 密钥对它们进行签名。要颁发客户端（用户）证书，您还需要为所有客户端生成密钥对并使用用户 CA 密钥对其进行签名。理想情况下，颁发用户证书的过程是完全自动化的。例如，您可以构建一个流程，用户在通过您公司的身份提供商进行身份验证时可以自动获取签名证书。

当客户端想要访问主机时，它将向主机提供其证书，主机也会执行相同的操作。主机服务器将只允许访问具有受密钥信任的证书的客户端，并且客户端可以放心，他们正在连接到受信任的主机。

诚然，这有点过于简单化了实际过程。如果您正在寻找上述过程的实际演练，您可以查看我们有关使用 SSH 证书的文档。

除了消除普通的密钥管理任务和 TOFU 之外，基于 SSH 证书的身份验证还提供了一些允许细粒度访问的功能：

• 证书过期。可以向用户颁发短期证书，以消除废弃的密钥绑定受损的风险。例如，如果开发人员在没有撤销其访问权限的情况下离开，那么他们的证书将在一段时间后过期，并且他们也将自动失去访问权限。
• 证书仅限于某些用户（主体）。这为启用基于角色的访问控制创造了机会。
• 证书可以包含SSH 限制，例如禁止PTY 分配或端口转发。

SSH 证书与 X.509 证书有何不同？

现在我们了解了 SSH 证书是什么以及它们如何使用，让我们看看它们与 X.509 证书有何不同。

用例

X.509 证书被设计为无处不在。它们可以用在 SSL/TLS、S/MIME、EAP-TLS 中，甚至可以用在 Web 应用程序、数据库、VPN、WiFi、文档签名的数字签名以及各种其他地方的 SSH 协议中。SSH证书主要用于SSH访问和认证。

特性

在 OpenSSH 中，SSH 证书要简单得多，并且只有几个功能。与具有众多选项和复杂编码规则的传统 X.509 证书不同，SSH 证书只是带有附加身份和约束数据的公钥和私钥对。

解码后的 SSH 用户证书和 X.509 客户端证书如下所示：

$ step ssh inspect id_ecdsa-cert.pub
id_ecdsa-cert.pub:
        Type: ecdsa-sha2-nistp256-cert-v01@openssh.com user certificate
        Public key: ECDSA-CERT SHA256:O6M6oIjDm5gPm1/aTY619BgC3KSpS4c3aHVWxYh/uGQ
        Signing CA: ECDSA SHA256:EY2EXJGoPv2LA6yEbjH+sf9JjG9Rd45FH1Wt/6H1k7Y
        Key ID: "linda@example.com"
        Serial: 4309995459650363134
        Valid: from 2022-07-11T14:50:01 to 2022-07-11T18:50:01
        Principals:
                linda
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

step certificate inspect https://smallstep.com
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 312048233971325841563421249287934957707544 (0x39506ffca33cfa15b5325cace3c6c45e118)
    Signature Algorithm: SHA256-RSA
        Issuer: C=US,O=Let's Encrypt,CN=R3
        Validity
            Not Before: Jun 6 07:05:01 2022 UTC
            Not After : Sep 4 07:05:00 2022 UTC
        Subject: CN=*.smallstep.com
        Subject Public Key Info:
            Public Key Algorithm: ECDSA
                Public-Key: (256 bit)
                X:
                    98:e4:b1:ce:2f:54:13:50:ac:af:d0:31:54:79:12:
                    0c:48:83:23:0e:c3:92:92:5e:19:20:b0:a9:f1:5d:
                    63:a8
                Y:
                    29:0d:33:d7:6a:ab:c8:d0:20:03:15:0d:9f:62:8a:
                    b5:37:ff:2b:2c:ef:60:82:b5:fc:a3:b8:9d:c8:f6:
                    70:cd
                Curve: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                Server Authentication, Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                09:5C:5C:F4:77:93:82:7E:E2:9E:C8:3A:EE:CD:4D:40:63:E0:85:67
            X509v3 Authority Key Identifier:
                keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6
            Authority Information Access:
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/
            X509v3 Subject Alternative Name:
                DNS:*.smallstep.com, DNS:smallstep.com
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
            RFC6962 Certificate Transparency SCT:
                SCT [0]:
                    Version: V1 (0x0)
                    LogID: QcjKsd8iRkoQxqE6CUKHXk4xixsD6+tLx2jwkGKWBvY=
                    Timestamp: Jun 6 08:05:01.371 2022 UTC
                    Signature Algorithm: SHA256-ECDSA
                      30:45:02:21:00:8e:77:7a:d9:bf:5c:50:59:60:10:bc:2d:c0:
                      f8:6e:9b:51:1d:31:85:4c:11:fe:89:10:ae:de:5c:e1:d7:0c:
                      a1:02:20:3a:d2:1b:78:67:2c:01:7b:04:07:45:3d:34:c8:30:
                      25:23:fe:f8:1e:ce:74:41:00:a0:88:64:32:de:4a:97:c9
                SCT [1]:
                    Version: V1 (0x0)
                    LogID: RqVV63X6kSAwtaKJafTzfREsQXS+/Um4havy/HD+bUc=
                    Timestamp: Jun 6 08:05:01.416 2022 UTC
                    Signature Algorithm: SHA256-ECDSA
                      30:45:02:20:6a:ca:bb:ec:e6:94:86:2b:2d:c2:57:5a:3c:f0:
                      c5:a1:c2:66:ce:eb:f3:83:4c:c3:94:04:31:57:5e:88:b0:e6:
                      02:21:00:e1:86:6e:0b:d0:c4:5f:18:1e:08:0c:a8:0f:8b:e0:
                      4a:da:b0:a3:33:b4:8f:ae:3a:57:91:aa:13:5d:a6:c3:c2
    Signature Algorithm: SHA256-RSA
         88:a3:d8:fb:86:33:83:a7:4c:cd:cc:e3:f2:f8:04:bf:f0:34:
         1c:f8:2f:f3:09:ec:0c:39:6a:96:f4:15:62:f6:7e:20:50:75:
         e2:f6:c3:79:69:f3:7a:78:71:83:7a:28:d0:c4:51:05:77:57:
         bc:5a:40:58:d0:1d:0e:36:5f:f4:2a:e7:70:7d:70:2f:0f:b1:
         91:f1:31:d2:bd:7d:e8:0b:c3:f9:b1:f3:81:08:b3:cc:a7:0a:
         7c:63:67:97:5c:2b:12:48:7b:39:1c:a0:6c:ae:7d:df:63:76:
         0a:40:27:ca:6a:99:d5:7d:67:d2:29:77:85:bf:b3:19:57:5f:
         c2:23:f4:67:c7:09:8b:d6:c4:fd:01:7e:78:66:eb:58:4f:2d:
         87:60:90:d4:27:b5:69:60:f4:ad:91:51:35:eb:25:01:0a:27:
         47:16:eb:47:18:5a:6e:28:e4:d1:5e:f1:78:81:e7:fa:e6:e4:
         45:a9:06:c5:d4:a6:95:97:58:57:1c:eb:d3:b9:e8:c7:c0:52:
         70:88:d4:71:c1:81:ca:9c:41:e0:f4:a0:88:0d:dd:18:b2:68:
         87:52:65:ea:3a:27:c1:d1:76:8c:61:b5:47:b5:e7:63:38:bb:
         3e:0d:f7:46:f3:00:96:91:df:d2:aa:7e:d4:50:63:79:32:4e:

执行

在 X.509 实现中，证书颁发机构始终拥有自己的证书，并且可以拥有中间证书颁发机构（证书链）。SSH 不允许这一切。采用更简单的方法可以使 SSH 证书配置更加容易并最大限度地减少攻击面。

另外，SSH 证书有两种格式：主机证书和用户证书。在 X.509 中，您可以指定证书是否允许“服务器身份验证”或“客户端身份验证”（单个 X.509 证书可以同时允许两者）

可以使用X.509 CA颁发SSH证书吗？

不需要。要支持基于 SSH 证书的身份验证，您需要维护另一个可以处理 SSH 证书签名和颁发的 CA，因为 OpenSSH 使用自定义（更简单）的证书格式。

SSH 证书是执行 SSH 的正确方法

OpenSSH 证书具有强大的功能。它们允许您放弃复杂的关键审批和分发流程。它们还提供临时 SSH 访问，使密钥管理疏忽万无一失。如果您还没有使用它们，您应该使用它们！