用 Cloudflare Workers 部署 EdgeSSH，并接入我的博客服务器

EdgeSSH 是一个运行在 Cloudflare Workers 上的开源 WebSSH 工作台，提供在线终端、SFTP 文件管理、服务器监控、代码片段和 HTTP 端口转发等功能。它适合个人管理少量可通过公网 SSH 访问的服务器，不需要额外维护一台 WebSSH 中转机。

本文记录一套完整流程：使用 GitHub OAuth 登录、免费 workers.dev 地址部署 EdgeSSH，再为博客服务器创建一把独立 SSH 密钥并接入工作台。

文中的账号、地址、用户名和文件名均为占位符，请替换成自己的信息。不要将 API Token、OAuth Client Secret、SSH 私钥或带认证参数的回调地址发布到博客、截图或日志中。

准备工作

需要提前准备：

• GitHub 账号
• Cloudflare 账号
• 一台已经运行 SSH 服务、可从公网访问的 Linux 服务器
• 服务器的公网 IP、SSH 端口和登录用户名

本文选择 GitHub OAuth 作为 EdgeSSH 的唯一登录方式，并使用 Cloudflare 免费分配的 workers.dev 地址。GitHub OAuth 模式不需要开通 Cloudflare Zero Trust。

一、Fork 项目并启用 Actions

打开 EdgeSSH 项目：

https://github.com/aozorae/EdgeSSH

点击右上角 Fork，把项目复制到自己的 GitHub 账号下。进入自己的 Fork 后打开 Actions；如果 GitHub 显示启用工作流提示，按提示启用。

左侧正常情况下可以看到 Deploy、部署预览 Worker、Force Update 等工作流。普通部署只需要使用 Deploy。

二、创建 GitHub OAuth App

打开 GitHub OAuth App 创建页面：

https://github.com/settings/applications/new

首次使用免费 workers.dev 地址时，还不知道最终入口，可以先填写占位地址：

如果页面显示相关选项，不要启用通配符回调或 Device Flow。创建完成后：

1. 复制页面中的 Client ID。
2. 点击 Generate a new client secret。
3. 立即安全保存生成的 Client Secret；GitHub 之后不会再次完整显示它。

Client ID 可以作为仓库 Variable 保存，Client Secret 必须作为 Secret 保存。两者必须来自同一个 OAuth App。

三、配置 GitHub Actions Variables 和 Secrets

进入自己 Fork 后的仓库：

Settings → Secrets and variables → Actions

在 Variables 页签添加：

使用免费 workers.dev 地址时，不要创建 CUSTOM_DOMAIN，也不要把某个 workers.dev 地址填进去。

在 Secrets 页签添加：

常见错误是把说明文字或占位符直接填进 GH_CLIENT_ID。这里必须粘贴 OAuth App 页面提供的真实 Client ID。

四、创建 Cloudflare API Token

打开 Cloudflare 的 API Tokens 页面，点击 Create Token，以 Edit Cloudflare Workers 模板为起点。

GitHub OAuth 模式需要以下最小权限：

账户资源只选择实际部署 EdgeSSH 的 Cloudflare 账户。使用 GitHub 托管的 Actions Runner 时，API Token 的客户端 IP 过滤应留空，因为 Runner 的出口 IP 并不固定；有效期可以根据自己的轮换策略设置。

EdgeSSH 不使用 R2、KV 或普通 Workers Routes，因此不需要为部署额外添加 R2、KV、Zone Read 或 Workers Routes 权限。GitHub OAuth 模式也不需要 Cloudflare Access 权限。

创建 Token 后，将它保存到 GitHub 仓库 Secret：

CLOUDFLARE_API_TOKEN

Token 只会在创建时完整显示一次，不要发到聊天、Issue、博客或截图中。

五、运行 Deploy

回到 Fork 仓库的 Actions 页面：

1. 点击左侧 Deploy。
2. 点击 Run workflow。
3. 分支选择 main。
4. GitHub OAuth 模式下，管理员邮箱输入框留空。
5. 点击绿色按钮开始部署。

工作流会自动完成 Worker、Durable Object、D1 数据库、数据库迁移、运行时 Secret 和前端资源部署。不要手动创建同名 D1 或覆盖 Worker 中的加密密钥。

首次部署结束后，在运行摘要或部署日志中找到正式入口，形式通常类似：

https://<worker-name>.<account-subdomain>.workers.dev

首次生成 workers.dev 子域时，DNS 或证书可能需要短暂生效时间。如果 Worker 已成功上传，但最终入口验收暂时无法连接，可以等待片刻后重跑同一个 Deploy；已有 Worker、D1 和加密密钥会被复用。

六、回填 OAuth App 的正式地址

回到 GitHub：

Settings → Developer settings → OAuth Apps → My EdgeSSH

把占位地址替换为部署摘要中的正式入口：

Homepage URL:
https://<正式 workers.dev 入口>

Authorization callback URL:
https://<正式 workers.dev 入口>/auth/callback

注意：

• 必须使用 https://。
• 两处域名必须完全相同。
• 回调路径必须精确为 /auth/callback。
• 不要在末尾额外添加 /。

如果上一次 Deploy 已经成功，保存 OAuth App 地址后无需再次部署，直接打开正式入口登录即可；如果上一次部署因入口验收失败而标红，则修正配置后重跑 Deploy。点击登录，并使用 GH_ADMIN 指定的 GitHub 账号授权。登录后看到主机总览，即代表 EdgeSSH 部署完成。

七、确认博客服务器的真实 SSH 配置

如果 Mac 上已经配置了 SSH 快捷名称，例如：

ssh blog-server

可以用下面的命令展开真实配置：

ssh -G blog-server | grep -E '^(hostname|user|port|identityfile|identitiesonly|proxyjump|proxycommand) '

需要记录的只有：

• hostname：服务器公网 IP 或域名
• user：SSH 用户名
• port：SSH 端口
• identityfile：Mac 当前使用的私钥路径

不要把本地私钥内容发布到文章中。

八、为 EdgeSSH 创建独立密钥

不要把日常使用的主密钥直接交给 WebSSH。建议为每台服务器创建一把独立、随时可以撤销的 Ed25519 密钥。

EdgeSSH 当前不支持带口令的私钥，因此专用密钥需要创建为无口令密钥：

ssh-keygen -t ed25519 \
  -f ~/.ssh/id_ed25519_edgessh_blog \
  -N '' \
  -C 'EdgeSSH blog server'

该命令会生成：

~/.ssh/id_ed25519_edgessh_blog       # 私钥，不可公开
~/.ssh/id_ed25519_edgessh_blog.pub   # 公钥，可以安装到服务器

确认私钥权限：

chmod 600 ~/.ssh/id_ed25519_edgessh_blog

九、把公钥安装到博客服务器

如果现有 SSH 快捷名称可以正常登录，可执行：

ssh blog-server \
  'umask 077; mkdir -p ~/.ssh; touch ~/.ssh/authorized_keys; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys; key=$(cat); grep -qxF "$key" ~/.ssh/authorized_keys || printf "%s\n" "$key" >> ~/.ssh/authorized_keys' \
  < ~/.ssh/id_ed25519_edgessh_blog.pub

这条命令会修正 SSH 目录权限，并在公钥已经存在时避免重复追加。然后使用新密钥直接测试。下面的 ssh-user 和 server.example.com 是文档示例，必须分别替换为真实 SSH 用户名和服务器地址：

ssh -i ~/.ssh/id_ed25519_edgessh_blog \
  -o IdentitiesOnly=yes \
  ssh-user@server.example.com

如果原有密钥已经丢失口令、Mac 也无法再登录，可以通过云服务商控制台的 VNC、WebShell 或救援终端进入服务器，再把 .pub 公钥追加到目标用户的：

~/.ssh/authorized_keys

安装的是 .pub 公钥，绝不能把私钥上传到服务器的 authorized_keys。

十、在 EdgeSSH 中添加博客服务器

在 EdgeSSH 主机页面点击添加主机，填写：

如果当前界面支持“密钥链”，可以在 EdgeSSH 中新建密钥，粘贴私钥并保存，再让主机引用该密钥。旧版界面则直接在主机的私钥输入框中粘贴。

如果 EdgeSSH 界面支持上传私钥文件，优先直接选择 ~/.ssh/id_ed25519_edgessh_blog，避免让无口令私钥经过系统剪贴板。

需要粘贴时，macOS 可以用下面的命令把专用私钥临时复制到剪贴板：

pbcopy < ~/.ssh/id_ed25519_edgessh_blog

复制后立即粘贴到 EdgeSSH，不要经过聊天软件、在线剪贴板或公开笔记。保存完成后立即清空剪贴板：

pbcopy </dev/null

同时关闭系统或第三方剪贴板工具对这次内容的历史记录与跨设备同步。

首次连接时，EdgeSSH 会显示服务器的 SHA-256 Host Key Fingerprint。应先在可信渠道核对服务器指纹，再点击确认；如果以后指纹突然变化，应停止连接并排查服务器是否重装、SSH Host Key 是否更换或是否存在中间人风险。

十一、常见问题

1. Deploy 上传成功，但最终显示红色

先检查日志末尾。常见原因包括：

• GH_CLIENT_ID 填成了说明文字，而不是真实 Client ID。
• GH_CLIENT_SECRET 与 Client ID 不属于同一个 OAuth App。
• workers.dev 子域的 DNS 或证书尚未就绪。
• OAuth App 仍使用 example.com 占位回调。

修正后直接重跑 Deploy，不要删除 Worker、D1 或 ENCRYPTION_KEY。

2. 提示 SSH authentication failed

说明网络和 SSH 握手通常已经建立，但用户名、密码或私钥不匹配。用 ssh -G your-host-alias 核对 Mac 实际使用的用户名、端口和密钥。

3. 提示 Encrypted private keys are not supported

说明粘贴的是带口令私钥。不要为了方便而解除日常主密钥的口令，建议重新生成一把 EdgeSSH 专用无口令密钥，并只把对应公钥安装到目标服务器。

4. 提示 An SSH connection is already being initialized

这通常是首次连接失败后自动重连产生的后续提示。应查看会话日志中最早出现的红色错误，解决真正原因，再关闭失败会话并重新连接。

十二、安全建议与适用边界

EdgeSSH 的 Worker 是实际 SSH 客户端，建立连接时必然会处理 SSH 凭据和会话数据。主机资料与私钥会加密后保存到 D1，但这不等同于端到端加密。只应部署在自己完全掌控的 Cloudflare 和 GitHub 账号中。

建议至少做到：

• GitHub 和 Cloudflare 均启用多因素认证。
• 每台服务器使用独立 SSH 密钥，方便单独撤销。
• 禁止 SSH 密码登录和 root 直接登录。
• 为 EdgeSSH 使用低权限系统用户，只授予必要的 sudo 权限。
• 定期同步上游安全更新并重新部署。
• 不把数据库、Redis、管理面板等内部端口直接开放到公网。

EdgeSSH 只支持连接可通过公网 SSH 访问的目标，并且当前不支持 ProxyJump。对于支付、发卡、财务或保存高价值数据的服务器，如果已经关闭公网 SSH，建议继续保持关闭，通过 VPN、私网、堡垒机或云厂商 VNC 管理，不要为了加入 EdgeSSH 而把 SSH 端口长期开放给互联网。

参考资料

• EdgeSSH 项目：https://github.com/aozorae/EdgeSSH
• EdgeSSH 部署文档：https://github.com/aozorae/EdgeSSH/blob/main/DEPLOYMENT.md
• Cloudflare Workers TCP Sockets：https://developers.cloudflare.com/workers/runtime-apis/tcp-sockets/
• GitHub-hosted runners 网络说明：https://docs.github.com/en/actions/reference/runners/github-hosted-runners