【安全】OpenClaw 安全配置基础

海兰2026-03-21 8:28

  • 在AI代理技术飞速发展的2026年，OpenClaw因其强大的执行能力和易用性迅速成为个人和企业用户的热门选择。然而，随之而来的安全问题也引发广泛关注。根据最新安全审计报告，超过4万个OpenClaw实例暴露于公网，其中63%存在可被利用的漏洞，超过1.2万个实例被标记为可远程控制。这表明安全配置绝非可选项，而是OpenClaw部署的必备基础 。

  • 本文将深入解析OpenClaw的安全边界构建，重点从Gateway认证、allowlist机制、Control UI暴露方式和SSH/Tailscale接入策略四个维度，帮助用户建立安全防护的第一道防线。

一、安全架构与核心原则

OpenClaw是一个开源的AI代理框架，由奥地利程序员彼得·斯坦伯格开发，最初名为Clawdbot，后更名为OpenClaw。它采用"本地优先、安全可控、开箱即用"的设计理念，主要由四个核心组件构成：

  • Gateway：作为消息网关和会话协调器，负责接收来自各种通信渠道的输入
  • Agent：执行具体任务的智能体，基于大型语言模型API进行决策和操作
  • Skills：可扩展的技能系统，通过Markdown文件描述特定领域的操作流程
  • Memory ：负责存储和管理代理的记忆数据

OpenClaw的安全防护重点不在于"有没有一个安全页"，而在于你是否真正理解了Gateway的暴露面。官方文档反复强调同一件事：Gateway和dashboard都是高权限入口，不应该默认暴露到公网。

三条核心黄金安全原则：

  1. Gateway默认应尽量保持loopback绑定：即绑定到本地回环地址127.0.0.1，而非所有网络接口
  • 默认只让服务器本机自己能摸到Gateway，外面的网络哪怕是同局域网的设备，都碰不到它。
  • TCP/IP协议中，127.0.0.1（loopback回环地址）的流量完全不会经过网卡，不会出现在任何外部网络中。哪怕你的服务器被全网端口扫描，都扫不到这个绑定的端口，默认攻击面直接归0。反过来，如果你直接绑定0.0.0.0（所有网卡），就相当于把家门装在了大马路上，哪怕有锁，也会24小时被人暴力撬锁，风险指数级上升。
  1. dashboard属于管理面，不是普通访客页面：它不仅能聊天，还能修改配置、查看会话、处理执行审批
  • 这是90%的人踩的第一个坑：很多人把dashboard当成ChatGPT一样的聊天页面，随便分享给朋友用。但你必须清楚：dashboard是root级别的管理员控制台，它不仅能聊天，还能修改你所有的配置、查看全量历史会话、审批Agent执行的高危命令（比如删服务器文件、调用付费API）。它不是你家的客厅会客室，而是你家的物业总控室------能开全楼的门、拉全楼的电闸，绝对不能随便让人进。
  1. 渠道一旦接通，就要立即考虑allowlist、提及规则和认证方式：避免渠道一接通就变成"谁都能触发的机器人"
  • OpenClaw的渠道（WhatsApp/Telegram/微信等）一接通，就相当于你在墙上开了个新窗口，这个窗口默认是无阻拦的，谁都能往里递东西触发你的Agent干活。顺序绝对不能反：先装护栏，再开窗口，而不是先开窗口再补护栏。否则你刚接通渠道，还没来得及配置，就会被全网爬虫扫到，轻则刷爆你的API账单，重则直接控制你的服务器。

这三条原则，是所有安全配置的底层逻辑，比任何冗长的checklist都重要。

二、保护Gateway和dashboard：安全边界的起点

1. Gateway的默认配置与风险

在讲具体配置前，我们先通过一张架构图，搞清楚所有组件的权限关系和攻击面，一眼看懂为什么Gateway是安全核心。

图示：OpenClaw核心安全边界架构图
Plain 复制代码 
┌─────────────────────────────────────────────────────────────┐
│                公网/外部网络（不可信区域）                  │
└───────────────────────┬─────────────────────────────────────┘
                        │ 仅允许加密隧道流量，其余默认拦截
┌───────────────────────▼─────────────────────────────────────┐
│              系统防火墙/反向代理（第一道物理防线）           │
└───────────────────────┬─────────────────────────────────────┘
                        │ 仅可信流量可进入
┌───────────────────────▼─────────────────────────────────────┐
│  接入渠道层（WhatsApp/Telegram等）  │  远程管理接入层      │
│  （仅白名单用户可触发）             │ （SSH隧道/Tailscale） │
└───────────────────────┬─────────────────────────────────────┘
                        │ 所有流量必须经过Gateway校验
┌───────────────────────▼─────────────────────────────────────┐
│                OpenClaw Gateway（唯一总入口）                │
│        【认证模块】【白名单校验】【权限管控核心】           │
└───────────┬─────────────────────────────────┬───────────────┘
            │                                 │
┌───────────▼───────────────┐   ┌───────────▼───────────────┐
│  Control UI / dashboard   │   │  核心执行层（Agent/技能/  │
│  【最高权限管理面】        │   │  配置/会话数据）           │
└───────────────────────────┘   └───────────────────────────┘
  • 这张图直接点明了核心：Gateway是所有流量的唯一入口，Gateway的暴露面，就是你整个OpenClaw系统的攻击面。所有的安全配置，都是围绕着给Gateway加锁、缩小它的暴露面来做的。
第一道防线------锁死Gateway与dashboard的默认暴露

gateway.bind是Gateway的核心配置项，它的作用是告诉Gateway：你要监听服务器上哪个网卡的哪个端口。我们用一张对比，直接看懂不同绑定地址的安全差异。

不同bind地址的暴露面对比
绑定地址 可访问范围 安全等级 适用场景 风险说明
127.0.0.1:18789 仅服务器本机 ⭐⭐⭐⭐⭐ 默认推荐、所有场景 流量不离开服务器，公网完全扫不到，零攻击面
192.168.1.100:18789 仅同局域网设备 ⭐⭐⭐ 纯内网家庭/办公环境 局域网内设备可访问，有内网横向攻击风险
0.0.0.0:18789 全网所有设备（含公网） ⭐ 绝对不推荐默认使用 公网可直接扫描到，24小时面临暴力破解风险
最安全的默认姿势
  1. 配置文件中，gateway.bind永远保持127.0.0.1:18789，不做任何修改；
  2. 本地直接在服务器上访问127.0.0.1:18789，流量全程不离开服务器，无任何窃听、拦截风险；
  3. 远程访问绝对不修改bind地址，而是通过加密隧道接入（后面会详细讲SSH和Tailscale）。
  • 这里补全一个很多人忽略的细节：哪怕你只在内网使用，也不建议直接绑定局域网IP，优先用SSH隧道（可以参见【应用】打造你的安全本地AI购物助手：OpenClaw + 淘宝MCP部署全攻略中隧道的使用祥例）或Tailscale接入内网，始终保持Gateway的loopback绑定，把暴露面缩到最小。
  • OpenClaw的Gateway默认监听地址为0.0.0.0:18789，这意味着它将监听服务器的所有网络接口。这带来了一个严重问题：如果服务器位于公网，任何知道IP地址和端口的人都可以尝试访问Gateway，这可能导致未授权访问、API密钥泄露甚至完全控制OpenClaw实例。

安全加固措施：

  • 修改监听地址 ：将Gateway绑定到本地回环地址127.0.0.1，限制仅本地访问

    bash 复制代码 
    # 方法一：通过CLI配置
openclaw config set gateway.bind loopback

# 方法二：手动编辑配置文件
nano ~/.openclaw/openclaw.json

    在配置文件中添加或修改：

    json 复制代码 
    {
  "gateway": {
    "bind": "loopback",
    "port": 18789
  }
}

    修改后重启网关服务：

    bash 复制代码 
    openclaw gateway restart

  • 使用防火墙限制访问：即使修改了绑定地址，仍建议通过防火墙进一步限制

    bash 复制代码 
    # 使用ufw限制访问（我这里举Ubuntu系统为例，我自己使用的是这个Ubuntu24.04版本）
sudo ufw deny 18789
sudo ufw allow from 127.0.0.1 to any port 18789
2. Dashboard的保护策略

Dashboard是OpenClaw的Web管理界面，默认运行在http://127.0.0.1:18789。它属于管理面，具有最高权限，能够修改配置、查看所有会话记录和审批敏感操作。因此，保护Dashboard同样至关重要。

安全访问方式：

  • 本地直接访问 ：最安全的方式是通过本地机器访问http://127.0.0.1:18789

  • SSH隧道：远程访问时，优先使用SSH隧道建立加密连接

    bash 复制代码 
    ssh -N -L 18789:127.0.0.1:18789 user@server_ip -p 22

    这会将本地的18789端口映射到服务器的127.0.0.1:18789，通过SSH加密通道访问。

  • Tailscale Serve：对于需要远程安全访问的场景，可使用Tailscale的Serve功能

    bash 复制代码 
    tailscale serve 18789

    这将创建一个Tailscale网络内的子域名，允许通过Tailscale网络访问Dashboard。

三、认证机制：安全访问的第二道门，先开认证，再谈远程访问

  • 哪怕你非要开放远程访问，也必须遵守一个铁则：先配置认证，再开放访问 ，顺序绝对不能反。官方把认证的核心能力都放在了gateway.auth配置项中，所有访问请求必须先经过auth模块校验通过，才能进入系统，相当于你家大门的门锁。
1. 认证模式概览

OpenClaw提供三种主要的认证模式：

Token模式：使用预设的Token进行身份验证，适合个人使用、小团队内部使用，配置最简单，安全性最高（只要token足够复杂且不泄露）。

  1. 给Gateway设置一个超长的随机字符串密钥，所有访问请求必须在HTTP
    Header中带上这个token，或是访问dashboard时输入这个token，才能通过校验。相当于你家大门的门禁密码，只有知道密码的人才能进。
  2. token必须使用16位以上的随机强密码，组合字母+数字+特殊符号，绝对不能用123456、admin这类弱密码；
  3. 优先通过环境变量OPENCLAW_GATEWAY_TOKEN传入token，不要写死在配置文件里，避免不小心提交到公开代码仓库泄露；
  4. 定期更换token，更换后所有已登录的浏览器会自动失效，必须重新输入新token才能登录。

密码模式：使用用户名和密码进行验证，提供更细粒度的权限控制，小团队多人管理使用，需要区分不同管理员的操作权限和访问记录。

和token模式逻辑一致，但采用「用户名+密码」的形式，支持给不同的管理员设置不同的账号密码，可区分访问身份，相当于给家里不同的人配了不同的门禁卡。

Trusted-Proxy模式：信任特定代理服务器传递的身份信息，需谨慎配置（高敏感，非必要不启用）

  1. 这是官方明确标注的安全敏感功能，也是最容易踩坑的配置，90%的安全事故都出自这里，我必须把原理和红线讲透。
  2. 大白话讲：你找了一个绝对靠谱的保镖（反向代理，比如Nginx、Cloudflare
    Access），这个保镖已经在门口把所有人的身份都核验完毕，确认是可信人员，才会把人带到Gateway门口，然后跟Gateway说："这个人我已经验过了，绝对可信，你直接放行"。Gateway会100%信任这个保镖的话，不再做二次身份校验。
  3. 这个模式的风险点非常明确：如果你的保镖不靠谱，或是Gateway认错了保镖，坏人就可以冒充保镖，直接绕过所有认证，进入你的系统。相当于你把家门的开锁权限给了一个陌生人，还跟门锁说"只要是这个人带来的，都直接开门"。
2. Token模式配置

Token模式是最简单直接的基础认证方式，特别适合个人用户和小团队。以下是配置步骤：

  • 生成Token ：

    bash 复制代码 
    # 通过命令行生成

openclaw config set gateway.auth.mode token

openclaw config set gateway.auth.token $(openssl rand -base64 16 | tr -dc 'a-zA-Z0-9' | head -c 16)

  • 或通过Python生成（推荐）
    python3 -c "import secrets; print(secrets.token_hex(16)); openclaw config set gateway.auth.token $(secrets.token_hex(16))

    • 配置Token访问：在配置文件中启用Token认证
    json 复制代码 
    {
  "gateway": {
    "auth": {
      "mode": "token",
      "token": "生成的16位Token"
    }
  }
}

使用Token访问Dashboard ：访问http://127.0.0.1:18789/?token=你的Token，或通过openclaw dashboard命令启动并自动注入Token。

重要注意事项 ：Token会被前端保存到浏览器本地存储中，因此不要在不受控的公共机器上长期登录Dashboard，使用完毕后应清除浏览器缓存。

3. 密码模式配置

密码模式提供了更精细的权限控制能力，适合需要多用户访问的场景：

  • 配置密码认证：

    json 复制代码 
    {
  "gateway": {
    "auth": {
      "mode": "password",
      "users": [
        {
          "username": "your_username",
          "password": "your_strong_password",
          "permissions": ["*"]  // 权限范围
        }
      ]
    }
  }
}

  • 权限控制 ：通过permissions字段限制用户的操作范围，可以使用通配符或具体权限名称

    json 复制代码 
    "permissions": ["channel:whatsApp", "model:openai", "!tool:shell"]  // 示例：允许WhatsApp渠道和OpenAI模型，但禁止shell工具
4. Trusted-Proxy模式的使用与风险

Trusted-Proxy模式允许通过已认证的反向代理访问Gateway，官方明确的4个必填前提，缺一个都绝对不能启用：

  1. 你的反向代理本身已经完成了强身份认证：比如你的Nginx已经配置了账号密码，或是Cloudflare Access已经做了企业级SSO登录，绝对不能是只转发流量、不做认证的裸反向代理------否则这个保镖就是个摆设，什么人都放进来。

  2. Gateway只有这一条代理入口：Gateway必须只能通过这个反向代理访问，不能直接绑定公网，不能有其他任何入口，否则坏人可以直接绕开保镖，闯你的大门。

  3. trustedProxies 只包含最小的代理IP范围 ：比如你的反向代理IP是10.0.0.2，那你就只能填10.0.0.2/32（单个IP），绝对不能填10.0.0.0/24这类大网段，更不能填0.0.0.0/0------否则坏人只要伪造一个同网段的IP，就能冒充保镖。

  4. 代理会覆盖而非拼接转发头 ：HTTP的X-Forwarded-For头是用来记录客户端真实IP的，如果代理是拼接模式，坏人可以在请求里自己伪造这个头，代理会把它拼在后面，Gateway就会误判；只有代理覆盖了这个头，填入自己验证过的真实IP，坏人才能无法伪造。

  • 配置示例 ：

    json 复制代码 
    {
  "gateway": {
    "auth": {
      "mode": "trusted-proxy",
      "trustedProxies": ["10.0.0.0/8", "192.168.0.0/16"]
    }
  }
}
图示：trusted-proxy模式正确与错误配置对比
Plain 复制代码 
【正确配置】
┌──────────┐    强身份认证    ┌──────────┐    仅允许代理IP    ┌──────────┐
│  用户端  │ ───────────────→ │ 反向代理 │ ─────────────────→ │ Gateway  │
└──────────┘                  └──────────┘                    └──────────┘
✅ 代理已完成身份校验
✅ trustedProxies仅填代理单个IP
✅ 无其他入口，流量必须经过代理

【错误配置】
┌──────────┐    无认证直接转发 ┌──────────┐    全网段信任      ┌──────────┐
│  用户端  │ ───────────────→ │ 反向代理 │ ─────────────────→ │ Gateway  │
└──────────┘                  └──────────┘                    └──────────┘
     ↓ 坏人直接绕开代理，公网直连Gateway
┌──────────┐                  0.0.0.0/0全信任                 ┌──────────┐
│  攻击者  │ ───────────────────────────────────────────────→ │ Gateway  │
└──────────┘                                                    └──────────┘
❌ 代理无身份认证
❌ trustedProxies配置大网段/全网段
❌ Gateway直接暴露公网，可绕开代理
**安全建议**：如果对代理服务器的安全性不完全确定，**不要启用Trusted-Proxy模式**。对于大多数用户，Token或密码模式已经足够安全。

四、第三道防线------allowlist机制：控制谁可以与你的助手交互（可以参看【频道】防入侵！OpenClaw 本地部署对接 QQ：从部署到安全权限锁死全流程）

1. allowlist的基本原理
  • 很多人刚接入渠道就踩坑：刚把QQ/钉钉/飞书/WhatsApp/Telegram机器人接通，还没玩明白，就被陌生人刷爆了API账单，甚至触发了高危命令。核心原因就是：渠道一接通，默认是"谁都能触发"的，必须先配好白名单，再上线渠道。
  • allowlist是一种白名单机制，用于限制只有特定用户或设备可以与OpenClaw交互。它是防止OpenClaw被未授权访问的防线，尤其在公网上暴露时至关重要。

核心作用：

  • 限定谁可以和你的助手交互
  • 限定群聊中何时才响应
  • 避免渠道一接通就变成"谁都能触发的机器人"

OpenClaw的channels（渠道），就是把你的Agent接入到各类聊天平台，相当于你在不同平台开了客服窗口。安全配置的核心，就是给这个窗口加两个规则：

  1. 身份白名单：只允许你指定的人/号码能和机器人说话，其他人直接拦在门外；

  2. 响应规则：哪怕是在允许的群聊里，也只有明确@你的时候才响应，避免误触发和恶意触发。

我们直接拆解官方给出的示例配置，每一行都讲透它的作用和原理：

JSON 复制代码 
{
  "channels": {
    "whatsapp": {
      // 核心白名单：仅允许这个手机号给机器人发消息，其他所有号码的消息直接拒收
      "allowFrom": ["+15555550123"],
      "groups": {
        // 所有群聊中，必须@机器人，它才会响应，否则群内消息完全不处理
        "*": { "requireMention": true }
      }
    }
  },
  "messages": {
    "groupChat": {
      // 定义触发响应的@规则，只有@openclaw时，才会触发机器人回复
      "mentionPatterns": ["@openclaw"]
    }
  }
}
图示：渠道allowlist安全逻辑图
Plain 复制代码 
┌─────────────────────────────────────────────────────────────┐
│                    OpenClaw 机器人核心                        │
└───────────▲───────────────────────────────▲─────────────────┘
            │                               │
            │ 放行                          │ 放行
┌───────────┴───────────┐       ┌───────────┴───────────┐
│  白名单内的个人用户    │       │  群聊内@机器人的消息   │
└───────────────────────┘       └───────────────────────┘
            × 拦截                          × 拦截
┌───────────────────────┐       ┌───────────────────────┐
│  陌生用户/非白名单号码 │       │  群聊内未@的普通消息   │
└───────────────────────┘       └───────────────────────┘
补充配置要点与避坑指南

  1. 所有渠道都有对应的白名单配置：除了QQ、钉钉、飞书、WhatsApp，Telegram的allowFrom填用户ID，Discord填用户Snowflake ID，企业微信填用户账号，原理完全一致，先配白名单，再接通渠道。

  2. 群聊必须开启requireMention: true：否则机器人会响应群里的所有消息，轻则刷屏打扰群友，重则被群内陌生人恶意触发，执行高危操作。

  3. 白名单要遵循最小权限原则：只添加必须要使用的用户/号码，不要添加大的范围，避免权限溢出。

2. 不同渠道的allowlist配置

OpenClaw支持多种消息渠道，每种渠道的allowlist配置略有不同：

WhatsApp配置示例：

json 复制代码 
{
  "channels": {
    "whatsapp": {
      "allowFrom": ["+15555550123"],
      "groups": {
        "*": { "requireMention": true }
      }
    }
  }
}
  • allowFrom：指定允许私聊的WhatsApp号码
  • groups：定义群组响应规则，*表示所有群组，requireMention为true时，只有@提及机器人时才会响应

Telegram配置示例：

json 复制代码 
{
  "channels": {
    "telegram": {
      "groupPolicy": "allowlist",
      "groups": {
        "-51xxx": { "requireMention": true },  // 普通群组ID
        "-10051xxx": { "requireMention": false }  // 超级群组ID
      }
    }
  }
}
  • 关键区别 ：Telegram的群组控制通过groupPolicy和groups对象实现，私聊白名单通过allowFrom字段
  • 配置要点：Telegram Bot默认开启隐私模式，需在@BotFather中关闭Group Privacy并重新拉入群组

Slack配置示例：

json 复制代码 
{
  "channels": {
    "slack": {
      "allowFrom": ["U12345678", "W23456789"],
      "groups": {
        "C34567890": { "requireMention": true }
      }
    }
  }
}
3. 交互限制规则的扩展应用

allowlist机制可以与其他安全规则结合使用，实现更精细的交互控制：

群组@提及规则：

json 复制代码 
{
  "messages": {
    "groupChat": {
      "mentionPatterns": ["@openclaw"]
    }
  }
}
  • 仅当消息中包含指定@提及模式时，机器人会响应

私聊配对机制：

json 复制代码 
{
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing"
    }
  }
}
  • 新用户发送私聊消息时，需要通过配对码确认，防止骚扰

复合规则应用：可以结合allowlist与时间限制，实现更灵活的访问控制

json 复制代码 
{
  "session": {
    "reset": {
      "mode": "daily",
      "atHour": 4  // 凌晨4点重置记忆
    }
  }
}

五、第四道防线------远程访问的安全首选：SSH隧道与Tailscale远程访问策略（可以参见【应用】打造你的安全本地AI购物助手：OpenClaw + 淘宝MCP部署全攻略中隧道的使用典型例子）

  • 很多人会问：我不在服务器本机，怎么访问dashboard？官方说不要直接绑公网，那正确的姿势是什么？

  • 核心答案是：不直接暴露Gateway到公网，而是先通过加密、有认证的隧道，进到服务器的本机环境，再访问Gateway。相当于你不把家门开在大马路上，而是让远程的人先通过一条加密的地下通道进到你家院子，再开家门------这条地下通道本身有严格的认证和加密，外面的人看不到，也进不来。

  • 官方首推两种远程访问方式：SSH隧道（最通用）、Tailscale（最适合团队/多设备），我们分别讲透原理和用法。

1. 远程访问的核心原则

OpenClaw官方远程访问文档明确指出：优先保留Gateway在专用主机，客户端通过SSH tunnel或Tailscale接入。这意味着，即使需要远程访问，也应避免直接将Gateway暴露到公网。

远程访问策略应遵循以下原则：

  • 网关应保持loopback绑定，仅监听本地
  • 远程访问应通过加密隧道建立
  • 不要使用Funnel直接公网暴露，除非必要
  • 首选SSH tunnel或Tailscale Serve作为远程接入路径
2. SSH隧道：最通用、最稳、零依赖的方案

  • 几乎所有Linux服务器都自带SSH服务，不需要安装任何额外软件，零成本、强加密、零公网暴露，是个人使用的首选方案。

  • SSH是通用、稳定且广泛支持的远程接入方式，适合大多数用户。

  • SSH是银行级加密的远程登录协议，SSH的本地端口转发（-L参数），会把你本地电脑的一个端口，通过加密的SSH隧道，直接转发到远程服务器的127.0.0.1:18789端口。也就是说，你在本地电脑访问127.0.0.1:18789，流量会全程加密，通过SSH隧道直接送到远程服务器的Gateway端口，Gateway全程绑定127.0.0.1，公网完全扫不到，完美符合黄金原则。

  • 基础SSH隧道配置：

    bash 复制代码 
    # 基本SSH隧道命令
ssh -N -L 18789:127.0.0.1:18789 user@server_ip -p 22

# 带密钥认证的SSH隧道（推荐）
ssh -i ~/.ssh/id_ed25519 -N -L 18789:127.0.0.1:18789 openclaw_user@server_ip -p 22

  • -N：不打开远程服务器的命令行，只做端口转发，不会进入服务器shell，更安全；

  • -L 本地端口:远程绑定IP:远程端口：本地端口转发的核心参数，这里就是把本地的18789端口，转发到远程服务器127.0.0.1的18789端口；

  • openclaw_user@server_ip：远程服务器的用户名和IP/域名。

  • SSH服务加固：

    bash 复制代码 
    # 禁用root登录
sudo sed -i 's/^PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config

# 创建专用用户运行OpenClaw
sudo adduser --shell /bin/rbash --disabled-password clawuser
sudo chown clawuser:clawuser /home/clawuser

# 限制命令执行（可选）
sudo mkdir -p /home/clawuser/bin
sudo ln -s /bin/ls /home/clawuser/bin/ls
sudo ln -s /bin/echo /home/clawuser/bin/echo
sudo ln -s /usr/bin/curl /home/clawuser/bin/curl

# 修改环境变量限制PATH
echo 'if [ "$USER" = "clawuser" ]; then export PATH=/home/clawuser/bin; readonly PATH; fi' | sudo tee -a /etc/profile.d/restricted_clawuser.sh
sudo chmod 644 /etc/profile.d/restricted_clawuser.sh

SSH远程访问流程：

  1. 在服务器上安装并配置SSH服务
  2. 生成SSH密钥对（推荐使用ed25519算法）
  3. 将公钥复制到服务器的~/.ssh/authorized_keys文件中
  4. 通过SSH隧道命令建立加密连接
  5. 在本地浏览器访问http://127.0.0.1:18789，并提供网关认证信息
优势

  • 零成本：所有服务器自带SSH，无需额外安装软件；

  • 强加密：全程银行级加密，流量不会被窃听、篡改；

  • 强认证：支持SSH密钥登录，比密码更安全，完全杜绝暴力破解；

  • 零暴露：Gateway全程绑定127.0.0.1，公网无任何暴露，攻击面为0。

3. Tailscale远程访问配置-官方首推的团队/多设备方案

  • Tailscale是一种更现代的点对点网络工具，提供基于TLS的加密连接和自动IP管理：

  • Tailscale是零配置的Mesh VPN，能把你的电脑、手机、服务器等所有设备，都加到同一个加密的虚拟局域网里，哪怕设备在全世界不同的地方，都能像在同一个局域网里一样互相访问，全程端到端加密，不需要公网IP，不需要端口映射。

  • Tailscale Serve配置（推荐）：

bash 复制代码 
  # 安装Tailscale
  tailscale up

  # 开启Dashboard的Tailscale访问
openclaw config set gateway.auth_allowTailscale true

  # 启用Tailscale的Serve功能
  tailscale serve 18789

  # 重启网关服务
 openclaw gateway restart
  • Tailscale Funnel配置（仅限必要情况）：
bash 复制代码 
  # 开启Funnel功能
  tailscale funnel 18789

  # 在网关配置中启用密码认证
 openclaw config set gateway.auth.mode password
 openclaw config set gateway.auth users "[{username: 'admin', password: 'strong_password'}]"

  # 重启网关服务
 openclaw gateway restart

Tailscale与SSH的对比：

特性 SSH Tailscale
部署复杂度 低 中
加密强度 强 强
访问控制 基于IP和用户 基于Tailscale网络和身份
维护成本 低 中（需管理Tailscale账号）
适合场景 简单的点对点访问 多设备、多环境的网络访问

如下图所示：

图示：SSH隧道 vs Tailscale 远程访问原理对比
Plain 复制代码 
【SSH隧道方案】
┌──────────────┐    端到端加密隧道    ┌──────────────┐
│  本地电脑    │ ───────────────────→ │ 远程服务器   │
│ 127.0.0.1:18789 │ ←───────────────→ │ 127.0.0.1:18789 │
└──────────────┘                      └──────────────┘
✅ 公网无Gateway暴露，仅开放SSH 22端口
✅ 全程加密，强身份认证

【Tailscale Serve方案】
┌──────────────┐    加密虚拟局域网    ┌──────────────┐
│  本地电脑/手机│ ←──────────────────→ │ 远程服务器   │
│ Tailscale内网IP │                    │ 127.0.0.1:18789 │
└──────────────┘                      └──────────────┘
✅ 公网无任何暴露，仅Tailscale授权设备可访问
✅ 支持身份自动校验，无需额外token

【Tailscale Funnel方案（高危）】
┌──────────────┐    公网可访问        ┌──────────────┐
│  全网任意设备 │ ───────────────────→ │ 远程服务器   │
│ 公网Funnel域名 │                    │ Gateway服务   │
└──────────────┘                      └──────────────┘
❌ 公网直接暴露，面临暴力破解风险
⚠️  必须配置强password认证，非必要不启用
4. 安全访问路径选择建议

根据使用场景和安全需求，OpenClaw官方建议以下访问路径选择：

  • 个人用户：首选SSH隧道或Tailscale Serve，提供简单安全的远程访问
  • 小团队协作：考虑Tailscale Serve，便于团队成员共享访问权限
  • 企业生产环境：建议使用SSH隧道+专用用户+IP白名单，实现最细粒度的访问控制
  • 绝对避免：直接将Gateway绑定到公网IP且不配置任何认证，这是最危险的配置

六、Control UI/Dashboard的安全使用与维护

1. Dashboard的认证方式

Dashboard支持多种认证方式，根据配置文件中的设置自动选择：

  • Token认证：通过URL参数或环境变量提供
bash 复制代码 
  # 生成Token
 openclaw token generate
 
  # 通过URL访问
 浏览器打开 http://127.0.0.1:18789/?token=生成的Token

  # 或通过环境变量
  export OPENCLAW_GATEWAY_TOKEN="生成的Token"
 openclaw dashboard
  • 密码认证：需提前在配置文件中设置用户
bash 复制代码 
  # 访问Dashboard后输入用户名和密码
 openclaw dashboard

重要提示 ：Dashboard的Token会被前端保存到浏览器本地存储中，这意味着在公共或共享设备上使用Dashboard后，应清除浏览器缓存，防止Token被窃取。

2. 配置文件的热重载与验证

OpenClaw支持配置文件的热重载功能，大部分配置修改后无需重启服务即可生效：

  • 配置热重载：修改配置文件后，保存即可自动重载
  • 需要重启的配置：某些核心配置（如网关绑定地址、端口）修改后需要重启
bash 复制代码 
  # 检查配置语法
 openclaw  config validate
  # 重启网关服务
 openclaw  gateway restart
  # 检查服务状态
 openclaw status

  • 配置诊断工具 ：使用openclaw doctor --fix命令修复配置问题

    bash 复制代码 
    openclaw doctor --fix  # 自动修复可识别的配置问题

七、dashboard的token管理与敏感环境注意事项

dashboard的token，就是Gateway的最高权限密钥，只要有这个token，就能完全控制你的OpenClaw实例，相当于你家保险柜的密码，绝对不能泄露。

token的三种获取方式

  1. 运行openclaw dashboard命令：自动启动Gateway，生成临时token，自动打开浏览器并填充token，直接登录dashboard，适合本地临时使用，最方便；

  2. 读取配置文件中的gateway.auth.token：如果你在配置文件中固定了token，直接读取该值即可，适合固定部署场景；

  3. 通过环境变量OPENCLAW_GATEWAY_TOKEN传入：Docker/systemd部署的首选方式，比写在配置文件里更安全，避免泄露。

核心安全注意事项

  1. token会被前端保存在浏览器的LocalStorage中：只要你在这个浏览器登录过dashboard，哪怕关掉页面，下次打开还是能直接登录，无需重新输入token。绝对不要在公共电脑、网吧、他人设备上登录dashboard，非要临时使用，必须用浏览器无痕模式，用完直接关闭无痕窗口，token会自动清除，不会被保存。

  2. 绝对不要把token提交到公开代码仓库：GitHub/Gitee上有无数爬虫24小时扫描公开仓库里的密钥、token，只要你提交上去，几秒钟内就会被扫到，直接导致实例被入侵。

  3. 最小范围分享token：只给必须的管理员，绝对不要把token分享给普通用户，普通用户只需要给他们开放配置好白名单的渠道即可。

八、生产环境的安全加固建议

1. 持续安全维护策略

安全不是一次性配置，而是需要持续维护的过程。建议的定期维护任务包括：

频率 任务 重要性
每日 检查异常登录日志 ⭐⭐⭐⭐⭐
每周 审查敏感操作记录 ⭐⭐⭐⭐
每月 更新系统和插件 ⭐⭐⭐⭐⭐
每月 轮换API密钥和Token ⭐⭐⭐⭐
每季度 全面安全审计 ⭐⭐⭐⭐⭐
每季度 备份配置和数据 ⭐⭐⭐⭐⭐
2. 最小权限原则的实现

最小权限原则是OpenClaw安全的核心，应体现在以下方面：

  • 文件系统权限：为OpenClaw创建专用工作目录，并限制其访问范围

    bash 复制代码 
    # 创建专用工作目录
mkdir -p ~/openclaw Workspace
chown clawuser:clawuser ~/openclaw Workspace
chmod 700 ~/openclaw Workspace

  • 工具权限白名单：在技能（Skills）配置中明确声明所需权限

    json 复制代码 
    {
  "permissions": {
    "network": ["https://api.example.com"],
    "filesystem": {
      "read": ["/var/openclaw/data/input"],
      "write": ["/var/openclaw/data/output"]
    }
  }
}

  • 技能权限审查：定期检查已安装技能的权限要求

bash 复制代码 
 openclaw skills list --permissions  # 查看所有技能的权限要求
3. 网络安全加固

除了上述配置外，生产环境还应实施以下网络安全加固措施：

  • 网络隔离：将OpenClaw部署在专用网络或虚拟机中，与核心业务系统隔离

  • 访问控制：通过防火墙限制仅允许特定IP访问SSH等管理端口

    bash 复制代码 
    # 限制SSH访问到特定IP（Ubuntu系统）
sudo ufw deny 22
sudo ufw allow from 203.0.113.0/24 to any port 22

  • 日志审计：启用详细日志记录，并定期检查异常活动

bash 复制代码 
  # 查看网关日志
  tail -f ~/.openclaw/logs/openclaw.log
  
  # 执行安全审计
 openclaw security audit  # 检查常见配置风险

  • 如果你不是本地测试玩一玩，而是要把OpenClaw放在服务器上7x24小时长期运行，给团队使用，官方推荐了一套标准化的生产级安全部署方案，我们讲透每一部分的作用和原理。

  • 官方推荐的生产部署架构：openclaw-ansible + 系统防火墙 + Docker沙箱 + systemd + SSH/Tailscale远程管理，如下图所示：

图示：生产环境OpenClaw安全部署架构图
Plain 复制代码 
┌─────────────────────────────────────────────────────────────┐
│                公网/外部网络（不可信区域）                  │
└───────────────────────┬─────────────────────────────────────┘
                        │ 仅开放SSH 22端口、Tailscale端口
                        │ 其余所有端口默认拒绝
┌───────────────────────▼─────────────────────────────────────┐
│                UFW/系统防火墙（第二道防线）                  │
└───────────────────────┬─────────────────────────────────────┘
                        │ 仅可信流量可进入隔离环境
┌───────────────────────▼─────────────────────────────────────┐
│            隔离运行层（Docker沙箱/非root用户）               │
│        最小权限运行，避免入侵后影响整个服务器                │
└───────────────────────┬─────────────────────────────────────┘
                        │ 仅本地回环地址可访问
┌───────────────────────▼─────────────────────────────────────┐
│                OpenClaw Gateway（核心入口）                  │
│        绑定127.0.0.1 + 强认证 + 渠道全量白名单             │
└───────────────────────┬─────────────────────────────────────┘
                        │ 仅加密隧道可访问管理面
┌───────────────────────▼─────────────────────────────────────┐
│              Control UI / dashboard（管理面）                │
│  仅通过SSH隧道/Tailscale虚拟局域网访问，公网完全不可见       │
└─────────────────────────────────────────────────────────────┘
每一部分的核心作用

  1. openclaw-ansible：官方提供的自动化部署脚本，会自动帮你完成所有安全配置，包括防火墙配置、systemd服务设置、SSH配置、强token生成，避免手动配置出错、漏掉安全项，相当于官方给你装了一套标准化的安保系统，比自己手工配置靠谱得多。

  2. UFW/系统防火墙：Linux系统自带的防火墙，在系统层面把所有不需要的端口全部关掉，只开放SSH 22端口和Tailscale需要的端口，其余所有端口默认拒绝外部访问。相当于你家小区的围墙，哪怕家门没锁好，也能把坏人拦在外面，多一层兜底防护。

  3. Docker沙箱：用Docker部署OpenClaw，会把服务运行在隔离的沙箱环境中，哪怕OpenClaw被入侵，攻击者也只能在Docker容器内活动，无法直接控制整个服务器，相当于你把保险柜放在了单独的密室里，哪怕坏人进了家门，也进不了密室。

  4. systemd：Linux系统的服务管理工具，用它运行OpenClaw，可实现开机自动启动、崩溃自动重启、用非root用户隔离运行，避免用root用户运行导致入侵后直接拿到服务器最高权限。

  5. SSH + Tailscale 管理入口：所有管理操作，只能通过SSH隧道或Tailscale虚拟局域网完成，绝对不把Gateway和dashboard直接暴露到公网，始终保持最小暴露面。

九、总结与最佳实践

OpenClaw的安全配置核心在于正确理解并管理Gateway的暴露面。通过本指南的学习，我们应记住以下关键点：

  1. Gateway和dashboard是高权限入口，不应默认暴露到公网
  2. 默认应将Gateway绑定到loopback地址（127.0.0.1），而非所有网络接口
  3. 渠道接入后应立即配置allowlist，限制交互范围
  4. 远程访问优先使用SSH隧道或Tailscale Serve，而非直接公网暴露
  5. 定期进行安全审计和更新，及时修补已知漏洞

最佳实践路径：

  1. 初始部署阶段：

    • 确保Gateway绑定到loopback地址
    • 配置基本认证（Token或密码模式）
    • 为OpenClaw创建专用操作系统用户
    • 限制网关服务的文件系统访问范围

  2. 渠道接入阶段：

    • 为每个渠道配置allowlist
    • 设置群组@提及规则
    • 配置私聊配对机制
    • 审查渠道的API密钥安全

  3. 远程访问阶段：

    • 优先使用SSH隧道或Tailscale Serve
    • 避免直接公网暴露网关
    • 使用专用用户和IP白名单进行访问控制
    • 配置SSH密钥认证，禁用密码登录

  4. 持续维护阶段：

    • 定期更新OpenClaw和相关依赖
    • 每月轮换API密钥和Token
    • 每季度执行全面安全审计
    • 监控异常日志和操作记录
    • 用官方ansible脚本部署，配合防火墙、沙箱、systemd做好权限隔离

提醒：安全是一个持续的过程，不是一次性的配置。随着OpenClaw的快速迭代，其安全机制也在不断演进，建议定期查阅官方安全文档，关注最新安全公告和漏洞修复。

十、最容易踩的7个安全大坑，避坑指南

最后，我们把官方提到的、以及实际使用中最容易踩的安全坑，全部列出来，讲清楚踩坑后果和避坑方法，帮你彻底避开风险。

  1. 大坑一：把dashboard当成普通聊天入口，随便分享

    • 后果：dashboard是最高权限管理面，分享给他人后，轻则被误改配置、删除白名单，重则触发高危命令、服务器被入侵；

    • 避坑：dashboard仅给管理员使用，普通用户仅开放配置好白名单的渠道，绝对不分享dashboard链接和token。

  2. 大坑二：先开公网，再慢慢补认证

    • 后果：互联网上有无数端口扫描爬虫，24小时不停扫全网IP，你把端口绑到公网哪怕1分钟，都可能被扫到、被暴力破解，还没来得及配认证就被入侵；

    • 避坑：顺序绝对不能反，先配好认证、隧道、白名单，再决定是否开放远程访问，默认永远不绑公网。

  3. 大坑三：trusted-proxy配置过宽

    • 后果：配置大网段甚至全网段后，坏人可轻易伪造IP冒充可信代理，直接绕过所有认证，控制你的Gateway；

    • 避坑：非必要不启用trusted-proxy，必须启用时，trustedProxies仅填代理单个IP，绝对不填大网段，且确保只有这一个入口。

  4. 大坑四：渠道接通后不配置allowFrom

    • 后果：渠道一接通就被全网爬虫扫到，陌生人疯狂触发机器人，刷爆API账单，甚至执行高危命令；

    • 避坑：渠道配置的第一行先写allowFrom白名单，确认白名单生效后，再接通渠道上线。

  5. 大坑五：用root用户运行OpenClaw

    • 后果：root是Linux系统最高权限用户，一旦OpenClaw被入侵，攻击者直接拿到整个服务器的控制权，可删盘、装木马、窃取数据；

    • 避坑：用普通非root用户运行OpenClaw，仅给必要的权限，遵循最小权限原则。

  6. 大坑六：token泄露，提交到公开代码仓库

    • 后果：公开仓库的token会在几秒内被爬虫扫到，攻击者直接拿到最高权限，控制你的OpenClaw实例；

    • 避坑：token用环境变量管理，绝对不写在配置文件里提交到Git，用.gitignore把配置文件排除。

  7. 大坑七：公共环境登录dashboard，不清除缓存

    • 后果：token保存在浏览器LocalStorage中，公共电脑上的下一个使用者，可直接打开你的dashboard，控制你的实例；

    • 避坑：绝对不在公共电脑登录dashboard，临时使用必须用无痕模式，用完直接关闭窗口。

如有错误或是遗漏之处，请各位小伙伴批评指正。🙏

相关推荐
ComPDFKit31 分钟前
OpenClaw安全风险与规避方法 — 安全“养虾”全套办法
安全·ai
gallonyin36 分钟前
【企业级龙虾】LLM Gateway 工程化落地：配置中心、429故障转移与统计持久化实战
gateway·openclaw
Web极客码39 分钟前
OpenAI GPT-5.2-Codex (High) vs. Claude Opus 4.5 vs. Gemini 3 Pro：真实场景编程大横评
ai编程·claude code·claude skill·openclaw
乾元1 小时前
全球治理： 从《AI 法案》看安全合规的国际趋势
网络·人工智能·安全·机器学习·网络安全·架构·安全架构
API开发1 小时前
一个MCP操作所有的数据库
数据库·api·api接口·apisql·mcp·mcpserver·openclaw
supersolon1 小时前
OpenClaw安装碰到的一些问题和解决方法
linux·运维·ai·openclaw·龙虾
啊阿狸不会拉杆1 小时前
《现代人工智能基础》个人解读分享
人工智能·ai·llm·aigc·agent·ml·dl
腾视科技TENSORTEC1 小时前
安全驾驶 智在掌控｜腾视科技ES06终端，为车辆运营赋能
大数据·人工智能·科技·安全·ai·车载系统·车载监控
热门推荐
01GitHub 镜像站点02Qwen3.5 开源全解析：从 0.8B 到 397B，代际升级 + 全场景选型指南03OpenClaw 使用和管理 MCP 完全指南04Labelme从安装到标注：零基础完整指南05AI 编程三剑客：Spec-Kit、OpenSpec、Superpowers 深度对比与实战指南06UV安装并设置国内源07小黑课堂计算机二级WPSoffice题库软件下载安装教程（2026年3月最新版）08OpenClaw Control UI安全上下文访问配置09Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services10“wsl --install -d Ubuntu-22.04”下载慢，中国地区离线安装 Ubuntu 22.04 WSL方法（亲测2025年5月6日）