AI 帮你管远程服务器：OpenClaw / Hermes / Claude Code / Codex 的 SSH 运维实战与对比

先给结论：让 AI 管远程服务器，正确的架构是 AI 代理住在你的本地电脑，通过 SSH 协议远程操控 Ubuntu 服务器；服务器上只开 sshd，不装任何 AI 组件。所有 LLM 推理、任务规划、工具调用全部发生在本地，服务器端唯一的软件是 OpenSSH Server。

这个架构最大的好处是干净：服务器零 AI 依赖、零 Node 依赖，攻击面小；密钥和 API Key 都在你手里；Agent 的每条远程指令都能在本地留审计日志。服务器就是一台普通 Linux 机器，换掉 Agent、换掉模型，服务器不用动一根手指。

问题是：本地 Agent 选哪款？OpenClaw、Hermes、Claude Code、Codex 是现在最热的四个选项，但它们的架构和远程能力差别很大——有一款拓扑甚至是反的。本文用同一套架构跑通四款工具，给例子、给对比、给安全基线。

一、核心架构：Agent 在本地，服务器只开 sshd

你的本地机器（Windows / macOS / Linux）
 ┌─────────────────────────────────┐
 │  Hermes / OpenClaw / Claude Code│← LLM 推理、任务规划、工具调用（全在本地）
 │  / Codex（Agent 本体）           │
 │  OpenSSH client（本地 ssh）      │
 └───────────────┬─────────────────┘
                 │ SSH（密钥认证）
                 ▼
远程 Ubuntu Server
 ┌─────────────────────────────────┐
 │  openssh-server（唯一服务）       │
 │  无 node、无 claude、无 hermes   │
 └─────────────────────────────────┘

前置准备（一次做完，四款工具共用）

本地：装 OpenSSH client（Windows 11 自带，确认 ssh -V 有输出即可）、git。

远程 Ubuntu：

sudo apt install openssh-server
sudo systemctl enable --now ssh
# 编辑 /etc/ssh/sshd_config：
#   PasswordAuthentication no   ← 禁用密码登录
#   PermitRootLogin no          ← 禁止 root 直接登录
sudo systemctl restart ssh

本地生成密钥并推送（Agent 自动化必须免密，所以密钥不设口令）：

ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_remote_ubuntu

# 推送公钥到远程
ssh-copy-id -i ~/.ssh/id_remote_ubuntu ubuntu@remoteip

# 测试免密登录：确认不再要求输入密码
ssh -i ~/.ssh/id_remote_ubuntu ubuntu@remoteip

二、方案 A：Hermes 本地 Agent —— 原生 terminal 工具，零胶水

Hermes Agent（NousResearch 开源，Go 单二进制）在四款里和这个架构最匹配：它天生就是「本地跑 Agent、本地执行命令」的设计，terminal 工具直接调用本地 shell，你把 ssh 命令喂给它，它就跑。不需要写任何插件代码。

安装

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
hermes setup   # 配置模型 Provider（支持 Anthropic / OpenAI / DeepSeek / 本地模型等 20+）

注意：网上流传的「git clone + python venv + pip install」是早期版本或其他同名项目的装法，官方现在就是一个编译好的二进制，装完即用。

使用示例：远程巡检

直接对本地 Hermes 说：

巡检远程 Ubuntu 服务器（ubuntu@192.168.1.100，私钥 ~/.ssh/id_remote_ubuntu）：查看磁盘、内存、失败的系统服务，找出异常，给出修复建议。高危操作（删除、重启服务）不要自动执行，先报告。

Agent 的完整流程：

1. 规划：决定依次执行 free -h、df -h、systemctl list-units --failed
2. 执行：调用 terminal 工具运行 ssh -i ~/.ssh/id_remote_ubuntu ubuntu@192.168.1.100 "free -h"
3. 分析：拿到远端输出，继续思考，决定下一步
4. 报告：整理成巡检报告给你。全程发生在本地

进阶：把 ssh 封装成独立工具（更利于审计和约束）

Hermes 支持自定义工具（Python 插件）。把「执行远程命令」封装成唯一的入口，好处是：所有远程指令都走同一个函数，你可以在这一层加日志、加高危命令拦截、加人工确认，而不是靠提示词约束。

def ssh_run(command: str) -> str:
    """
    在远程 Ubuntu 执行 shell 命令（本地 ssh 客户端调用）。
    """
    import os, subprocess
    target = os.environ["REMOTE_SSH_TARGET"]   # ubuntu@192.168.1.100
    keyfile = os.environ["REMOTE_SSH_KEY"]     # ~/.ssh/id_remote_ubuntu
    result = subprocess.run(
        ["ssh", "-i", keyfile, target, command],
        capture_output=True, text=True, timeout=120,
    )
    return (f"stdout:\n{result.stdout}\nstderr:\n{result.stderr}\n"
            f"returncode:{result.returncode}")

在这个函数里加三条保险：把命令写进审计日志；正则匹配 rm -rf|mkfs|dd|shutdown|reboot 直接拒绝并提示人工确认；超时控制。这样即使模型抽风，也有最后一道闸。

三、方案 B：Claude Code CLI —— 开箱即用，提示词约束

Claude Code 没有原生的「远程服务器模式」，但它是本地运行的完整 Agent，内置 Bash 工具。所以路线就是：让它在本地生成 ssh 命令，用本机 OpenSSH 去执行远端命令。零远程依赖，符合架构。

安装与启动

npm install -g @anthropicai/claudecode
claude

会话开场提示词（核心）

Claude Code 的远程纪律完全靠提示词，每次新会话都要重申：

规则：你运行在本地机器。所有服务器操作禁止在本地本机执行，必须通过 ssh 调用远程 Ubuntu ubuntu@192.168.1.100，私钥 ~/.ssh/id_remote_ubuntu。 需要操作远程服务器时，生成本地 ssh 命令，例如：ssh -i ~/.ssh/id_remote_ubuntu ubuntu@192.168.1.100 "df -h"。 高危命令（rm、格式化、apt remove、重启服务）执行前必须先向我确认，不要自动运行。 任务：巡检远程服务器 CPU、内存、磁盘与失败的 systemd 单元。

这套路线的局限

• 无状态：每次 ssh 都是一次性执行，Claude Code 不维护远程会话上下文。长任务（比如跨多步的排障）需要反复把上下文写进提示词
• 提示词漂移：会话一长，模型可能忘记「所有操作走 ssh」这条规则，直接在本地跑了命令——本地机器也会被污染
• 弥补手段：把规则写进 CLAUDE.md（项目级或用户级），每次会话自动加载，比手打提示词可靠得多

进阶玩法是挂一个 SSH MCP Server，把 ssh 封装成标准工具，比纯提示词约束稳定。但那是另一篇文章的工程量。

四、方案 C：Codex CLI —— 同一条路线，另一家模型

OpenAI 的 Codex CLI 和 Claude Code 是同类产品：本地运行、内置 shell 工具、靠提示词或配置文件约束远程纪律。

安装与启动

npm install -g @openai/codex
codex            # 交互式 TUI
codex exec "巡检远程服务器……"   # 非交互模式，适合脚本和 CI

与 Claude Code 的差异（运维场景相关的几条）

运维用法完全一致：开场提示词声明「所有操作走 ssh 到 ubuntu@x.x.x.x，高危命令先确认」，然后让它干活。它同样无状态、同样会提示词漂移，规则文件（AGENTS.md）同样能治标。

注意一个容易混的变体：ChatGPT 桌面版有个「SSH 主机连接」功能，可以让 Codex 直接跑在远程项目上——但那个模式要求在远程主机安装 codex CLI 并启动 app server，不符合本文「服务器只开 sshd」的架构。要严格遵守零远程依赖，就用 CLI 模式自己拼 ssh 命令。

五、方案 D：OpenClaw —— 先搞清楚它的拓扑，它是反的

OpenClaw 是四款里最特殊的，因为它的默认架构和本文架构方向相反。

OpenClaw 的设计是 Gateway 常驻：Agent 本体（Gateway + 模型推理）跑在某台常开的机器上（VPS、家用服务器），手机、笔记本、Telegram 等作为客户端远程连接它。官方文档里到处是「把 Gateway 装在 VPS 上」的教程。换句话说：OpenClaw 的默认姿势是 Agent 住在服务器上，而本文的架构是 Agent 在本地、服务器只开 sshd。

如果你已经用 OpenClaw 且不想换，有两条路管远程服务器：

路线 1：Node Host（能力最强，但服务器上要装东西）

OpenClaw 支持「节点」机制：在一台机器上跑一个轻量 node 进程，连回本地 Gateway（WebSocket，跨网络走 SSH 隧道），Agent 的 exec 工具可以路由到这台机器执行。官方文档原话：agent 可以在不手动 SSH 的情况下在远程机器上跑命令。

# 远程机器上启动 node host，连回本地 gateway（127.0.0.1:18789 是 SSH 隧道转发的端口）
openclaw node run --host 127.0.0.1 --port 18790 --display-name "Build Server"

# 把 agent 的 exec 默认路由到该节点
openclaw config set tools.exec.host node
openclaw config set tools.exec.security allowlist
openclaw config set tools.exec.node "Build Server"

# 命令白名单（不在名单里的命令需逐条人工审批）
openclaw approvals allowlist add --node "Build Server" "/usr/bin/systemctl"
openclaw approvals allowlist add --node "Build Server" "/usr/bin/apt"

优点：审批机制是硬性的（allowlist + 逐条确认，网关和模型都无法单方面在远程机器上执行任意命令），审计也完整。缺点：远程机器上必须装 OpenClaw 的 node 进程——它不符合「服务器只开 sshd」的纯净原则。适合「远程机器本来就是我自己的服务器」的场景，用白名单反而比裸 sshd 更可控。

路线 2：提示词约束（同 Claude Code / Codex）

让 OpenClaw 的 agent 在本地生成 ssh 命令。能用，但和 B/C 一样有提示词漂移问题，而且绕过了 OpenClaw 最有价值的审批体系——不推荐。

六、安全基线（四款工具通用，最重要的一节）

Agent 能执行任意远程 shell，这就是一把钥匙。钥匙链必须这么挂：

1. 远程禁用 root 登录，用普通用户 + sudo 提权
2. sudo 只给最小权限：不要 NOPASSWD: ALL，用命令白名单（示例见下）
3. 高危操作强制人工确认：rm -rf、mkfs、卸载内核、重启服务器，Agent 一律不许自动执行
4. SSH 全部走密钥，禁用密码登录
5. 审计：所有下发给远程服务器的指令留本地日志。用方案 A 的 ssh_run 封装，这一步最省事
6. 公网暴露的服务器，绝不给 Agent 开放无限制 sudo

sudo 有限免密示例（远程 Ubuntu visudo）

ubuntu ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt, /usr/bin/df, /usr/bin/free
# rm、shutdown、mkfs 不给免密——高危命令必须人工输入密码

Agent 跑巡检、看服务状态、装包是高频操作，免密提升效率；删库、重启是低频高危操作，卡一道人工确认，成本可接受。

七、四方案横向对比

八、怎么选

• 日常运维主力，追求省心：Hermes。架构最贴合，长会话状态保持，终端工具就是本地 shell，自定义 ssh_run 封装一层就是完整审计
• 已经在用 Claude 系、不想折腾：Claude Code。开箱即用，把规则写进 CLAUDE.md，临时排查、简单任务足够
• OpenAI 生态、喜欢脚本化：Codex CLI。用法跟 Claude Code 同构，codex exec 在 CI 里最顺手
• 已经深度绑定 OpenClaw：用 Node Host + allowlist。别硬套提示词方案，浪费它最强的审批机制

最后一句：架构对了，工具只是顺手；架构错了，换什么工具都是裸奔。 Agent 拿的是能执行任意命令的钥匙，钥匙链上的每一道锁——密钥登录、最小 sudo、高危确认、审计日志——都比选哪款工具重要。

版权声明：本文首发于 cn-res.vip，作者 Grout。

Here's the short version: if you want an AI to manage your remote servers, the right architecture is an AI agent that lives on your local machine and drives the Ubuntu server over SSH. The server runs nothing but sshd — no Node, no Claude Code, no Hermes. All LLM reasoning, planning, and tool calls happen locally; the only server-side software is OpenSSH Server.

Why this is the clean setup: the server has zero AI dependencies and a small attack surface. Keys and API tokens stay in your hands. Every remote command the agent issues can be logged locally for audit. The server is just a normal Linux box — swap the agent, swap the model, and the server doesn't move a muscle.

The real question is which local agent to pick. OpenClaw, Hermes, Claude Code, and Codex are the four names everyone is comparing right now — but their architectures and remote capabilities differ a lot, and one of them is even wired backwards. This article runs the same architecture through all four: examples, comparison, and a security baseline.

1. The core architecture: agent on your machine, sshd only on the server

Your local machine (Windows / macOS / Linux)
 ┌─────────────────────────────────┐
 │  Hermes / OpenClaw / Claude Code│← reasoning, planning, tool calls (all local)
 │  / Codex (the agent itself)     │
 │  OpenSSH client (local ssh)     │
 └───────────────┬─────────────────┘
                 │ SSH (key auth)
                 ▼
Remote Ubuntu server
 ┌─────────────────────────────────┐
 │  openssh-server (the only service) │
 │  no node, no claude, no hermes  │
 └─────────────────────────────────┘

Prep work (do once, shared by all four tools)

Local: install the OpenSSH client (built into Windows 11 — check ssh -V), plus git.

Remote Ubuntu:

sudo apt install openssh-server
sudo systemctl enable --now ssh
# Edit /etc/ssh/sshd_config:
#   PasswordAuthentication no   ← disable password login
#   PermitRootLogin no          ← no direct root login
sudo systemctl restart ssh

Generate a key locally and push it (automation needs passwordless SSH, so no passphrase):

ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_remote_ubuntu

ssh-copy-id -i ~/.ssh/id_remote_ubuntu ubuntu@remoteip

# Verify: no password prompt
ssh -i ~/.ssh/id_remote_ubuntu ubuntu@remoteip

2. Option A: Hermes local agent — native terminal tool, zero glue code

Hermes Agent (NousResearch, open source, a single Go binary) fits this architecture better than any of the other three: it was designed to run the agent locally and execute commands locally. Its terminal tool just calls your local shell, so you feed it an ssh command and it runs. No plugin code required.

Install

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
hermes setup   # configure model providers: Anthropic / OpenAI / DeepSeek / local models, 20+

Note: the "git clone + python venv + pip install" instructions floating around belong to an early version or a different project with the same name. The official build is a compiled binary — install and go.

Example: remote inspection

Just tell local Hermes:

Inspect the remote Ubuntu server (ubuntu@192.168.1.100, key ~/.ssh/id_remote_ubuntu): check disk, memory, and failed system services, find anomalies, and suggest fixes. Do NOT auto-run destructive operations (deletes, service restarts) — report first.

What the agent does:

1. Plan: decide to run free -h, df -h, systemctl list-units --failed in sequence
2. Execute: call the terminal tool with ssh -i ~/.ssh/id_remote_ubuntu ubuntu@192.168.1.100 "free -h"
3. Analyze: read the remote output, keep reasoning, decide what's next
4. Report: hand you an inspection report. All of it happens locally

Advanced: wrap ssh in a dedicated tool (audit + guardrails)

Hermes supports custom tools (Python plugins). Wrapping "run remote command" behind a single function gives you one choke point: log every command, block dangerous ones, force human approval — enforced in code, not by prompt.

def ssh_run(command: str) -> str:
    """
    Run a shell command on the remote Ubuntu (via local ssh client).
    """
    import os, subprocess
    target = os.environ["REMOTE_SSH_TARGET"]   # ubuntu@192.168.1.100
    keyfile = os.environ["REMOTE_SSH_KEY"]     # ~/.ssh/id_remote_ubuntu
    result = subprocess.run(
        ["ssh", "-i", keyfile, target, command],
        capture_output=True, text=True, timeout=120,
    )
    return (f"stdout:\n{result.stdout}\nstderr:\n{result.stderr}\n"
            f"returncode:{result.returncode}")

Add three safeguards inside: append every command to an audit log; reject rm -rf|mkfs|dd|shutdown|reboot and require human confirmation; enforce the timeout. Then even if the model goes rogue, there's a hard gate.

3. Option B: Claude Code CLI — zero setup, prompt discipline

Claude Code has no native "remote server mode," but it's a complete locally-run agent with a built-in Bash tool. So the route is: let it generate ssh commands locally and run them through your OpenSSH client. Zero remote dependencies — architecture-compliant.

Install and start

npm install -g @anthropicai/claudecode
claude

Opening prompt (the critical part)

Remote discipline in Claude Code lives entirely in the prompt, so restate it at the start of every session:

Rules: you run on the local machine. Never run server operations on this machine — always go through ssh to remote Ubuntu ubuntu@192.168.1.100, key ~/.ssh/id_remote_ubuntu. For remote operations, generate a local ssh command, e.g.: ssh -i ~/.ssh/id_remote_ubuntu ubuntu@192.168.1.100 "df -h". Dangerous commands (rm, formatting, apt remove, service restarts) require my explicit approval first — never auto-run. Task: inspect the remote server's CPU, memory, disk, and failed systemd units.

The limits of this route

• Stateless: every ssh call is one-shot; Claude Code doesn't maintain a remote session context. Long multi-step troubleshooting means re-feeding context into the prompt
• Prompt drift: in a long session the model may forget the "everything goes through ssh" rule and run commands locally — polluting your own machine
• Mitigation: put the rules in CLAUDE.md (project-level or user-level) so every session loads them automatically — far more reliable than typing the prompt each time

A more advanced move is an SSH MCP Server, wrapping ssh as a standard tool instead of relying on prompt discipline. That's a whole other article.

4. Option C: Codex CLI — same route, another model family

OpenAI's Codex CLI is the same species as Claude Code: local agent, built-in shell tool, remote discipline enforced via prompt or config file.

Install and start

npm install -g @openai/codex
codex            # interactive TUI
codex exec "inspect the remote server..."   # non-interactive, good for scripts and CI

Differences from Claude Code (ops-relevant)

Ops usage is identical: open with a prompt declaring "all operations go through ssh to ubuntu@x.x.x.x, dangerous commands need approval," then let it work. Same statelessness, same drift risk, same AGENTS.md fix.

One trap: the ChatGPT desktop app has an "SSH host connection" feature that runs Codex directly on a remote project — but that mode requires installing the Codex CLI and starting an app server on the remote host. It violates the "sshd only" architecture. If you want strict zero remote dependencies, use the CLI and build ssh commands yourself.

5. Option D: OpenClaw — check the topology first, it's backwards

OpenClaw is the odd one out because its default architecture points the other way.

OpenClaw is designed around an always-on Gateway: the agent itself (gateway + model reasoning) runs on a machine that never sleeps (a VPS or home server), and phones, laptops, and Telegram connect to it as clients. The official docs are full of "deploy the Gateway on your VPS" guides. In other words, OpenClaw's default posture is the agent lives on the server — the exact opposite of "agent local, sshd only."

If you're already on OpenClaw and want to manage remote servers, two routes:

Route 1: Node Host (most capable, but the server needs software)

OpenClaw has a "node" mechanism: a lightweight node process on a machine connects back to your local Gateway (WebSocket; SSH tunnel across networks), and the agent's exec tool can be routed to run on that machine. The docs' own words: the agent can run shell commands on a remote machine without you SSH-ing in manually.

# On the remote machine, start a node host back to your local gateway
# (127.0.0.1:18790 is the SSH-tunneled port)
openclaw node run --host 127.0.0.1 --port 18790 --display-name "Build Server"

# Route agent exec to that node by default
openclaw config set tools.exec.host node
openclaw config set tools.exec.security allowlist
openclaw config set tools.exec.node "Build Server"

# Command allowlist (anything not listed needs per-call approval)
openclaw approvals allowlist add --node "Build Server" "/usr/bin/systemctl"
openclaw approvals allowlist add --node "Build Server" "/usr/bin/apt"

Upside: the approval mechanism is hard enforcement (allowlist + per-call confirmation; neither the gateway nor the model can unilaterally run arbitrary code on the remote machine), and auditing is complete. Downside: the OpenClaw node process must be installed on the remote machine — it breaks the "sshd only" purity. It shines when the remote machine is already your own server: the allowlist actually gives you more control than bare sshd.

Route 2: prompt discipline (same as B/C)

Have the OpenClaw agent generate local ssh commands. It works, but it has the same drift problem as B/C while throwing away OpenClaw's best asset — its approval system. Not recommended.

6. Security baseline (universal, most important section)

An agent that can execute arbitrary remote shell commands is a master key. Chain it like this:

1. No root login — normal user + sudo escalation
2. Least-privilege sudo — no NOPASSWD: ALL; use a command allowlist (example below)
3. High-risk ops require human confirmation — rm -rf, mkfs, kernel removal, server reboot: never auto-run
4. Key-only SSH, password login disabled
5. Audit — log every command sent to the remote server. The ssh_run wrapper in Option A makes this trivial
6. Never give an agent unrestricted sudo on a publicly exposed server

Limited passwordless sudo example (remote Ubuntu visudo)

ubuntu ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt, /usr/bin/df, /usr/bin/free
# rm, shutdown, mkfs are NOT passwordless — dangerous commands require the password

Inspection, service status, and package installs are high-frequency — passwordless is efficient. Deletes and reboots are low-frequency, high-risk — one human check is a cheap price.

7. Side-by-side comparison

8. How to choose

• Daily ops driver, want zero fuss: Hermes. Best architecture fit, stateful long sessions, terminal tool is your local shell, and one ssh_run wrapper buys you a complete audit trail
• Already in the Claude ecosystem: Claude Code. Works out of the box; put the rules in CLAUDE.md; fine for ad-hoc checks and simple tasks
• OpenAI ecosystem, like scripting: Codex CLI. Same shape as Claude Code, and codex exec is the smoothest for CI
• Already deeply invested in OpenClaw: use Node Host + allowlist. Don't settle for the prompt hack — you'd be wasting its strongest feature

Last word: get the architecture right and the tool is just a preference; get it wrong and no tool can save you. The agent holds a key that can execute anything — the locks on that keychain (key-only login, minimal sudo, human confirmation, audit logs) matter more than which agent you pick.

© cn-res.vip — Grout