Ist OpenClaw 2.0 auf einem VPS sicher? 7-Tage-Check von Rechten, SSH und API-Keys

OpenClaw 2.0 auf einem Linux-VPS zu installieren ist der leichte Teil. Ein Gateway, das im Chat antwortet, ist nicht dieselbe Maschine, die man eine Woche allein lassen würde. Die Host-Installation ist konservativ: Loopback-Bind, Pairing-Codes für unbekannte DMs, Gruppen nur auf Erwähnung. Was am siebten Tag noch beißt, ist das Trio, das der Installer nicht nachzieht — Sandbox aus, Sitzungswerkzeuge mit Blick auf das ganze Gateway, Modell-API-Schlüssel, die in Dateien liegen können, die der Agent lesen darf.

Wir haben dieselbe Ubuntu-Cloudbox sieben Tage als Einzeloperator mit Remote-API und einem Telegram-Kanal laufen lassen. Jeden Tag eine Aufgabe: Rechte, SSH und Listener, API-Schlüssel, Browser, Agent-Isolation. Das Urteil: im eigenen Vertrauensbereich darf sie weiterlaufen. Eine Mandantengrenze ist das nicht. Die offizielle Doku sagt das auf dem ersten Bildschirm. Die Größe der Box steht in den OpenClaw-2.0-Notizen zu CPU, RAM und Disk; hier fragen wir nur, welche Türen nach einer Woche noch offen waren.

Kurze Antwort: sicher, aber mit Vertrag

OpenClaw behandelt ein Gateway als eine Vertrauensgrenze — ein Operator oder ein kleines Team, das sich bereits vertraut. Feindliche Nutzer, getrennte Kunden, getrennte Geschäftslinien brauchen eigene Gateways und eigene Credentials, idealerweise eigenen OS-User oder Host. Das steht in den OpenClaw-Gateway-Sicherheitsdocs, nicht in einem Blog-Schmucksatz. Mit der Note „Multi-Tenant-SaaS“ fallen fast alle Defaults durch. Mit der Note „meine eigene Dienstbox“ halten die meisten.

Wir haben openclaw security audit jeden Tag neu laufen lassen. Tag eins war kein nackter Port — eine Host-Installation bleibt auf Loopback, 18789 taucht in einem öffentlichen Scan nicht auf. Laut waren Host-Tool-Exec und Gateway-weite Sitzungssicht. Lässt man das liegen und hängt ein Browser-Skill plus eine „nur-lesen-Familie“-Persona an, springt der Blast-Radius von „diese VM“ auf „jedes Transkript und jedes Geheimnis auf dieser VM“.

Sieben Tage, ohne „kein Vorfall“ als Bestanden zu werten

Die Box war 2 vCPU / 8 GB Ubuntu 24.04, natives install.sh, Remote-API, systemd-User-Unit. SSH nur mit Keys, Passwortlogin aus. Das Gateway blieb auf bind: loopback; die Control UI erreichten wir über einen SSH-Local-Forward und öffneten 18789 nie in der Cloud-Security-Group. Telegram blieb auf Pairing. Die Docker-Sandbox ließen wir absichtlich aus, damit Tag sieben die echte Default-Haltung zeigt.

Jeden Morgen drei Artefakte: openclaw security audit --json, ss -lntp gegen die Provider-Firewall, und ein Sweep von Rechten plus Klartext-Keys unter ~/.openclaw. Wir haben nicht bewertet, ob eine Prompt-Injection „geklappt“ hat. Wir haben Config-Drift bewertet und Dateien, die der Agent (oder wir) weltlesbar liegen ließen.

Check 1: Rechte — Exec landet weiter auf dem Host

Sandboxing in OpenClaw 2.0 ist optional. Das Gateway bleibt immer auf dem Host; Tools wandern erst nach agents.defaults.sandbox nach Docker oder Podman. Ist das aus, fällt host=auto auf die Gateway-Maschine. Für einen persönlichen Assistenten, dem man vertraut, ist das angenehm. Für einen Dienstbot, der Links, Forwards und Anhänge sieht, verdrahtet das Prompt-Injection mit der Shell des Deploy-Users.

Das Audit am ersten Tag hielt zwei Notizen: großer Tool-Blast-Radius und security="full" — der dokumentierte Trusted-Operator-Default, kein CVE. Unser Schnitt: der persönliche Agent darf Host-Exec behalten, wenn Pairing an ist, Datei-Tools nur den Workspace sehen und tools.elevated aus ist. Ein zweiter Agent für Familie oder öffentlichen Raum braucht sandbox.mode: "all", Workspace ro oder none, und Deny für exec, browser, gateway und cron.

Verzeichnismodi driften schneller, als man denkt. Ein scp vom Laptop, ein Docker-Volume oder das Kopieren von openclaw.json durch den Agenten macht aus 600/700 schnell 644/755. openclaw security audit --fix zieht State- und Config-Modi fest. Sandboxing schaltet es nicht ein. Fahren Sie das Gateway als eigenen Linux-User, damit Keys, Sitzungsspeicher und Workspace in diesem Home liegen — nicht unter ubuntu oder root.

Check 2: SSH und Bind — Steuerebene vom öffentlichen Netz fernhalten

Tag zwei war ein Scan von außen. Auf dem Host-Install-Pfad lauschte 18789 nur auf 127.0.0.1. Die Security Group ließ 22 durch. Der Scanner sah das Gateway nicht. Das ist der dokumentierte Default für einen normalen Host und der ruhigste Fund der Woche. Container-Images sind die andere Geschichte: sie binden standardmäßig offen und müssen mit Auth ausgeliefert werden. Veröffentlichte Docker-Ports sind nicht „so sicher wie eine Host-Installation“.

Bei SSH verlangten wir nur drei Dinge: kein Passwortlogin, kein Root-Passwort, keine antiken Key-Typen. Fernzugriff aufs Gateway lief über SSH-Tunnel (oder Tailscale), nicht über „Control UI auf 443 reverse-proxyn und das Token vergessen“. HTTP und WebSocket teilen einen Port, inklusive Control UI und Agent-Widgets. Die offizielle Linie behandelt diese Widgets als untrusted Content. Nicht auf denselben Origin wie eine bereits eingeloggte Admin-App legen.

Veröffentlichte Container-Ports überspringen das Host-INPUT und fahren in Dockers eigener Forward-Kette. Die Security-Docs nennen die Kette DOCKER-USER. Läuft ein Container, erneut gegen die öffentliche IP testen, nicht gegen ss im Namespace. Für den Schnitt Firewall gegen Loopback gilt die Linux-Matrix zu Minimalexposition, SSH und HTTPS; danach hierher zurück und fragen, ob jemand den Bind in der Woche auf 0.0.0.0 gedreht hat.

Node-Pairing ist ebenfalls eine SSH-Fläche. sshVerify liest die Geräteidentität über Operator-SSH zurück; Erreichbarkeit allein genehmigt nicht. autoApproveCidrs ist standardmäßig aus und gilt nur für eine erstmalige, scopelose Node-Rolle. Beide Defaults ließen wir. Bequemlichkeit ist kein Grund, eine zweite Maschine automatisch zu genehmigen.

Check 3: API-Keys — Klartext auf der Platte bleibt agent-lesbar

Tag drei war ein Secret-Sweep. OpenClaw 2.0 hat SecretRefs: Provider-apiKey-Felder, das Gateway-Token und manche Kanal-Credentials können aus env, file, exec oder store aufgelöst werden. Klartext funktioniert weiter. SecretRefs sind opt-in pro Feld. „Wir sind auf 2.0“ heißt nicht „die Keys haben die Platte verlassen“.

Das Risiko ist nicht „ein Key existiert auf der Dienstbox“. Das Risiko ist ein Key dort, wo read oder exec ihn öffnen kann: openclaw.json, .env, erzeugtes agents/*/agent/models.json, abgelegte Auth-Profile-Archive. Prompt-Injection muss SSH nicht knacken, wenn das Modell „lies die Config und kleb sie in den Chat“ macht. Der OpenClaw-Secrets-Guide wertet die Migration erst als fertig, wenn unterstützte Felder SecretRefs sind, alter Klartext weg ist und openclaw secrets audit --check sauber bleibt. Credentials ohne SecretRef brauchen weiter OS-User, Container oder einen externen Proxy.

Das Gateway-Token ist eine eigene Klasse. Ein Shared Secret, das /v1/chat/completions, /tools/invoke oder Admin-RPC rufen kann, ist ein volles Operator-Credential. Nicht in den Agent-Workspace, nicht ins Skill-Repo, nicht „der Bequemlichkeit wegen“ in einen zweiten Bot. Rotation ist kurz: neues Token, Neustart, Clients aktualisieren, beweisen, dass der alte Wert tot ist. Wir haben Modell-Keys auf Env-SecretRefs gelegt und das Gateway-Token in einer Env-Datei nur für den Deploy-User belassen. Im Workspace stand keine sk--Zeile mehr.

Check 4: der Browser — Sie geben dem Modell die Hände des Operators

Tag vier haben wir ein Browser-Skill eingeschaltet und am selben Tag wieder aus. Nicht weil Chromium RAM frisst — 8 GB überstehen einen Durchlauf — sondern weil Remote-Browsersteuerung dokumentiert Operator-Zugang entspricht. Der Agent erbt Logins, Cookies und gespeicherte Passwörter dieses Profils. Ihr tägliches Chrome-Profil ist kein Tool.

Isolation ist geschichtet: eigenes Profil, Passwortmanager und Sync aus, separates Download-Verzeichnis als untrusted, Steuerports nur auf Loopback oder Tailnet, nie Funnel. OpenClaw 2.0 kann einen sandboxed Browser im eigenen Container auf openclaw-sandbox-browser fahren, allowHostControl standardmäßig aus. SSRF bleibt streng; private Ziele bleiben blockiert, solange Sie dangerouslyAllowPrivateNetwork nicht setzen. Wir ließen das aus.

Extension-Relays und Remote-CDP heißen: wer den Tab sieht, ist diese Person. Existing-Session-Modus ist nicht sicherer, er ist nur mehr Sie. Ein Node auf einer Desktop-Maschine ist nach dem Pairing Admin. Gateway und Node gehören ins selbe private Netz. Regel der Woche: Textassistenten brauchen keinen Browser. Wenn doch, ein Profil ohne persönliche Konten, und keinen RAM mit einem lokalen 7B-Modell teilen.

Check 5: Agent-Isolation — Defaults sind keine Mandanten

An Tag fünf und sechs kam ein zweiter, read-only Agent dazu. Wir gingen von getrennten Sitzungen aus. Falsch. Default tools.sessions.visibility ist all; tools.agentToAgent.enabled ist true. Ein unsandboxter Agent kann Sitzungen anderer Agents listen, suchen und lesen — inklusive der Persona, die „Familie, nur lesen“ sein sollte. Sandboxed Caller bleiben auf ihrem Spawn-Baum, aber das versteckt ihre Transkripte nicht vor einem unsandboxten Hauptagenten.

Persona-Trennung auf einem Gateway heißt Sichtbarkeit agent oder self, Agent-to-Agent aus oder allowlisted, und kein scope: "shared"-Sandbox. Können mehrere Personen den Bot per DM erreichen, setzen Sie session.dmScope auf per-channel-peer, sonst rollt jede DM in die Hauptsitzung. Das sind Kollaborationsgeländer, keine feindlichen Mandantenwände. Kunde A und Kunde B brauchen zwei Gateways.

Control-Plane-Tools brauchen denselben Haarschnitt. gateway liest Config (Topologie und Secret-Hinweise). cron läuft weiter, wenn Sie offline sind. Jeder Agent, der untrusted Content sieht, sollte beides denyen, plus sessions_spawn und sessions_send. Plugins und Skill-Bäume sind trusted Code: Quellen pinnen, plugins.allow nutzen, nach Änderungen neu starten.

Tag 7: was driftete, was nicht

Letzter Durchgang: Bind noch Loopback, Pairing noch Pairing, niemand hatte 18789 in der Security Group geöffnet. Was driftete, war eine Debug-.env-Kopie im Workspace und ein auskommentiertes allowHostControl vom Browserversuch — knapp davor, beim Merge in die „Produktions“-Datei zu wandern. Nach --fix waren die Dateimodi sauber. Solange die Sandbox am Hauptagenten aus bleibt, labelt das Audit die Haltung weiter als Trusted-Operator, nicht als Multi-User.

Die Tabelle als Entscheidung lesen: OpenClaw 2.0 darf eine Woche oder ein Jahr auf einem VPS bleiben, wenn Sie ein Gateway als eine Vertrauensdomäne akzeptieren und das Audit vor einer zweiten Persona, einem Browser oder einem öffentlichen Reverse-Proxy neu laufen lassen. Sie brauchen kein neues Feature. Die Default-Geschichte „ich vertraue dem Operator“ muss zu Ihrer tatsächlichen Bedrohung passen.

Zumachen: eine Liste Szene für Szene

Nicht in einer Sitzung „Enterprise Zero Trust“ jagen. Die Bedingungen aufschreiben, die für den Workload von heute Nacht alle wahr sein müssen. Wenn sie sich beißen, Maschinen teilen. Extra-Ausnahmen in einer Config sind teurer als eine zweite Box.

Zwei Ops-Pflichten sind Security-Pflichten: Tokens in Logs und Plugins aus einer Quelle, die Sie nicht gelesen haben. Redaction und Rotation an; plugins.allow pinnen. Dann entscheiden, ob die Linux-Dienstbox Operator-Keys weiter halten soll — oder ob die Keys auf eine ruhigere Steuerebene gehören.

FAQ

Nur Text, Stock-Defaults — sieht ein öffentlicher Scan das Gateway?

Eine Host-Installation auf Loopback zeigt 18789 nicht im öffentlichen Netz. Zuerst Pairing schließen. Ein Fremder, der Sie schon per DM erreichen kann, ist der echte erste Hop, nicht nmap.

Ist Docker automatisch sicherer?

Images helfen bei Rollback und Dateisystemisolation. Offizielle Container binden standardmäßig offen, veröffentlichte Ports umgehen Host-INPUT. Ohne Auth und externen Retest ist Docker meist riskanter, nicht sicherer.

Ersetzt audit --fix Handarbeit?

Nein. Es zieht offene Gruppenrichtlinien auf Allowlists zurück und setzt 600/700. Es schaltet keine Sandbox ein, migriert keine SecretRefs und verengt die Sitzungssicht nicht.

Kann das Modell den API-Key selbst lesen?

Sitzt Klartext noch auf einem agent-lesbaren Pfad, öffnen ihn Datei-Tools oder Exec. SecretRefs schrumpfen den Plattenrückstand. Sie sind keine Prozessisolation. Untrusted Content nicht mit Host-Exec kombinieren.