短期证书（旧版）

Cloudflare Access can replace 传统 SSH 密钥，改为基于用户 Access 登录生成的令牌向其颁发短期证书。在传统模式中，用户生成 SSH 密钥对，管理员通过将用户的公钥部署到各 SSH 服务器来授予访问权限。这些 SSH 密钥可能在这些服务器上保持不变长达数月乃至数年。Cloudflare Access 消除了管理 SSH 密钥的负担，同时通过用临时 SSH 证书替换长期 SSH 密钥来提高安全性。

1. 保护 Cloudflare Access 后面的服务器

Cloudflare Access 短期证书可以与任何现代 SSH 服务器配合使用，无论其是否在 Access 后面。不过，我们建议将您的服务器置于 Access 后面，以增加安全性和功能，例如可审计性和基于浏览器的终端。

要在 Cloudflare Access 后面保护您的服务器：

将服务器连接到 Cloudflare作为已发布应用程序。
为该服务器创建自托管 Access 应用程序。

2. 确保 Unix 用户名与用户 SSO 身份匹配

Cloudflare Access 将从令牌中获取身份，并使用短期证书在目标基础设施上对用户进行授权。

最简单的设置是用户的 Unix 用户名与其电子邮件地址前缀相匹配。颁发的短期证书将对用户的电子邮件地址前缀有效。例如，如果您的 Okta 或 GSuite 组织中的用户注册为 jdoe@example.com，他们将以 jdoe 身份登录到 SSH 服务器。

出于测试目的，您可以运行以下命令在机器上生成一个 Unix 用户：

sudo adduser jdoe

高级设置：不同的用户名

SSH 证书在其签名中包含一个或多个 principals，这些主体指示允许该证书登录的 Unix 用户名。Cloudflare Access 始终会将主体设置为用户的电子邮件地址前缀。例如，当 jdoe@example.com 尝试连接时，Access 会颁发一份针对主体 jdoe 授权的短期证书。

默认情况下， SSH 服务器会根据用户证书中列出的主体来验证 Unix 用户名。您可以配置您的 SSH 服务器以接受与 Unix 用户名不匹配的主体。

用户名与不同的电子邮件匹配

要允许 jdoe@example.com 以用户 johndoe 身份登录，请将以下内容添加到服务器的 /etc/ssh/sshd_config：

Match user johndoe
  AuthorizedPrincipalsCommand /bin/echo 'jdoe'
  AuthorizedPrincipalsCommandUser nobody

这会告诉 SSH 服务器，当有人尝试以用户 johndoe 身份进行身份验证时，检查其证书中是否包含主体 jdoe。这将允许用户 jdoe@example.com 使用如下命令登录服务器：

ssh johndoe@server

用户名匹配多个电子邮件

要允许多个电子邮件地址以 vmuser 身份登录，请将以下内容添加到服务器的 /etc/ssh/sshd_config：

Match user vmuser
  AuthorizedPrincipalsFile /etc/ssh/vmusers-list.txt

这会告诉 SSH 服务器从文件中加载主体列表。然后，在 /etc/ssh/vmusers-list.txt 中列出可以作为 vmuser 登录的电子邮件前缀，每行一个：

jdoe
bwayne
robin

用户名匹配所有用户

要允许任何 Access 用户以 vmuser 身份登录，请将以下命令添加到服务器的 /etc/ssh/sshd_config：

Match user vmuser
  AuthorizedPrincipalsCommand /bin/bash -c "echo '%t %k' | ssh-keygen -L -f - | grep -A1 Principals"
  AuthorizedPrincipalsCommandUser nobody

此命令使用用户出示的证书，并授权其中列出的任何主体。

允许所有用户

要允许任何 Access 用户以任何用户名登录，请将以下内容添加到服务器的 /etc/ssh/sshd_config：

AuthorizedPrincipalsCommand /bin/bash -c "echo '%t %k' | ssh-keygen -L -f - | grep -A1 Principals"
AuthorizedPrincipalsCommandUser nobody

由于这将使服务器的安全性完全依赖于您的 Access 配置，请确保您的 Access 策略配置正确。

3. 生成短期证书公钥

在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Access controls（访问控制） > Service credentials（服务凭据） > SSH。
选择 Add a certificate（添加证书）。
在 Application（应用程序） 下拉菜单中，选择代表您的 SSH 服务器的 Access 应用程序。
选择 Generate certificate（生成证书）。短期证书表中将出现一个新行，其中包含您的 Access 应用程序的名称。
选择适用于您的应用程序的短期证书。
复制其 CA 公钥（CA public key）。您可以随时返回复制此公钥。

4. 保存您的公钥

复制步骤 3 中从仪表板生成的公钥。

使用以下命令切换到远程目标机器上的 SSH 配置目录：
```
cd /etc/ssh
```
到达该目录后，您可以使用以下命令生成文件并打开文本编辑器以输入/粘贴公钥。
```
vim ca.pub
```
在 ca.pub 文件中，粘贴公钥且不要进行任何修改。
ca.pubtxt
```
ecdsa-sha2-nistp256 <redacted> open-ssh-ca@cloudflareaccess.org
```
ca.pub 文件可以保存多个密钥，每行一个。也允许空行和以 # 开头的注释。
保存 ca.pub 文件。在某些系统中，根据您的权限，您可能需要使用以下命令强制保存文件：
```
:w !sudo tee %
:q!
```

5. 修改您的 `sshd_config` 文件

通过更新远程目标机器上的 sshd_config 文件，将您的 SSH 服务器配置为信任 Cloudflare SSH CA。

在远程机器的 /etc/ssh 目录中，打开 sshd_config 文件。
```
 sudo vim /etc/ssh/sshd_config
```
按 i 进入插入模式，然后在文件顶部、所有其他指令上方添加以下行：
```
PubkeyAuthentication yes
TrustedUserCAKeys /etc/ssh/ca.pub
```
请注意您的 include 语句
如果在这些行下方有任何 include 语句，则这些文件中的配置将不会优先。
按 esc，然后输入 :x 并按 Enter 保存并退出。

6. 重启您的 SSH 服务器

修改 sshd 配置后，在远程机器上重新加载 SSH 服务以使更改生效。

对于 Debian/Ubuntu：

sudo systemctl reload ssh

对于 CentOS/RHEL 7 及更高版本：

sudo systemctl reload sshd

7. 作为用户连接

配置您的客户端 SSH 配置

在客户端，配置您的设备以使用 Cloudflare Access 访问受保护的机器。要使用短期证书，您必须在 SSH 配置文件（~/.ssh/config）中包含以下设置。

为了节省时间，您可以使用以下 cloudflared 命令来打印所需的配置命令：

cloudflared access ssh-config --hostname vm.example.com --short-lived-cert

如果您更喜欢手动配置，这是生成的 SSH 配置示例：

Match host vm.example.com exec "/usr/local/bin/cloudflared access ssh-gen --hostname %h"
    HostName vm.example.com
    ProxyCommand /usr/local/bin/cloudflared access ssh --hostname %h
    IdentityFile ~/.cloudflared/vm.example.com-cf_key
    CertificateFile ~/.cloudflared/vm.example.com-cf_key-cert.pub

通过基于浏览器的终端连接

终端用户可以使用 Cloudflare 基于浏览器的终端连接到 SSH 会话，而无需进行任何配置。要启用，请参阅浏览器渲染的终端。

默认情况下，基于浏览器的终端会提示用户进行用户名/密码登录。如果您想使用基于证书的身份验证，请确保您已为配置了浏览器渲染 SSH 的特定 Access 应用程序创建了短期证书。

您的 SSH 服务器现在已受 Cloudflare Access 保护——在可以连接之前，用户将被提示向您的身份提供商进行身份验证。您还可以通过配置 Gateway 审计 SSH 策略来启用 SSH 命令日志记录。