> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/openclaw_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/openclaw_guide/di-er-bu-fen-jin-jie-shi-yong/08_automation_ops/8.4_remote_access.md).

# 8.4 远程访问：SSH、内网穿透与零信任

本节讨论 OpenClaw 远程运维的目标：在保证可达性的前提下，尽量减少暴露面，并提供可快速吊销的访问机制。

> \[!NOTE] OpenClaw 已提供远程访问相关能力，包括 loopback Gateway WebSocket、SSH 隧道/远程默认配置、`gateway.mode: "remote"` / `gateway.remote.*`，以及可选的 OpenClaw 托管 Tailscale Serve/Funnel。隧道、零信任和凭据管理仍属于基础设施风险面，需要在宿主机和网络层面做最小暴露与可吊销设计。

## 8.4.1 入口原则：管理面默认不公网暴露

远程运维首先要控制入口暴露面。

* 不把管理端口长期暴露在公网。
* 管理面与业务面分离，避免同一入口承载高权限操作和对外业务流量。
* 访问链路必须可审计，能追溯“谁在何时做了什么”。

## 8.4.2 推荐拓扑：专用通道优先

**默认安全路径：SSH 隧道或 Tailscale Serve**

1. **SSH 隧道（Port Forwarding）**。对于仅需命令行排障或偶尔打开 Web 控制台的场景，通过堡垒机或跳板机进行 `ssh -L 18789:localhost:18789 user@host` 转发，实现安全轻量的本地访问。零额外依赖，是最通用的安全路径。
2. **Tailscale Serve（推荐）**。更准确的理解是：保持 Gateway 绑定 loopback，再由 `tailscale serve` 代为向 Tailnet 内部转发 Dashboard。它的核心价值不是“先暴露再限制”，而是“默认仍不公网暴露，只在受信网络内转发访问”，因此很适合长期运维场景。

**需要额外论证的例外路径：**

3. **Tailscale Funnel（公网暴露）**。与 Serve 不同，`tailscale funnel` 会把服务暴露到公网。只有在确实需要外部系统（如 Webhook 回调、第三方 CI/CD 触发）访问 Gateway 时才应启用；OpenClaw 管理的 Funnel 路径当前要求 `gateway.auth.mode: "password"`，应把“公网暴露 + 密码认证 + 最小化入口”视为一整套方案，而不是只补一条浏览器来源限制。
4. **临时端口转发（仅非 Serve/Funnel 场景）**。若确需直接绑定非环回（non-loopback）地址暴露 Dashboard，真正的第一道护栏应是 Gateway 认证（token、password 或明确的 trusted-proxy 身份边界）；`gateway.controlUi.allowedOrigins` 只解决浏览器来源约束，不应被理解为主要安全边界。

> \[!WARNING] Serve 和 Funnel 的安全边界完全不同：Serve 仅限 Tailnet 内部访问，Funnel 对公网开放。如果不确定，选 Serve。

> \[!NOTE] 使用 `openclaw gateway status --url ...`、`gateway call --url ...` 等显式 URL 参数时，CLI 不会回退读取配置或环境里的隐式凭据；必须同时传入 `--token` 或 `--password`。这是为了避免把本地凭据误发到非预期远端。

`gateway.remote.token` / `gateway.remote.password` 是远程 CLI 或客户端连接目标 Gateway 时使用的客户端凭据，不是服务端侧的认证策略本身。启用 Tailscale Serve 身份头时，Serve identity header 可用于 Control UI / WebSocket 的受信代理身份判断；HTTP API 面（如 Gateway API、工具调用或 Responses 兼容入口）仍应按 Gateway 正常 auth 规则传递 token/password 或其他受信凭据。

远程浏览器或远程节点接入时，还要区分“控制面地址”和“执行主机身份”：CLI 的 `--url` 只指定要连哪个 Gateway，不代表该 Gateway 会自动信任本机浏览器、节点或 shell 执行环境。生产环境应显式配置节点配对、设备身份和可审计的执行入口。

无论选型如何，核心是“先建受信网络，再放行管理操作”。

## 8.4.3 身份与权限：最小权限和短期凭据

远程访问建议采用：

* 禁用密码登录，使用密钥或证书认证。
* 按角色分配最小权限，不共用管理员账号。
* 使用短期凭据并定期轮换，降低泄露后影响范围。

## 8.4.4 文件同步方案：把远程成果拿回来

当 OpenClaw 部署在云服务器时，智能体整理的素材、报告、代码等成果都存储在远程硬盘上。工程实践中，推荐建立可控的文件双向同步机制，将“云端工作区”无缝映射到本地：

**1. rclone 远程挂载（强烈推荐）**

通过 `rclone mount` 将服务器上的工作区目录直接挂载为 Mac/Linux 本地磁盘。

* **优点**：免费、实时、原生支持，无需在服务器端安装同步守护进程（走原生 SFTP）。
* **优化参数经验**：默认挂载较慢且易断，建议增加 `--vfs-cache-mode full`（利用本地缓存提速读写）、`--sftp-connections 8`（增加并发数）、`--sftp-idle-timeout 0`（防止超时断联）。

**2. 坚果云等企业云盘同步**

在服务器与本地同时安装客户端，指定工作区目录进行双向同步。

* **优点**：搭建门槛极低，开箱即用。
* **缺点**：如果智能体高频读写或生成大量临时文件，容易耗尽同步流量池；冲突解决机制对开发者不够透明。

**3. 轻量级网盘服务（File Browser）**

如果只需要手机端偶尔查看文件，不需要重度编辑，可以在服务器裸起一个基于 Web 的文件浏览器（如 [File Browser](https://filebrowser.org/)），通过浏览器随时访问、下载生成的报告。需配合 8.4.1 的安全入口原则使用。

## 8.4.5 浏览器远程接管：节点主机与 KasmVNC

当前更推荐的远程浏览器路径是：在真正运行浏览器的机器上启动 OpenClaw node host，让 Gateway 通过已配对节点代理浏览器动作。这样浏览器控制流量仍留在受信网络内，通常不需要为了浏览器自动化开启 Funnel。KasmVNC 更适合处理验证码、二次确认或需要人工临时接管的场景。

当智能体在云端运行 L2（有头浏览器）进行自动化操作时，经常会遇到复杂验证码（如滑块、行为验证）或需要二次确认。如果仅依赖截图（L3），往往无法成功突破这些安全策略。

实践中，可以在服务器安装基于 Web 的远程桌面服务（如 [KasmVNC](https://kasmweb.com/)）。

1. 当智能体遭遇验证码界面时，通知用户。
2. 用户通过本地浏览器连接 KasmVNC，接管云端鼠标与键盘。
3. 协助智能体通过验证码后，关闭连接，智能体继续执行后续工具流程。

这种“平时无人干预，受阻时人工接管”模式是在自动化与安全性之间的一种实用平衡。

## 8.4.6 应急机制：可快速吊销与隔离

发生凭据泄露或可疑访问时，优先执行：

1. 吊销受影响凭据或设备信任。
2. 收敛入口策略，必要时临时阻断管理通道。
3. 回放审计日志，确认影响范围并复验恢复。

应急动作要预先演练，避免事故时临时决策。

## 8.4.7 基线巡检命令

下面命令可用于快速巡检主机远程访问基线。

```bash
# 检查 SSH 认证方式
sshd -T | grep -E 'passwordauthentication|pubkeyauthentication'

# 检查是否存在非本地监听端口
lsof -nP -iTCP -sTCP:LISTEN | grep -Ev '127\.0\.0\.1|localhost|::1|\[::1\]' || echo "No public listeners"
```

巡检建议固定在发布后和变更后执行，并与 `doctor/status` 输出一起归档。