OpenClaw sicher auf einem VPS betreiben

Was OpenClaw ist und warum Sie es zuerst absichern

OpenClaw ist ein selbst gehosteter KI-Agent. Sie betreiben ihn auf Ihrem eigenen Server, verbinden ihn mit einem Large Language Model, und er kann Shell-Befehle ausführen, einen Browser steuern, Ihre Dateien lesen und schreiben sowie auf Nachrichten reagieren, die Sie ihm aus Chat-Apps senden. Diese Reichweite ist der eigentliche Zweck des Tools und zugleich das gesamte Risiko. Ein Agent, der beliebige Befehle ausführen kann, ist nur so sicher wie das System, auf dem er läuft, und wie die Einschränkungen, die Sie für ihn festlegen.

Zwei Tatsachen bestimmen den Schwerpunkt dieses Leitfadens. Erstens ist OpenClaw dafür ausgelegt, von Ihnen abgesichert zu werden. Sein Sicherheitsmodell legt die Verantwortung für strenge Tool-Richtlinien, Sandboxing und sorgfältig gesetzte Berechtigungen beim Administrator, nicht bei sicheren Standardeinstellungen. Zweitens gab es bereits ein schwerwiegendes Sicherheitsereignis im Projekt: Im März 2026 wurden innerhalb von vier Tagen neun Sicherheitsprobleme offengelegt, darunter eine kritische Schwachstelle zur Rechteausweitung, CVE-2026-32922, mit einer Bewertung von 9.9 von 10. Keine dieser Tatsachen bedeutet, dass Sie OpenClaw vermeiden sollten. Sie bedeuten, dass Sie es nicht auf die nachlässige Art betreiben sollten. Dieser Leitfaden zeigt die sorgfältige Vorgehensweise. Dazu gehört, von Anfang an festzulegen, was der Agent ohne Rückfrage tun darf. Claude Code macht diese Entscheidung mit seinen Berechtigungsmodi explizit. Ein Server, vor dem Sie nicht sitzen, verdient dabei eine strengere Einstellung als der Laptop, den Sie gerade beobachten.

Es gibt auch gute Nachrichten. OpenClaw trifft bereits eine sichere Entscheidung für Sie: Sein Gateway, der einzelne Prozess, der alles steuert, lauscht standardmäßig an der Loopback-Adresse. Dadurch ist es nicht aus dem Internet erreichbar, solange Sie es nicht ausdrücklich nach außen freigeben. Bei den meisten folgenden Schritten geht es darum, diesen Zustand beizubehalten und den möglichen Schadensumfang zu begrenzen, falls doch etwas schiefgeht.

OpenClaw einen eigenen Benutzer ohne Privilegien geben

Führen Sie einen Agenten niemals als root aus. Wenn OpenClaw als root läuft und etwas schiefgeht, gibt es für den Schaden keine Begrenzung. Das gilt unabhängig davon, ob ein Fehler, eine fehlerhafte Anweisung oder eine CVE wie die oben genannte die Ursache ist. Erstellen Sie einen dedizierten Systembenutzer ohne Login-Shell und ohne sudo. Führen Sie den Agenten anschließend unter diesem Benutzer aus:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Alles, was OpenClaw besitzt, liegt unter /opt/openclaw und gehört diesem Benutzer. Dies ist der wichtigste einzelne Schritt. Es gilt dasselbe Prinzip wie unter Dienste als Benutzer ohne Privilegien ausführen beschrieben: Der Benutzer, unter dem ein Agent läuft, begrenzt den Schaden, den er anrichten kann.

OpenClaw installieren

OpenClaw wird als npm-Paket bereitgestellt. Installieren Sie daher zuerst Node.js, falls es auf dem Server noch nicht vorhanden ist. Installieren Sie das Paket global. Dadurch befindet sich die openclaw-Binärdatei für alle Benutzer im PATH. Führen Sie anschließend die einmalige Ersteinrichtung aus:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

Wenn Sie die Ersteinrichtung als Benutzer openclaw ausführen, wird die Konfiguration des Agenten in dessen Home-Verzeichnis /opt/openclaw abgelegt und nicht im Home-Verzeichnis von root. Das Projekt bietet außerdem ein curl -fsSL https://openclaw.ai/install.sh | bash-Installationsprogramm, das dieselbe Installation in einer Zeile ausführt. Lassen Sie während der Ersteinrichtung das Flag --install-daemon weg. Andernfalls würde der eigene Dienst von OpenClaw registriert. Die weiter unten erstellte gehärtete systemd-Unit ist strenger.

Gateway auf Loopback belassen, hinter einer Firewall

Das Gateway bindet standardmäßig an 127.0.0.1. Belassen Sie diese Einstellung. Es gibt fast nie einen Grund, diesen Port im Internet zu veröffentlichen. Andernfalls erhält jeder, der ihn findet, einen entfernten Einstiegspunkt in einen Prozess, der Befehle ausführt.

Schalten Sie vor dem Server eine Firewall mit standardmäßiger Ablehnung ein, damit nichts versehentlich erreichbar ist:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Vermeiden Sie dabei zwei typische Fallen. Eine Firewall, die nur IPv4 abdeckt, kann denselben Dienst über IPv6 weiterhin vollständig offen lassen. Genau diese IPv6-Firewall-Lücke führt bei vielen zu Problemen. Wenn Sie das Gateway von Ihrem Laptop aus erreichen müssen, öffnen Sie den Port nicht. Greifen Sie stattdessen über ein VPN oder einen SSH-Tunnel darauf zu. Der Agent lauscht dann niemals im offenen Internet.

Isolieren Sie seine Geheimnisse

OpenClaw benötigt einen API-Schlüssel für das von Ihnen angebundene Sprachmodell. Mit diesem Schlüssel können Kosten entstehen. Über den Agenten kann er außerdem in Ihrem Namen Aktionen ausführen. Behandeln Sie ihn daher wie ein Passwort. Speichern Sie ihn weder in der Unit-Datei noch in einem Repository. Legen Sie ihn in einer Datei ab, die nur der OpenClaw-Benutzer lesen kann:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

Die systemd-Unit lädt diese Datei mit EnvironmentFile. Dadurch erreicht der Schlüssel den Prozess, ohne jemals in einer Befehlszeile, einem Log oder Ihrer Shell-History zu stehen. Dieses Muster gilt für jedes Geheimnis auf dem Server: Ein Hardening-Durchlauf für selbst gehostetes Vaultwarden konzentriert sich auf das Admin-Token und die Backup-Datei und nicht auf die Verschlüsselung, weil die Dateiberechtigungen tatsächlich bestimmen, wer ein im Ruhezustand gespeichertes Geheimnis lesen kann.

Führen Sie es als gehärteten systemd-Dienst aus

Wenn Sie den Agent unter systemd ausführen, erhalten Sie automatische Neustarts, übersichtliche Logs über journalctl und vor allem mehrere Sandbox-Optionen auf Kernel-Ebene. Diese schränken den Zugriff des Prozesses ein, selbst wenn der Server kompromittiert wurde. Für einen Agent sind insbesondere NoNewPrivileges wichtig, damit er niemals zusätzliche Berechtigungen erlangen kann, ProtectSystem=strict, damit das Dateisystem nur an den ausdrücklich erlaubten Stellen beschreibbar ist, PrivateTmp für ein eigenes isoliertes temporäres Verzeichnis und ProtectHome, damit er keine Home-Verzeichnisse lesen kann.

Erstellen Sie hier eine vollständige, gehärtete Unit und kopieren Sie sie anschließend nach /etc/systemd/system/openclaw.service:

Die Unit startet openclaw gateway, den langlebigen Prozess, der den Agent steuert. Wenn which openclaw auf Ihrem Server einen anderen Pfad ausgibt, passen Sie ExecStart entsprechend an. Eine vollständige Erläuterung dieser Direktiven sowie von daemon-reload und enable --now finden Sie unter ein Programm als systemd-Dienst ausführen. Kurz gesagt, nachdem Sie die Unit eingefügt haben:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Auch die Zugangsschicht absichern

Ein Agent-Server ist nur so sicher wie das System, auf dem er läuft. Zwei weitere Schutzschichten vervollständigen die Absicherung. Stellen Sie SSH auf eine Authentifizierung ausschließlich mit kryptografischen Schlüsseln um und deaktivieren Sie die root-Anmeldung, wie unter SSH-Härtung auf einem VPS beschrieben. Dadurch kann das Administratorkonto nicht per Brute-Force angegriffen werden. Installieren Sie anschließend Fail2ban, um Scanner zu sperren, die jeden öffentlich erreichbaren Port angreifen. Keine dieser Maßnahmen greift direkt in OpenClaw ein. Beide versperren jedoch die Zugangswege, die ein Angreifer verwenden würde, um OpenClaw zu erreichen.

Gezielt aktuell halten

Die Sicherheitsmeldungen vom März 2026 sind das deutlichste Argument dafür, Software aktuell zu halten. Eine Schwachstelle zur Rechteausweitung in einem Agenten ist wesentlich schwerwiegender als in einer gewöhnlichen Webanwendung, weil der Agent bereits Befehle ausführt. Beobachten Sie die Releases des Projekts, installieren Sie Sicherheitsupdates zeitnah und behandeln Sie ein OpenClaw-Upgrade als routinemäßige Wartung, statt es aufzuschieben.

Um zu verstehen, welche Komponenten Sie tatsächlich absichern, erläutert die Architektur eines OpenClaw-ähnlichen Agenten die einzelnen Bestandteile. Einen eigenen KI-Agenten auf einem VPS erstellen beschreibt die allgemeine Struktur eines Agenten. Wenn Sie zusätzlich einen zweiten Agenten betreiben, beachten Sie, dass zwei Claude-Code-Sitzungen auf einem VPS Aufgaben aneinander übergeben können. Jeder Agent benötigt daher ein eigenes Konto und eigene Grenzen, statt Ihre Einstellungen zu übernehmen.

FAQ

Ist es sicher, OpenClaw auf einem öffentlichen VPS zu betreiben?

Das kann es sein, wenn Sie den Dienst absichern. OpenClaw ist bewusst leistungsfähig: Es führt Shell-Befehle aus und steuert einen Browser. Eine sorglose Konfiguration ist daher tatsächlich gefährlich. Außerdem gab es bereits eine kritische CVE (CVE-2026-32922 im März 2026). Das Sicherheitsmodell setzt voraus, dass Sie als Betreiber die Einschränkungen festlegen. Führen Sie OpenClaw als nicht privilegierten Benutzer aus, binden Sie sein Gateway hinter einer standardmäßig blockierenden Firewall an das Loopback-Interface, isolieren Sie seine API-Schlüssel und betreiben Sie es als gehärteten systemd-Dienst.

Sollte ich das OpenClaw-Gateway aus dem Internet erreichbar machen?

Nein. Das Gateway bindet standardmäßig an das Loopback-Interface. Dabei sollten Sie es belassen. Es ist der einzelne Prozess, der den Agenten steuert. Ein aus dem Internet erreichbares Gateway stellt daher einen entfernten Zugang zu einem Dienst dar, der fortlaufend Befehle ausführt. Wenn Sie remote darauf zugreifen müssen, verwenden Sie stattdessen ein VPN oder einen SSH-Tunnel. Öffnen Sie den Port nicht.

Unter welchem Benutzer sollte OpenClaw ausgeführt werden?

Unter einem dedizierten Systembenutzer ohne Login-Shell und ohne sudo, niemals unter root. Wenn der Agent kompromittiert wird, begrenzt sein Benutzerkonto den möglichen Schaden. Dieses Konto sollte daher nur seine eigenen Dateien unter einem Verzeichnis wie /opt/openclaw besitzen und keine weiteren Dateien.

Wie schütze ich die API-Schlüssel von OpenClaw?

Speichern Sie sie in einer Datei, die nur für den OpenClaw-Benutzer lesbar ist (Modus 600), und laden Sie sie mit systemd über EnvironmentFile in den Dienst. Der Schlüssel darf nicht in der Unit-Datei, in Ihrer Shell-History oder in einem git-Repository stehen. Rotieren Sie den Schlüssel, sobald Sie vermuten, dass er offengelegt wurde.