乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > OpenClaw系列第26课:安全加固 – SSH / 防火墙 / 自动更新

OpenClaw系列第26课:安全加固 – SSH / 防火墙 / 自动更新

当前时间： 2026-05-13 08:59:48 更新时间： 2026-05-13 分类：软件教程 评论(0)

OpenClaw系列第26课:安全加固 – SSH / 防火墙 / 自动更新

这是「OpenClaw 教程课程」第 26 课。 上一课我们讲了 OpenClaw 内部的权限控制：sandbox、tool policy、elevated、exec approvals。今天继续往外一层，讲运行 OpenClaw 的主机本身怎么加固：SSH、防火墙、自动更新和安全巡检。

图：OpenClaw 的安全不只在 Agent 配置里，也在宿主机的 SSH、防火墙、更新策略、备份和网络暴露面里。

很多人搭 OpenClaw 时，会把注意力放在功能上：

  • Telegram 能不能回复？
  • exec 能不能跑命令？
  • browser 能不能操作网页？
  • 手机节点能不能拍照？
  • cron / heartbeat 能不能自动执行？

这些当然重要。

但只要 OpenClaw 开始接触真实文件、真实账号、真实设备，安全问题就不能再靠“应该没事”来处理。

特别是 Gateway 跑在 VPS 或家用服务器上时，你至少要回答几个问题：

  • SSH 会不会被公网爆破？
  • 防火墙是不是只开放必要端口？
  • Gateway 端口有没有裸露公网？
  • Tailscale / SSH tunnel 是不是配置清楚？
  • OpenClaw 本身有没有安全审计？
  • 系统和 OpenClaw 有没有更新策略？
  • 出问题时有没有备份和回滚方案？

这一课不是让你变成安全专家。

而是给你一个实用基线：

让 OpenClaw 主机不裸奔、不乱开、不失控、可巡检、可恢复。

一、先说结论：OpenClaw 安全加固分两层

很多新手会误以为：

我把 OpenClaw 配好权限，系统就安全了。  

不对。

OpenClaw 的安全至少分两层。

第一层：OpenClaw 内部安全

上一课讲的内容属于这一层：

  • sandbox
  • tool policy
  • elevated
  • exec approvals
  • node command policy
  • channel allowlist / pairing
  • security audit

这层回答：

Agent 和工具能做什么？

第二层：宿主机安全

今天讲的是这一层：

  • SSH
  • 防火墙
  • 系统用户
  • 端口暴露
  • 自动更新
  • 备份
  • 日志巡检
  • OpenClaw 更新

这层回答：

运行 OpenClaw 的机器本身能不能被别人打进来？

两层都重要。

只做第一层，不管 SSH 和防火墙，等于把控制台放在门口。

只做第二层，不管 tool policy 和 approvals，等于门锁很好，但进屋的人权限太大。

图：OpenClaw 安全分为内部权限层和宿主机安全层，前者控制 Agent 能力，后者控制机器暴露面和运维风险。

二、先明确你的部署场景

安全加固没有一套适合所有人的配置。

先判断你是哪种场景。

1）本地个人电脑

特点：

  • OpenClaw 跑在自己的 Mac / Linux / Windows 上
  • 主要自己使用
  • 不需要公网访问
  • 可能有浏览器登录态和个人文件

重点：

  • 不暴露 Gateway 端口
  • 保持系统更新
  • 打开磁盘加密
  • 控制工具权限
  • 避免共享给陌生人使用

2）VPS / 远程服务器

特点：

  • 7×24 在线
  • 常有公网 IP
  • 通过 SSH 远程管理
  • 适合跑 Gateway、Telegram、Webhook、Cron

重点：

  • SSH key-only
  • 禁止 root 密码登录
  • 防火墙 deny-by-default
  • 只开放必要端口
  • Gateway 不裸露公网
  • 自动安全更新
  • 定期 audit

3）家用服务器 / NAS / 树莓派

特点：

  • 在家庭局域网
  • 可能没有公网 IP
  • 常通过 Tailscale 访问
  • 可能连接摄像头、设备、传感器

重点：

  • 不做路由器端口转发暴露 Gateway
  • 使用 Tailscale / SSH tunnel
  • 控制局域网自动信任
  • 注意备份和 SD 卡寿命
  • 节点能力最小授权

4）团队或共享环境

这里要特别小心。

OpenClaw 文档强调，它默认是 personal assistant trust model。

也就是：

一个 Gateway 对应一个可信操作边界。

如果多个互不信任的人共用一个带工具权限的 Gateway，不是推荐模型。

更好的做法是：

  • 分开 Gateway
  • 分开 OS 用户
  • 分开 credentials
  • 分开浏览器 profile
  • 分开主机或容器

三、第一步：运行 OpenClaw 自带安全审计

OpenClaw 提供：

openclaw security auditopenclaw security audit --deepopenclaw security audit --json

这是你最应该养成习惯的命令之一。

普通 audit

openclaw security audit

它主要做冷配置和文件系统层面的检查。

适合日常快速跑。

deep audit

openclaw security audit --deep

它会包含 live Gateway probes 和插件相关安全检查。

适合：

  • 改过配置后
  • 开了远程访问后
  • 安装插件后
  • 准备长期运行前

JSON 输出

openclaw security audit --json

适合脚本或 CI。

比如：

openclaw security audit --deep --json | jq '.summary'

自动修复

openclaw security audit --fix

注意：--fix 不是万能安全加固。

文档里说，它会做一些安全、确定性的修复，例如：

  • 把常见 open group policy 收紧到 allowlist
  • 恢复 logging.redactSensitive: "tools"
  • 收紧 state/config/credentials/auth 文件权限
  • 收紧 config include 文件权限

但它不会做这些事：

  • 不会旋转 token / password / API key
  • 不会改宿主机防火墙
  • 不会改 SSH 配置
  • 不会移除插件
  • 不会替你决定 Gateway 网络暴露方式

一句话：

OpenClaw audit 能发现很多 OpenClaw 配置风险，但不会替你加固整台服务器。

图：安全巡检建议先跑 openclaw security audit，再看 deep audit，必要时使用 –fix，但系统级 SSH 和防火墙仍需单独处理。

四、第二步：确认 Gateway 有没有暴露公网

这是 OpenClaw 安全里最重要的问题之一。

Gateway 默认 WebSocket / HTTP 端口通常是：

18789

第 22 课已经讲过：

不要把 Gateway 端口裸露公网。

推荐模式是：

Gateway bind = loopback远程访问走 Tailscale Serve / SSH tunnel

也就是让 Gateway 继续监听：

127.0.0.1:18789

外部设备通过安全通道访问。

推荐检查

openclaw statusopenclaw gateway statusopenclaw security audit --deep

系统层面可以看监听端口。

Linux：

ss -ltnp

macOS：

lsof -nP -iTCP -sTCP:LISTEN

如果你看到 Gateway 监听在：

0.0.0.0:18789

或者公网 IP 的 18789，就要非常谨慎。

不是说绝对不能这么做，而是你必须清楚：

  • 是否有强认证
  • 是否只在可信网络暴露
  • 是否有反向代理和 TLS
  • 是否需要 Tailscale / SSH 替代
  • 是否有防火墙限制来源 IP

新手默认答案是：

不要这样做。

五、SSH：先保护你的入口

如果 OpenClaw 跑在 VPS，SSH 基本就是管理入口。

SSH 出问题，OpenClaw 配得再好也没用。

推荐原则

  1. 使用 SSH key 登录
  2. 禁止 root 密码登录
  3. 禁止密码登录，或至少限制密码登录
  4. 保留一个可用的 sudo 用户
  5. 修改 SSH 配置前，先开一个现有 SSH 会话别断
  6. 改完后新开窗口测试，再关闭旧窗口

不建议

  • 只用 root + 密码
  • 密码很短
  • 多人共用同一个 Linux 用户
  • 不知道怎么回滚就改 sshd_config
  • 远程改 SSH 后直接断开当前连接

常见检查命令

查看 SSH 服务是否监听：

ss -ltnp | grep ssh

查看失败登录：

sudo journalctl -u ssh --since "24 hours ago"

不同系统服务名可能是 ssh 或 sshd。

Debian / Ubuntu 常见：

sudo systemctl status ssh

CentOS / RHEL 常见：

sudo systemctl status sshd

修改 SSH 前一定要有回滚方案

比如：

  • 云厂商控制台能不能进机器
  • 有没有 root 控制台
  • 有没有快照
  • 当前 SSH 会话是否保持不断
  • 新配置是否用 sshd -t 检查过

修改 SSH 属于可能把自己锁在门外的操作。

所以本教程只给原则，不建议你直接复制陌生命令一把梭。

六、防火墙：默认拒绝，只开必要端口

VPS 上建议使用 deny-by-default 思路：

默认拒绝入站只开放 SSH只开放确实需要的业务端口Gateway 不直接开放公网

常见工具：

  • Ubuntu / Debian：ufw
  • RHEL / CentOS / Fedora：firewalld
  • 通用 Linux：nftables
  • 云服务器：还要看云安全组

UFW 示例思路

只作为示例，真正执行前要确认你当前 SSH 端口。

sudo ufw status verbosesudo ufw allow OpenSSHsudo ufw enable

如果你的 SSH 不在 22，而是自定义端口，要先允许那个端口：

sudo ufw allow <ssh-port>/tcp

再启用防火墙。

云安全组也要检查

很多 VPS 有两层防火墙：

  1. 系统内防火墙
  2. 云厂商安全组

你系统里关了端口，但云安全组开着；或者系统里开了，云安全组拦了，都可能造成困惑。

建议对照检查：

  • SSH 端口
  • HTTP / HTTPS 端口
  • 是否误开 18789
  • 是否误开数据库端口
  • 是否误开 Docker / Redis / Prometheus 等服务端口

图：VPS 上建议 SSH key-only、关闭不必要入站端口，Gateway 保持 loopback，通过 Tailscale 或 SSH tunnel 访问。

七、哪些端口应该开放？

这取决于你的部署方式。

本地个人电脑

通常不需要开放任何入站端口。

VPS 跑 Telegram bot

Telegram bot 通常是 Gateway 主动访问 Telegram API，不需要你开放 Telegram 入站端口。

常见开放：

  • SSH：给你管理服务器
  • HTTP / HTTPS：只有你明确部署 Webhook / 反代 / 公开服务时才开放

不建议开放：

  • 18789 Gateway 端口
  • 数据库端口
  • Docker API
  • Redis
  • 内部管理面板

Tailscale Serve 模式

通常 Gateway 本机继续 loopback。

公网防火墙不需要开放 18789。

Tailnet 内访问由 Tailscale 处理。

SSH tunnel 模式

也不需要开放 Gateway 端口。

只需要 SSH 可达。

八、Tailscale 和 SSH tunnel 的安全边界

第 22 课讲过 Tailscale，这里从安全角度再强调一次。

Tailscale 解决网络可达

它让你的设备进入同一个 tailnet。

但它不等于：

  • 自动批准 OpenClaw 节点
  • 自动允许所有工具
  • 自动跳过 Gateway auth
  • 自动跳过 exec approvals

SSH tunnel 解决安全转发

它把本地端口安全转发到远程 loopback。

比如：

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

然后你访问本地：

127.0.0.1:18789

实际到远程 Gateway。

这比开放公网 18789 安全很多。

安全边界一句话

Tailscale / SSH tunnel 负责把路打通，OpenClaw auth / pairing / policy 负责决定能不能进门和能做什么。

九、系统自动更新：至少开启安全更新

长期运行的 Gateway 主机，不更新也有风险。

尤其是：

  • OpenSSL
  • SSH
  • kernel
  • sudo
  • systemd
  • curl / git
  • 浏览器相关组件

如果是 Ubuntu / Debian，可以考虑 unattended-upgrades。

如果是 RHEL 系，可以考虑 dnf-automatic。

如果是 macOS，至少开启系统安全更新。

这里不直接给“一键开启”命令，因为不同系统差异很大，而且更新策略会影响服务稳定。

建议原则：

  1. 安全更新优先自动化
  2. 大版本升级手动确认
  3. 更新后检查 OpenClaw gateway 状态
  4. 关键机器先有备份或快照
  5. VPS 可以用云快照兜底

十、OpenClaw 更新：用 update status 和 update

OpenClaw 自己也要更新。

常用命令：

openclaw update statusopenclaw updateopenclaw update --dry-runopenclaw update --json

先看状态

openclaw update status

它会显示当前 channel、版本和是否有更新。

预演更新

openclaw update --dry-run

适合你想知道会发生什么，但暂时不想真正更新。

执行更新

openclaw update

文档里说，openclaw update 会检测安装类型，更新后运行 doctor，并重启 Gateway。

更新后检查

openclaw doctoropenclaw gateway statusopenclaw health

如果你手动用 npm / pnpm / bun 更新，记得更新后重启 Gateway。

自动更新

OpenClaw auto-updater 默认关闭。

配置大概是：

{  update: {    channel: "stable",    auto: {      enabled: true,      stableDelayHours: 6,      stableJitterHours: 12,      betaCheckIntervalHours: 1,    },  },}

我对新手的建议是：

先定期 check，再决定是否开启自动 apply。

也就是先养成：

openclaw update status

的习惯。

图：推荐先 update status，再 dry-run，确认后 update，最后 doctor、gateway status、health 验证。

十一、备份：安全加固前先想好怎么恢复

安全加固不是只会变安全。

也可能带来：

  • SSH 锁死
  • 防火墙误封
  • 配置写错
  • Gateway 起不来
  • 更新后插件不兼容
  • 凭据丢失

所以要有备份意识。

OpenClaw 里比较敏感、值得关注的内容包括：

  • ~/.openclaw/openclaw.json
  • ~/.openclaw/credentials/
  • ~/.openclaw/devices/
  • ~/.openclaw/secrets.json
  • agent 的 auth-profiles.json
  • session / memory / workspace 数据

这些文件可能包含：

  • bot token
  • pairing allowlist
  • model API key 引用
  • OAuth 状态
  • channel 登录态
  • device token

备份要注意两点：

  1. 要能恢复
  2. 备份本身也要加密或限制权限

否则备份泄漏也是泄漏。

十二、磁盘加密：个人机器尤其重要

如果 OpenClaw 跑在个人电脑上，它可能能访问很多个人数据。

建议开启磁盘加密：

  • macOS：FileVault
  • Windows：BitLocker
  • Linux：LUKS 或云盘加密

这不能防止在线攻击。

但可以降低设备丢失、硬盘被拿走、云盘快照泄漏时的风险。

十三、日志和密钥：不要把秘密写进日志

OpenClaw 的安全 audit 会关注日志脱敏配置。

例如 logging.redactSensitive。

security audit --fix 会把常见错误配置恢复到更安全状态，比如：

logging.redactSensitive: "tools"

你自己写脚本时也要注意：

  • 不要 echo $API_KEY
  • 不要把完整 token 贴进群聊
  • 不要把 setup code 发给别人
  • 不要把 ~/.openclaw/credentials 上传公开仓库
  • 不要把 debug log 发给陌生人前不脱敏

十四、浏览器和账号安全

如果 OpenClaw 能操作浏览器，风险会变大。

因为浏览器可能有：

  • 已登录网站
  • 邮箱
  • 云盘
  • 管理后台
  • 支付后台
  • 社交账号

建议：

  • 重要账号开启 2FA
  • 优先硬件安全密钥
  • 不要让共享 agent 使用个人浏览器 profile
  • 为自动化准备专用浏览器 profile
  • 不要把 browser control 暴露公网
  • 远程浏览器控制要当成 operator access 对待

一句话：

Agent 能操作浏览器，就相当于能替你点很多已经登录的网站。

十五、插件和 hooks：外部入口要更谨慎

第 19 课讲过 webhook / hooks。

它们属于外部触发入口。

安全 audit 会检查很多 webhook 风险，比如：

  • hooks token 太短
  • hooks token 复用 Gateway token
  • hooks path 是 /
  • defaultSessionKey 未设置
  • allowedAgentIds 不受限
  • sessionKey overrides 太宽

建议：

  • webhook token 单独生成，不复用 Gateway token
  • path 不要用 /
  • 限制 allowedAgentIds
  • 限制 sessionKey override
  • 对外入口尽量加反代 / TLS / IP 限制
  • 不需要就关闭

插件也一样。

插件本质上会增加工具和代码面。

只安装你信任的插件，并定期更新。

十六、定期巡检：不要只加固一次

安全不是一次性动作。

建议你建立一个简单节奏：

每周

openclaw security auditopenclaw update status

每次改配置后

openclaw security audit --deepopenclaw doctor

每次更新后

openclaw doctoropenclaw gateway statusopenclaw health

每次开放新入口后

检查：

  • 防火墙
  • 云安全组
  • Gateway bind / auth
  • channel allowlist
  • tool policy
  • security audit –deep

如果你要做自动巡检，可以用 OpenClaw cron。

但创建计划任务属于持久化行为，应该明确确认后再做。

十七、一个安全巡检命令清单

下面是一套只读检查思路。

OpenClaw 层

openclaw statusopenclaw status --deepopenclaw security auditopenclaw security audit --deepopenclaw update statusopenclaw doctor

Linux 主机层

uname -acat /etc/os-releasess -ltnpsudo ufw status verbosesudo firewall-cmd --state

不一定每台机器都有 ufw 或 firewalld。

哪个存在看哪个。

macOS 主机层

sw_verslsof -nP -iTCP -sTCP:LISTEN/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

Tailscale

tailscale status

这套命令里有些需要 sudo。

真正执行前要确认环境和权限。

十八、一个推荐的 VPS 安全基线

如果你的 Gateway 跑在 VPS，我建议基线是：

  1. SSH key-only
  2. 禁止 root 密码登录
  3. 防火墙默认拒绝入站
  4. 只开放 SSH，以及明确需要的 HTTP / HTTPS
  5. 不开放 Gateway 18789 到公网
  6. 使用 Tailscale Serve 或 SSH tunnel 访问 Gateway
  7. OpenClaw gateway.auth 使用 token / password
  8. channel DM / group 使用 allowlist / pairing
  9. exec 不默认 full，至少重要场景用 allowlist / ask
  10. openclaw security audit --deep 定期跑
  11. openclaw update status 定期看
  12. 系统安全更新有策略
  13. 关键配置和 credentials 有加密备份

图：VPS 安全基线包括 SSH key-only、防火墙默认拒绝、Gateway 不裸露公网、Tailscale/SSH tunnel、审计、更新和备份。

十九、不要做的危险操作

1）不要裸露 Gateway 端口

尤其不要：

0.0.0.0:18789

配合弱 auth 或 no auth 会非常危险。

2）不要复用 token

Webhook token、Gateway token、模型 API key，不要混用。

3）不要把 credentials 传到公开仓库

尤其是：

~/.openclaw/credentials/~/.openclaw/secrets.jsonauth-profiles.json

4）不要在不确认 SSH 回滚时启用防火墙

这可能把你锁在服务器外面。

5）不要让陌生人使用同一个带工具权限的 Gateway

OpenClaw 默认不是 hostile multi-tenant 安全边界。

6）不要忽略浏览器登录态风险

有 browser control 的 Agent，可能能操作你已登录的网站。

二十、适合新手的提问模板

1）只读安全巡检

请帮我做 OpenClaw 主机安全巡检，只做只读检查。先运行 openclaw security audit --deep、openclaw update status、openclaw status，再根据系统检查监听端口和防火墙状态，不要修改配置。

2）检查 Gateway 是否裸露公网

请帮我检查 OpenClaw Gateway 是否可能裸露公网。重点看 gateway bind/auth、监听端口、防火墙和 Tailscale/SSH tunnel 路径。只读检查。

3）设计 VPS 加固方案

我的 OpenClaw Gateway 跑在 VPS 上。请帮我设计 SSH、防火墙、Tailscale、OpenClaw audit、更新和备份的安全基线。先给计划，不要直接执行。

4）更新前检查

请帮我在更新 OpenClaw 前做检查：update status、security audit、doctor，并说明是否建议先备份或 dry-run。

5）防火墙变更前确认

我想开启防火墙。请先列出当前 SSH 端口、当前连接方式、需要保留的端口、回滚方案，再给我命令。不要直接执行。

6）定期巡检计划

请帮我设计一个每周 OpenClaw 安全巡检计划，包括 security audit、update status、日志检查和需要人工确认的事项。先只给方案，不要创建 cron。

二十一、这一课最值得记住的一句话

如果今天只记一句话：

OpenClaw 的工具权限很重要，但宿主机 SSH、防火墙、更新和备份同样重要。

再记一句安全原则：

先减少暴露面，再加认证；先有回滚方案，再改远程访问。

二十二、总结

今天这节课，我们讲了 OpenClaw 主机安全加固的基本路线：

  1. OpenClaw 安全分为内部权限层和宿主机安全层。
  2. 先明确部署场景：本地电脑、VPS、家用服务器或共享环境。
  3. 定期运行 openclaw security audit 和 --deep。
  4. security audit --fix 只做 OpenClaw 内部安全修复，不改 SSH / 防火墙。
  5. Gateway 端口不要裸露公网，优先 loopback + Tailscale Serve / SSH tunnel。
  6. VPS 上 SSH 要优先 key-only，并保留回滚路径。
  7. 防火墙默认拒绝入站，只开放必要端口。
  8. 云安全组和系统防火墙都要检查。
  9. 系统安全更新和 OpenClaw 更新都要有策略。
  10. 备份要能恢复，备份本身也要保护。
  11. 浏览器控制和 webhook / hooks 都属于高风险入口。
  12. 安全巡检应该定期做，而不是装完才做一次。

安全加固的目标不是把系统变得完全不可用。

而是让 OpenClaw 在长期运行时保持一个可控状态：

入口清楚权限清楚暴露面清楚更新清楚出事能恢复

这就是个人 AI 系统走向长期可用的基础。

下一课预告

下一课我们会讲：

第 27 课：日志与调试——怎么看 Gateway 日志排错

会重点讲：

  • Gateway 日志在哪里看
  • openclaw logs --follow 怎么用
  • 怎么区分模型错误、通道错误、工具错误、权限错误
  • deep status / doctor / security audit 怎么组合使用
  • 日志里哪些信息不能随便发给别人

🦞 本文由八条撰写，持续更新中。