域名负责名字，Tunnel 负责通路#

原来的连接方式是：

1
Windows ssh.exe → 服务器公网地址:22 → 服务器 SSH 服务

只把公网地址改成域名，SSH 仍需要能直接连接那个端口。域名本身不会让已经关闭的公网 22 重新可达。

Cloudflare Tunnel 的连接器由服务器侧主动连接 Cloudflare，访问请求通过已经建立的通道返回服务器。连接可以双向传输数据，所以关闭服务器公网入站后，仍可通过该通道提供服务。Cloudflare Tunnel 原理

SSH 需要适配这条通路#

浏览器原本就使用 HTTP/HTTPS；Windows 的普通 SSH 客户端则不会自动把 SSH 数据转换成这个发布入口所需的 WebSocket 连接。

电脑上的 cloudflared 负责接通这一段传输，ssh.exe 继续核对服务器身份、加密 SSH 内容和完成密钥认证。SSH 通过 ProxyCommand 自动调用它。Cloudflare 的 SSH 客户端配置

第一步：确认连接器能到达内网 SSH#

在连接器所在的网络中，确认目标服务器的 SSH 地址和端口可达。若连接器运行在 Docker 容器内，容器的 localhost 指它自身，不能直接当成宿主机。

内网地址或 DNS 名称应从实际环境取得，不要复制别人的服务器地址。

第二步：添加 SSH 域名路由#

在 Cloudflare 控制台进入 Networking → Tunnels，选择对应 Tunnel，在 Routes → Add route → Published application 中添加发布的应用路由，服务类型选择 SSH。例如：

表格使用完整 service 值说明协议与目标；在控制台已选择 SSH 类型时，地址栏只填写 <SERVER_1_PRIVATE_HOSTNAME>:22 这样的主机和端口，不要重复添加 ssh://。

尖括号内容是占位符，需要替换。域名应指向 Tunnel 的入口，路由再决定转送到哪个内网 SSH 服务；不能仅添加一个指向源站公网地址的普通 A 记录就认为迁移完成。官方 SSH 路由步骤

建议同时为对应 SSH 域名添加 Cloudflare Access 自托管应用，并设置允许哪些身份访问的策略；这是官方 SSH 路由步骤给出的建议。首次连接或 Access 会话过期时，按策略完成浏览器认证，之后仍须通过服务器的 SSH 密钥认证。两层认证的区别见第 9 节。

第三步：下载电脑侧 cloudflared#

从 Cloudflare 官方发布页 选择适合电脑体系结构的 Windows 客户端。保存到准备使用的程序目录，并核对对应版本资产的 SHA-256。

下面的命令只查看版本和计算文件摘要；需要自行将计算值与官方发布值比较：

1
# 路径为示例，使用前替换。
2
$cloudflaredExe = 'C:\Tools\cloudflared\cloudflared.exe'
3
& $cloudflaredExe --version
4
(Get-FileHash -LiteralPath $cloudflaredExe -Algorithm SHA256).Hash

文件摘要用于校验下载内容，不是 SSH 主机密钥。不同版本、不同体系结构的摘要不能混用。

第四步：备份主配置，并准备可信主机记录#

修改前备份已有的 ~/.ssh/config，例如保存为同目录下的 config.before-tunnel.bak，保留原有其他主机配置。

从已信任的连接或独立可信渠道核对目标服务器的主机公钥，再准备 ~/.ssh/tunnel/known_hosts。记录中的主机名应对应新的 SSH 域名，例如：

1
ssh-1.example.com <KEY_TYPE> <TRUSTED_HOST_PUBLIC_KEY_FOR_SERVER_1>
2
ssh-2.example.com <KEY_TYPE> <TRUSTED_HOST_PUBLIC_KEY_FOR_SERVER_2>

这是格式示意，不是有效的公钥记录。密钥类型和内容必须取自核对过的服务器主机公钥；原先按旧地址保存的记录，不一定自动匹配新域名。不要把自己的登录私钥放进这个文件。

第五步：添加两台主机的 SSH 配置#

将下面的示例保存到 ~/.ssh/tunnel/config，先替换域名、用户和程序位置：

1
Host server-1 ssh-1.example.com
2
    HostName ssh-1.example.com
3
    User serveruser
4
    ProxyCommand "C:/Tools/cloudflared/cloudflared.exe" access ssh --hostname %h
5
    UserKnownHostsFile "~/.ssh/tunnel/known_hosts"
6
    StrictHostKeyChecking yes
7
    PasswordAuthentication no
8
    KbdInteractiveAuthentication no
9
    ConnectTimeout 30
10
    ServerAliveInterval 30
11
    ServerAliveCountMax 3
12

13
Host server-2 ssh-2.example.com
14
    HostName ssh-2.example.com
15
    User serveruser
16
    ProxyCommand "C:/Tools/cloudflared/cloudflared.exe" access ssh --hostname %h
17
    UserKnownHostsFile "~/.ssh/tunnel/known_hosts"
18
    StrictHostKeyChecking yes
19
    PasswordAuthentication no
20
    KbdInteractiveAuthentication no
21
    ConnectTimeout 30
22
    ServerAliveInterval 30
23
    ServerAliveCountMax 3

在主配置 ~/.ssh/config 的原有 Host 或 Match 段之前加入：

1
Include ~/.ssh/tunnel/config

Include 让 SSH 自动读取独立文件，因此在任意工作目录都可以使用别名。文件名 config 不带 .txt 后缀。OpenSSH 对多数配置采用先取得的值，因此将这条 Include 放在已有通配 Host * 规则之前，并用第 8 节的 ssh -G 检查实际结果。

SSH 配置有自己的语法；不要把 PowerShell 的 $env:USERPROFILE 直接当成所有 SSH 参数都能识别的变量。本文在支持的位置使用 ~，程序路径使用带引号的绝对路径。OpenSSH 配置手册

第六步：验证新通道，再关闭公网 SSH#

先保留可用的维护连接，按第 8 节检查配置，再分别登录两个 Tunnel 入口。确认主机身份正确、原有密钥可用之后，才移除服务器公网 22 的入站放行，保留连接器所需的内网访问。

规则修改后，从外部再次验证：域名 SSH 仍可登录，源站公网 22 已不可直接访问。具体还需检查云安全组、安全列表和主机防火墙中是否存在其他放行规则。

8.1 确认使用的是预期 SSH 程序#

电脑可能同时装有多个 SSH。查看路径，必要时明确调用 Windows 自带版本：

1
Get-Command ssh.exe -All | Select-Object Source
2
& "$env:WINDIR\System32\OpenSSH\ssh.exe" server-1

8.2 查看最终生效的配置#

下面命令只展开本文配置，不建立 SSH 连接：

1
ssh -G server-1 | Select-String '^(hostname|user|port|proxycommand|userknownhostsfile|stricthostkeychecking) '
2
ssh -G server-2 | Select-String '^(hostname|user|port|proxycommand|userknownhostsfile|stricthostkeychecking) '

应看到替换后的真实域名、登录用户、cloudflared 命令和主机记录文件。若 hostname 仍是短别名，优先检查 Include、文件名和当前 SSH 程序。

port 22 仍可能出现在展开结果中，这是 SSH 默认配置值。由于存在 ProxyCommand，数据传输交给 cloudflared；电脑到 Cloudflare 使用 HTTPS/WebSocket，连接器到源站才使用内网 22。不能据此判断源站公网 22 是否开放，也不需要给日常 SSH 命令添加 -p 443。

8.3 查看客户端和 Agent 状态#

1
# 请改成实际客户端路径。
2
Test-Path -LiteralPath 'C:\Tools\cloudflared\cloudflared.exe'
3
Get-Service ssh-agent
4
ssh-add -l

如果 Agent 没有身份，检查 KeePassXC 是否解锁，以及对应条目是否加载到 Windows OpenSSH Agent。不同 Agent 的密钥列表不一定互通。

ssh-add -l 不显示私钥，但会显示密钥标识；路径、用户信息和这些标识都不应直接放进公开知识库。

8.4 按错误定位#

需要更多信息时可运行 ssh -v server-1。公开日志前，应移除个人路径、真实域名、账号、地址和密钥标识。

直接在浏览器中打开 SSH 域名，不能代替 SSH 连通性验证；该入口不是普通网页。

换电脑#

准备 Windows OpenSSH、KeePassXC 与对应 Agent 集成；安全迁移所需 SSH 密钥，下载并校验 cloudflared，替换客户端配置中的路径，核对可信主机记录，最后测试连接。

日常 SSH 客户端无需保存云平台管理 API 私钥或服务器侧 Tunnel 凭据。

连接器故障#

如果两台主机共用一个连接器，连接器所在主机故障会影响两个入口。维护前应准备独立恢复路径，不能停止唯一入口后再依赖同一入口修复它。

没有可用会话时，可先通过云控制台等管理入口检查状态；必要时临时放行受限维护来源的 SSH，修复并验证 Tunnel 后撤销。删除本机配置不会自动恢复服务器公网 22。

长时间会话#

电脑休眠、网络变化或连接器重连可能中断 SSH，保活配置不能保证会话永久不断。Cloudflare 对这类发布的 SSH 服务使用 WebSocket 转送，并为长时间连接推荐其他 Client-to-Tunnel 方式；有持续长连接需求时应单独评估。Cloudflare 协议与长连接说明