配合 Access for Infrastructure 使用 SSH

Access for Infrastructure 提供了对用户如何连接到您的 SSH 服务器的粒度控制。与自助管理 SSH 密钥方法类似，它使用用户设备上的 Cloudflare One Client 和服务器上的 Cloudflare Tunnel，通过 Cloudflare 网络创建安全、私密的连接。Access for Infrastructure 增加了应用级策略，具有针对特定目标和特定用户名的控制，以及 SSH 命令日志记录。

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

1. 在 Cloudflare 仪表板中，转到 Networking（网络） > Tunnels（隧道）。

   Go to Tunnels ↗

2. 创建新隧道或编辑现有的 cloudflared 隧道。

3. 在 Cloudflare 仪表板中，转到 Networking（网络） > Routes（路由）。

   Go to Routes ↗

4. 选择 Create route（创建路由） > Tunnel CIDR（隧道 CIDR）。选择您刚刚创建的隧道，输入您服务器的 IP 或 CIDR 地址（通常是私有 IP，但也允许公共 IP），然后选择 Create route（创建路由）。

要将您的设备连接到 Cloudflare：

1. 在您的设备上以 **Traffic and DNS（流量和 DNS）**模式部署 Cloudflare One Client。
2. 为 TCP 启用 Gateway 代理。
3. 创建设备注册规则以决定哪些设备可以注册到您的 Zero Trust 组织。

默认情况下，WARP 会排除发往 RFC 1918 地址空间 ↗的流量，这些 IP 地址通常用于私有网络，且无法从互联网访问。为了让 Cloudflare One Client 向您的 SSH server 发送流量，您必须配置分流隧道（Split Tunnels），以便将您的 SSH server 的 IP/CIDR 路由通过 Cloudflare One Client。

1. 首先，检查您的分流隧道模式是设置为**Exclude（排除）还是Include（包含）**模式。

2. 根据该模式编辑您的分流隧道路由：

   如果您使用的是**Exclude（排除）**模式：

   a. 删除包含您的 SSH server 的 IP/CIDR 范围的路由。例如，如果您的网络使用默认 AWS 范围 172.31.0.0/16，请删除 172.16.0.0/12。

   b. 重新添加您的 SSH server 没有明确使用的 IP/CIDR 范围。对于上述 AWS 示例，您需要为 172.16.0.0/13、172.24.0.0/14、172.28.0.0/15 和 172.30.0.0/16 添加新条目。这可确保只有发往 172.31.0.0/16 的流量通过 Cloudflare One Client 进行路由。

   您可以使用以下计算器来确定要重新添加的 IP 地址：

   Base CIDRSubtracted CIDRs

   Calculate

   计算器说明

   1. 在 Base CIDR 中，输入您从分流隧道中删除的 RFC 1918 范围。
   2. 在 Subtracted CIDRs 中，输入您的 SSH server 所使用的 IP/CIDR 范围。
   3. 将计算器结果重新添加到您的分流隧道“排除”模式列表中。

   通过缩小 Cloudflare One Client 中包含的私有 IP 范围，您可以降低破坏用户访问本地资源的风险。

   如果您使用的是**Include（包含）**模式：

   1. 将所需的 Zero Trust 域或IP 地址添加到您的分流隧道“包含”列表中。
   2. 添加一条路由以包含您的 SSH server 的 IP/CIDR 范围。

目标代表您基础设施中的单个资源（例如服务器、Kubernetes 集群、数据库或容器），用户将通过 Cloudflare 连接到该资源。

目标与协议无关，这意味着您无需为服务器上运行的每个协议定义新目标。要创建新目标：

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/infrastructure/targets" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"hostname": "infra-access-target",
		"ip": {
				"ipv4": {
						"ip_addr": "187.26.29.249",
						"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
				},
				"ipv6": {
						"ip_addr": "64c0:64e8:f0b4:8dbf:7104:72b0:ec8f:f5e0",
						"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
				}
		}
	}'

接下来，创建一个 Access 应用程序来保护该目标。

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Example infrastructure app",
		"type": "infrastructure",
		"target_criteria": [
				{
						"target_attributes": {
								"hostname": [
										"infra-access-target"
								]
						},
						"port": 22,
						"protocol": "SSH"
				}
		],
		"policies": [
				{
						"name": "Allow a specific email",
						"decision": "allow",
						"include": [
								{
										"email": {
												"email": "jdoe@company.com"
										}
								}
						],
						"connection_rules": {
								"ssh": {
										"usernames": [
												"root",
												"ec2-user"
										]
								}
						}
				}
		]
	}'

此应用程序中的目标现已受到您的基础设施策略保护。

从 Cloudflare One Client 到您的基础设施目标的流量会同时受到 Gateway 网络策略和特定于应用程序的 Access 策略的过滤。

为防止 Cloudflare One Client 用户访问您的整个私有网络，我们建议为您的私有 IP 空间创建一个兜底 Gateway 阻止策略。然后，您可以在此基础上叠加更高优先级的允许策略（在 Access 或 Gateway 中），以授予用户对特定应用程序或 IP 的访问权限。

默认情况下，Cloudflare 会在评估所有 Gateway 网络策略之后再评估 Access 应用程序策略。要在特定 Gateway 策略之前或之后评估 Access 应用程序，请执行以下步骤：

1. 在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Traffic policies（流量策略） > Firewall policies（防火墙策略）。在 Network（网络） 中，使用以下配置创建网络策略：

   选择器	运算符	值	操作
   Access Infrastructure Target	is	Present	Allow（允许）

2. 使用仪表板或 API 更新策略的优先顺序。

该 Gateway 策略将应用于所有 Access for Infrastructure 目标，包括 RDP 和 SSH。

接下来，配置您的 SSH 服务器以信任 Cloudflare SSH CA。这允许 Access 使用短期证书而非传统 SSH 密钥进行身份验证。

要生成 Cloudflare SSH CA 并获取其公钥：

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/gateway_ca" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/gateway_ca" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

1. 使用以下命令切换到远程目标机器上的 SSH 配置目录：

   cd /etc/ssh

2. 到达该目录后，您可以使用以下命令生成文件并打开文本编辑器以输入/粘贴公钥。

   vim ca.pub

3. 在 ca.pub 文件中，粘贴公钥且不要进行任何修改。

   ecdsa-sha2-nistp256 <redacted> open-ssh-ca@cloudflareaccess.org

   ca.pub 文件可以保存多个密钥，每行一个。也允许空行和以 # 开头的注释。

4. 保存 ca.pub 文件。在某些系统中，根据您的权限，您可能需要使用以下命令强制保存文件：

   :w !sudo tee %
   :q!

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

1. 在远程机器的 /etc/ssh 目录中，打开 sshd_config 文件。

    sudo vim /etc/ssh/sshd_config

2. 按 i 进入插入模式，然后在文件顶部、所有其他指令上方添加以下行：

   PubkeyAuthentication yes
   TrustedUserCAKeys /etc/ssh/ca.pub

3. 按 esc，然后输入 :x 并按 Enter 保存并退出。

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

sudo systemctl reload ssh

sudo systemctl reload sshd

您可以要求用户在连接到 您的 SSH 服务器之前使用 YubiKey PIV 密钥进行身份验证。当需要 MFA 时，用户必须在建立连接之前使用其注册的 PIV 密钥完成公钥身份验证。

要为 SSH 配置独立 MFA，请参阅为基础设施应用程序强制执行 MFA。

在启用 MFA 的情况下，用户在连接之前必须：

1. 通过 App Launcher 注册 PIV 密钥。
2. 配置其 SSH 客户端以使用注册的 PIV 密钥。

当用户运行 ssh <username>@<target IP> 时，SSH 代理会检查匹配策略是否需要 MFA。如果需要，用户必须触摸其 YubiKey 并输入其 PIN（取决于密钥的 PIN 策略）。然后代理完成连接。

只要用户在其设备上登录了 Cloudflare One Client，他们就可以使用任何 SSH 客户端连接到目标。如果目标位于特定的虚拟网络中，请在发起连接之前确保 Cloudflare One Client 已连接到该虚拟网络。用户无需在其设备上修改任何 SSH 配置。例如，要从终端进行 SSH：

ssh <username>@<target IP>

Access for Infrastructure 还支持 scp、sftp 和 rsync 命令。有关不受支持的 SSH 命令和功能的列表，请参阅已知限制。

要了解有关用户连接的更多信息，请参阅 Access for Infrastructure 文档。

SSH 命令日志包含用户在目标上运行的实际 SSH 命令。所有套餐计划的客户都可以在 Cloudflare 上存储 SSH 日志，并从仪表板下载日志。可下载日志使用客户提供的公钥进行加密，对 Cloudflare 不可见。提供可下载的 SSH 日志是尽力而为的；为了保证交付，Enterprise 客户可以配置 Logpush 作业将 SSH 日志发送到存储目标。Logpush 负载不会使用客户提供的公钥进行加密。

按照以下说明在 Zero Trust 中加密和下载 SSH 命令日志。

要记录 SSH 命令，您需要生成一个 HPKE 密钥对，并将公钥上传到 Cloudflare。

1. 下载 ↗ Cloudflare ssh-log-cli 实用程序。

2. 使用 ssh-log-cli 实用程序生成公钥和私钥对。

   ./ssh-log-cli generate-key-pair -o sshkey

   README.md    ssh-log-cli    sshkey    sshkey.pub

   此命令会输出两个文件：sshkey.pub 公钥和匹配的 sshkey 私钥。

3. 在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Traffic policies（流量策略） > Traffic settings（流量设置）。

4. 在 SSH log encryption public key（SSH 日志加密公钥） 中，粘贴 sshkey.pub 的内容，然后选择 Save（保存）。

所有代理的 SSH 命令都会使用此公钥立即加密。需要匹配的私钥才能查看日志。

要关闭 SSH 命令日志记录，请删除您上传的公钥：

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/audit_ssh_settings" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"public_key": ""
	}'

SSH 命令日志在仪表板本身中是不可见的，必须进行导出和解密。

要手动检索日志：

1. 在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Insights（洞察）> Logs（日志）。
2. 选择 SSH command logs（SSH 命令日志）。
3. 使用您的基础设施应用程序名称过滤日志。
4. 选择您要导出的命令日志对应的 SSH 会话。
5. 在侧边栏中，向下滚动到 **SSH logs（SSH 日志）**并选择 Download（下载）。

6. 要解密日志，请按照 SSH Logging CLI 仓库 ↗中的说明进行操作。在以下示例中，sshkey 是与上传到 Cloudflare 的公钥匹配的私钥。

   ./ssh-log-cli decrypt -i sshlog -k sshkey

   此命令会输出一个包含已解密日志的 sshlog-decrypted.zip 文件。

Cloudflare 允许您将 SSH 命令日志发送到 Logpush 中配置的存储目的地，包括第三方目的地。有关可用数据字段的列表，请参阅 SSH 日志数据集。

要设置 Logpush 作业，请参阅 Logpush 集成。

不支持以下 SSH 功能：

• 本地和远程端口转发
• SSH 代理转发
• X11 转发

SSH 会话的最大预期持续时间为 10 小时。有关更多信息，请参阅 Access 故障排除。

无法连接到您的 SSH 端点可能是由多个变量引起的。请使用以下步骤调查并解决您的连接失败源头。

1. 验证您的 Access 策略是否允许用户访问目标。
2. 检查 Cloudflare Tunnel 的健康状况。
3. 确认用户存在于服务器上。
4. 检查您的 sshd_config 文件是否存在配置错误。

用户可能因为不存在显式允许的 Access 策略，并且 Access 默认设置为拒绝该用户，而被 Access 策略阻止访问您的服务器。

作为最终用户，运行 warp-cli target list 以验证您是否有权访问该目标。

warp-cli target list

╭──────────────────────────────────────┬──────────┬───────┬───────────────────────┬──────────────────────┬────────────╮
│ Target ID                            │ Protocol │ Port  │ Attributes            │ IP (Virtual Network) │ Usernames  │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH      │ 22    │ hostname: do-target   │ 10.116.0.3 (a1net)   │ alice      │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH      │ 23    │ hostname: do-target   │ 10.116.0.3 (a1net)   │ root       │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 01943cff-6130-7989-8bff-cbc02b59a2b1 │ SSH      │ 80    │ hostname: az-target   │ 172.16.0.0 (b1net)   │ alice, bob │
╰──────────────────────────────────────┴──────────┴───────┴───────────────────────┴──────────────────────┴────────────╯

• 如果目标出现在列表中，请确认输出中显示了您尝试连接的用户名。如果未显示该用户名，则管理员必须找到与该目标关联的 Access 策略，并将该用户名添加到该 Access 策略中。管理员应该已经在步骤 5：添加基础设施应用程序的子步骤 9 中创建了一个 Access 策略。如果显示了该用户名，则意味着该 Access 策略应该已授予访问权限，您应该确保步骤 2 中的隧道健康状况良好。

• 如果目标未出现在列表中，管理员必须在 Cloudflare One 中审核与该目标关联的 Access 策略，查找可能阻止连接的误配置。

作为管理员，与其在最终用户设备上运行 warp-cli target list，您不如使用 Access 日志来检查 Access 策略是否导致连接问题。在代表最终用户排查连接问题时，审查日志非常有用。

1. 在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Insights（洞察）> Logs（日志）。

2. 选择 Access authentication logs（Access 身份验证日志）。

3. 选择您正在测试的应用程序，或将应用类型过滤为 Infrastructure（基础设施）。

4. 审查 Decision（决策）。如果 **Decision（决策）**为 Access denied（Access 已拒绝），请选择该应用程序并复制 **App（应用程序）**下方的名称。

   如果决策为 Access granted（Access 已授予），则 Access 策略没有干扰您的连接尝试，并且您的连接问题归咎于 Cloudflare Tunnel（步骤 2），SSH 服务器（步骤 3）或 sshd_config 文件（步骤 4）。

5. 转到 Access controls（访问控制）> Applications（应用程序）。

6. 在搜索栏中输入应用名称并选择该应用程序。

7. 选择 Configure（配置）。

8. 转到 Policies（策略）以审查哪些标准可能在阻止该用户。

通过添加 Access 策略来允许用户，连接问题应该得到解决。保存您的策略更改后，尝试连接到服务器。

如果您在审核 Access 策略后仍然遇到连接问题，请在下一步中审查隧道健康状况。

如果最终用户无法连接到目标，您在步骤 1：将服务器连接到 Cloudflare 中设置的隧道可能会处于关闭或非活动状态。

要检查您的隧道状态：

1. 在 Cloudflare 仪表板中，转到 Networking（网络）> Routes（路由）。

   Go to Routes ↗

2. 搜索您的 IP 以找到该路由及其关联的隧道。

   此 IP 将在前一步骤的 warp-cli target list 输出中可见。如果您是管理员，您也可以转到 Networks（网络）> **Targets（目标）**并找到您的 **Hostname（主机名）**旁的 IP。

3. 选择 **Connector（连接器）**列中的隧道名称以打开隧道详细信息页面。

4. 确认 Tunnel status 显示为 Active，而不是 Down、Degraded 或 Inactive。

有关排查问题的详细步骤，请参阅排查 Tunnel 故障文档。审查带防火墙的 Tunnel 文档以确保正确配置您的网络以允许 cloudflared 连接。

在验证了您的隧道健康状况没有问题之后，在下一步中确认用户在服务器上的存在。

要验证 UNIX 服务器上是否存在某个用户，请在服务器上运行 id <USERNAME> 命令以验证该用户名是否存在。如果该用户名不存在，您必须将该用户添加到服务器。

如果该用户在服务器上存在，请在下一步中排查您的 sshd_config 文件。

用户无法连接到您的 SSH 端点的原因之一可能是 sshd_config 文件配置错误。按照以下步骤审核您的 sshd_config 文件配置错误。

sshd 日志可以确认用户是否已到达服务器。您的 sshd 日志位置是在您的 sshd_config 中定义的。对于 Ubuntu，日志位置可能在 journalctl -u ssh，而对于 Red Hat 则是 tail /var/log/auth.log。

使用您的 sshd 日志，验证 SSH 连接尝试是否正在到达服务器。

要排除 sshd_config 文件中的任何问题，请将您现有的 sshd_config 文件与下面的示例进行对比，以验证是否有任何指令导致了身份验证问题。以下示例 sshd_config 文件将能够实现成功的身份验证：

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

PubkeyAuthentication yes
TrustedUserCAKeys /etc/ssh/ca.pub

Include /etc/ssh/sshd_config.d/*.conf

# When systemd socket activation is used (the default), the socket
# configuration must be re-generated after changing Port, AddressFamily, or
# ListenAddress.
#
# For changes to take effect, run:
#
#   systemctl daemon-reload
#   systemctl restart ssh.socket
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
LogLevel DEBUG3

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10



# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile    .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin yes
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem    sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server

接下来的步骤将引导您进行故障排除。您将暂时使用提供的示例替换现有的 sshd_config 文件，以排除配置问题。在继续之前，请仔细审查和对比这两个文件以识别任何冲突的指令。

1. 备份现有的 sshd_config 文件。

   mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

2. 创建一个新的 sshd_config 文件。

   vi /etc/ssh/sshd_config

3. 按键盘上的 i 键进入插入模式。

4. 粘贴示例文件中的内容。

5. 按 Esc 键退出插入模式。

6. 输入 :x 保存并退出。

7. 重新加载您的 SSH 服务器。

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

   对于 Debian/Ubuntu：

   sudo systemctl reload ssh

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

   sudo systemctl reload sshd

完成所有四个故障排除步骤后，您应该已经解决了由 SSH 服务器配置错误引起的所有连接问题。如果问题仍然存在，请重新检查 sshd 日志。上面共享的示例 sshd_config 启用了调试日志记录，这可能会暴更高特的问题。

为了尽可能快地进行故障排除，请确保您的支持工单包含详尽的详细信息。您提供的上下文越多，识别和解决您问题的速度就越快。

为了确保在 联系支持人员 时能够高效解决问题，请在工单中包含尽可能多的相关细节：

• 上下文：简要描述场景或用例（例如，用户在哪里，他们试图做什么）。

• 重现步骤：描述您在故障排除过程中为重现该问题所采取的步骤。

• 时间戳：具体说明并包括问题发生的确切时间和时区。

• 故障排除尝试：概述已尝试解决问题的任何故障排除步骤或更改。

• sshd 调试级日志：附上您在 步骤 4：调试 sshd_config 文件配置错误。
• sshd_config 文件：包括您服务器的 sshd_config 副本，以帮助识别任何配置错误或冲突的指令。
• 客户端 SSH 输出：使用详细标志 (-vvv) 运行失败的 SSH 命令，并提供完整的终端输出，以显示客户端的连接和身份验证尝试。