在云服务器上安全运行 OpenClaw：从安装到加固的完整指南

把 OpenClaw 部署到云服务器，看起来像是一件很普通的事情：装好环境、跑起来、打开端口、远程访问。

但真正的问题恰恰出在这里。

很多人会下意识把它当成一个普通 Web 服务，直接监听公网地址，再顺手开放端口。这样做虽然"能用"，却往往不是最安全的方式。对 OpenClaw 这种长期在线、可接消息渠道、可能持有密钥和状态数据的系统来说，最重要的不是先跑起来，而是先收紧边界。

这篇文章给出一套更稳妥的部署方案：

使用 Debian 云服务器
使用 rootless Podman 运行 OpenClaw
只监听本机回环地址
远程访问只走 SSH 隧道
默认启用 token 鉴权
默认保留最小工具权限
默认启用沙箱与私聊隔离

这套方案的目标不是"最快上线"，而是：让 OpenClaw 以更接近长期生产使用的方式稳定运行，同时把暴露面尽量缩小。

一、本文的部署思路

先说结论。

在 Debian 云服务器上部署 OpenClaw，最稳妥的一种方式是：

先把 Debian 主机本身加固
用 rootless Podman 安装 OpenClaw
让 Gateway 只绑定 127.0.0.1
只通过 SSH 隧道访问 Control UI
默认开启 token 鉴权
默认关闭高风险工具能力
默认让会话运行在沙箱里
定期跑安全审计与健康检查

如果你是个人使用，或者只服务于一个明确的可信边界，那么这套架构通常比"直接暴露公网 + 反向代理"更简单，也更不容易踩坑。

二、最终架构长什么样

部署完成后，整体应该是这样：

Debian 云服务器只开放 22/tcp
OpenClaw 运行在 rootless Podman 容器中
OpenClaw Gateway 监听 127.0.0.1:18789
Control UI 不直接暴露公网
本地电脑通过 SSH 隧道访问 Web 控制界面
消息渠道默认启用 pairing
工具权限默认最小化
会话默认放进沙箱中运行

这个设计的核心思想只有一句话：

把 OpenClaw 当成"你的私人网关"，不是"公开机器人平台"。

三、部署前准备

本文默认你已经具备以下条件：

一台 Debian 云服务器
一个拥有 sudo 权限的普通管理员账号
你自己的本地电脑可以通过 SSH 连接这台服务器

建议不要直接使用 root 作为日常运维账号。后面的操作也默认围绕一个普通管理员用户展开。

四、可直接执行的 Debian 命令清单

下面的命令我按执行位置拆成两部分：本地电脑 和服务器。

1. 在本地电脑生成 SSH 密钥并登录服务器

先在你自己的电脑上执行：

bash 复制代码

export VPS_USER="your_admin_user"
export VPS_HOST="your.server.ip.or.domain"

ssh-keygen -t ed25519 -C "openclaw-debian"
ssh-copy-id "${VPS_USER}@${VPS_HOST}"
ssh "${VPS_USER}@${VPS_HOST}"

这一步的目的很明确：先确保你已经能通过 SSH 公钥登录服务器。后面我们会关闭密码登录，因此这一步必须先成功。

2. 在服务器上更新系统并安装基础依赖

下面开始，默认都在服务器上执行：

bash 复制代码

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y git curl openssl podman nftables unattended-upgrades apt-listchanges

这里安装的是整套部署所需的基础组件：

git：拉取 OpenClaw 源码
curl、openssl：一些常见辅助工具
podman：以 rootless 方式运行 OpenClaw
nftables：主机防火墙
unattended-upgrades：自动安全更新
apt-listchanges：更新前查看软件包变更信息

3. 启用自动安全更新

bash 复制代码

sudo tee /etc/apt/apt.conf.d/20auto-upgrades >/dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF

sudo systemctl enable --now unattended-upgrades

这一项很容易被忽略，但长期运行的服务器尤其需要它。

你不一定每天都手动上去更新，但安全补丁最好能自动跟上。

4. 收紧 SSH：关闭密码登录和 root 直登

先强调一遍：先确认你已经能通过公钥正常登录，再做这一步。

bash 复制代码

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)

sudo tee /etc/ssh/sshd_config.d/99-openclaw-hardening.conf >/dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no
UsePAM yes
X11Forwarding no
EOF

sudo sshd -t
sudo systemctl reload ssh

完成之后，服务器就只接受公钥登录，不再接受密码和 root 直接登录。

这一步不是"高级安全技巧"，而是云服务器最基础也最值得做的一步。

5. 配置 nftables：默认拒绝入站，只开放 SSH

bash 复制代码

sudo tee /etc/nftables.conf >/dev/null <<'EOF'
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    iif lo accept
    ct state established,related accept

    tcp dport 22 accept

    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;
  }

  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}
EOF

sudo systemctl enable --now nftables
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

注意，这里故意不开放 18789 端口。

因为后面 OpenClaw Gateway 会只绑定在 127.0.0.1，它本来就不应该被公网直接访问。

这也是这篇文章和很多"能跑就行"的教程最大的区别之一。

五、安装 OpenClaw

6. 拉取源码并使用 Podman 安装

bash 复制代码

cd /opt
sudo git clone https://github.com/openclaw/openclaw.git
cd /opt/openclaw

sudo ./setup-podman.sh --quadlet

这一步会完成几件事：

创建专用的 openclaw 用户
构建和准备容器运行环境
安装启动脚本
注册为 systemd Quadlet 用户服务

这样做的好处是，OpenClaw 不直接以 root 身份运行，权限边界更清晰，也更适合长期运行。

7. 查看 OpenClaw 服务状态

bash 复制代码

sudo systemctl --machine openclaw@ --user status openclaw.service
sudo journalctl --machine openclaw@ --user -u openclaw.service -f

如果服务没有正常起来，第一时间看日志，不要盲目重装。

很多配置或环境问题，其实在日志里都会直接说清楚。

8. 启动 onboarding 向导

bash 复制代码

cd /opt/openclaw
sudo ./scripts/run-openclaw-podman.sh launch setup

执行完成后，OpenClaw 会准备初始配置环境，通常也会生成默认 token，并写入 ~openclaw/.openclaw/.env。

9. 查看默认生成的 token

bash 复制代码

sudo -u openclaw grep '^OPENCLAW_GATEWAY_TOKEN=' /home/openclaw/.openclaw/.env

后面访问 Control UI 时会用到它。

六、写入一份安全基线配置

下面写入一份适合个人部署、默认偏保守的基线配置。

bash 复制代码

sudo -u openclaw tee /home/openclaw/.openclaw/openclaw.json >/dev/null <<'EOF'
{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "port": 18789,
    "controlUi": {
      "enabled": true
    },
    "auth": {
      "mode": "token",
      "token": "${OPENCLAW_GATEWAY_TOKEN}"
    }
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "tools": {
    "profile": "messaging",
    "fs": {
      "workspaceOnly": true
    },
    "deny": [
      "group:runtime",
      "group:fs",
      "group:automation",
      "browser",
      "sessions_spawn"
    ]
  },
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "all",
        "scope": "agent",
        "workspaceAccess": "none"
      }
    }
  }
}
EOF

这份配置的含义可以简单理解为：

只监听本地回环地址，不直接面向公网
启用 token 鉴权
私聊按频道和对端隔离
工具集先保守，先别给执行能力
文件系统限制在工作区
默认把所有会话都放进沙箱
默认不给宿主机工作区访问权限

对个人部署来说，这是一份比较稳的起点。

以后你需要能力时，可以一项一项放开；不要一开始就把所有能力都打开。

10. 收紧 OpenClaw 配置目录权限

bash 复制代码

sudo chmod 700 /home/openclaw/.openclaw
sudo chmod 600 /home/openclaw/.openclaw/openclaw.json
sudo chown -R openclaw:openclaw /home/openclaw/.openclaw

~/.openclaw 目录下通常会存放配置、凭据、状态文件，甚至日志。

如果这个目录权限过宽，前面做的很多安全措施都会被削弱。

11. 重启服务使配置生效

bash 复制代码

sudo systemctl --machine openclaw@ --user restart openclaw.service
sudo systemctl --machine openclaw@ --user status openclaw.service

做到这里，OpenClaw 其实已经基本部署完成了。

七、通过 SSH 隧道访问 Control UI

现在不要开放新端口，而是回到你的本地电脑执行：

bash 复制代码

export VPS_USER="your_admin_user"
export VPS_HOST="your.server.ip.or.domain"

ssh -N -L 18789:127.0.0.1:18789 "${VPS_USER}@${VPS_HOST}"

然后在本地浏览器打开：

text 复制代码

http://127.0.0.1:18789/

这样访问时，浏览器连的是你本机的 127.0.0.1:18789，而 SSH 会把流量安全地转发到服务器上的 OpenClaw Gateway。

整个过程中，OpenClaw 本身并没有暴露公网。

这就是为什么前面我们不需要开放 18789 端口。

八、接入消息渠道时，为什么建议保留 pairing

部署完成后，很多人下一步会接 Telegram、Signal 或其他消息渠道。

这里最容易出现的误区是：

"为了省事，直接让任何人都能 DM 机器人。"

但更稳妥的方式是：保留 pairing 机制。

也就是：

未知发件人第一次接触机器人时，先拿到一次性配对码
只有你手动批准之后，对方消息才会真正进入可处理状态

常见操作类似这样：

bash 复制代码

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

或者：

bash 复制代码

openclaw pairing list signal
openclaw pairing approve signal <CODE>

如果后面要把机器人拉进群里，也建议继续保留 mention gating，尽量避免它在群聊里被任意内容触发。

九、上线后的日常运维建议

OpenClaw 跑起来以后，真正重要的是后面的维护习惯。

建议把下面这些命令当作常规检查项：

bash 复制代码

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw secrets audit
openclaw doctor

这些命令分别适合做不同层面的检查：

security audit：看当前配置有没有明显风险
security audit --deep：做更深入的检查
security audit --fix：自动修正一部分可修复问题
secrets audit：检查密钥与敏感配置处理是否合理
doctor：做整体健康检查

如果你后续调整了沙箱配置，建议再执行一次：

bash 复制代码

openclaw sandbox recreate --all

这样可以确保新的沙箱策略真正生效，而不是继续使用旧的容器状态。

十、常见坑

这一节特别值得看，因为很多问题都不是"不会装"，而是"装法看起来没问题，实际上不够稳"。

坑一：直接监听 `0.0.0.0`

最常见，也最危险。

你可能会觉得这样"方便远程访问"，但这会立刻扩大攻击面。

更稳妥的方式是继续保持 loopback，只通过 SSH 隧道或更受控的方式接入。

坑二：防火墙放行了 18789

即使你觉得"反正有 token"，也不建议这么做。

能不暴露就不要暴露。鉴权不是替代网络边界，而是第二道门。

坑三：一开始就开启全部工具

执行能力、文件系统访问、自动化能力、浏览器能力，这些都属于高风险能力。

最好的做法不是"全开然后慢慢修"，而是"默认收紧，按需放开"。

坑四：把配置和密钥权限放得太宽

如果其他本机用户能读到 ~/.openclaw 目录里的内容，那很多安全措施都会变得很脆弱。

目录权限和服务配置同样重要。

坑五：不做后续检查

很多部署文章写到"启动成功"就结束了。

但真正长期运行的服务，最怕的不是第一次装不上，而是半年以后忘了它怎么配置的、权限变没变、审计有没有跑过。

十一、什么时候再考虑 Tailscale 或反向代理

这篇文章刻意没有直接讲公网域名接入，因为那不是最保守的第一步。

更合理的顺序通常是：

先用 SSH 隧道
再考虑 Tailscale
最后才是公网反向代理 + 额外认证

也就是说，先让系统以最小暴露面稳定运行，再逐步改善访问体验。

不要一上来就为了"访问方便"把公网入口做复杂。

十二、上线前检查清单

正式开始长期使用前，可以对照下面这份清单快速自查：

如果这份清单里有几项你还没做到，建议先补齐，再开始正式接消息渠道。

十三、结语

在云服务器上部署 OpenClaw，真正值得追求的不是"最快跑起来"，而是"跑起来之后还能安心长期用"。

所以这篇文章的核心思路一直很一致：

不急着暴露公网
不急着开高权限工具
不急着给所有人接入
先把系统边界、访问路径和默认权限收紧

这样部署出来的 OpenClaw，虽然看上去保守一点，但往往更适合真实世界的长期运行。

在云服务器上安全运行 OpenClaw：从安装到加固的完整指南

一、本文的部署思路

二、最终架构长什么样

三、部署前准备

四、可直接执行的 Debian 命令清单

1. 在本地电脑生成 SSH 密钥并登录服务器

2. 在服务器上更新系统并安装基础依赖

3. 启用自动安全更新

4. 收紧 SSH：关闭密码登录和 root 直登

5. 配置 nftables：默认拒绝入站，只开放 SSH

五、安装 OpenClaw

6. 拉取源码并使用 Podman 安装

7. 查看 OpenClaw 服务状态

8. 启动 onboarding 向导

9. 查看默认生成的 token

六、写入一份安全基线配置

10. 收紧 OpenClaw 配置目录权限

11. 重启服务使配置生效

七、通过 SSH 隧道访问 Control UI

八、接入消息渠道时，为什么建议保留 pairing

九、上线后的日常运维建议

十、常见坑

坑一：直接监听 0.0.0.0

坑二：防火墙放行了 18789

坑三：一开始就开启全部工具

坑四：把配置和密钥权限放得太宽

坑五：不做后续检查

十一、什么时候再考虑 Tailscale 或反向代理

十二、上线前检查清单

十三、结语

坑一：直接监听 `0.0.0.0`