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-Anwendungen senden. Diese Reichweite ist der eigentliche Zweck des Tools, aber auch das gesamte Risiko. Ein Agent, der beliebige Befehle ausführen kann, ist nur so sicher wie die Umgebung, in der er läuft, und die Beschränkungen, die Sie ihm auferlegen.

Zwei Fakten geben den Ton für diesen Leitfaden an. Erstens ist OpenClaw darauf ausgelegt, von Ihnen abgesichert zu werden. Sein Sicherheitsmodell überträgt die Verantwortung für strikte Tool-Richtlinien, Sandboxing und sorgfältige Berechtigungen auf den Betreiber, nicht auf eine sichere Standardkonfiguration. Zweitens hat das Projekt bereits eine schwere Sicherheitsphase hinter sich: Die National Vulnerability Database listet allein im März 2026 199 CVEs für OpenClaw auf, davon 46 in den vier Tagen vom 4. bis zum 7. März (Stand der Zählung: 13. Oktober 2026). Zu den Schwachstellen dieses Monats gehört eine kritische Privilegieneskalation, CVE-2026-32922, die mit 9,9 von 10 Punkten bewertet und in Version 2026.3.11 behoben wurde. Keiner dieser Fakten bedeutet, dass Sie OpenClaw meiden sollten. Sie bedeuten, dass Sie es nicht auf die bequeme Art betreiben sollten; dieser Leitfaden zeigt den sorgfältigen Weg. Teil dieses sorgfältigen Weges ist die Entscheidung im Voraus, wie viel der Agent ohne Nachfrage tun darf – eine Wahl, die Claude Code mit seinen Berechtigungsmodi explizit macht, wobei ein Server, vor dem Sie nicht direkt sitzen, eine strengere Einstellung erfordert als der Laptop, den Sie im Blick haben.

Es gibt auch gute Nachrichten. OpenClaw trifft bereits eine sichere Entscheidung für Sie: Sein Gateway, der zentrale Prozess, der alles steuert, lauscht standardmäßig auf der Loopback-Adresse. Es ist also nicht aus dem Internet erreichbar, es sei denn, Sie unternehmen explizite Schritte, um es freizugeben. Der Großteil der folgenden Arbeit besteht darin, diesen Zustand beizubehalten und den Schadensradius 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 verteilt. Installieren Sie daher zuerst Node.js, falls der Server es noch nicht hat; das Projekt erfordert Node 24.16 oder neuer, beziehungsweise 26.1 oder neuer. Installieren Sie das Paket global, wodurch die openclaw-Binärdatei für jeden Benutzer in den PATH aufgenommen wird, und führen Sie anschließend den einmaligen Onboarding-Schritt aus:

sudo npm install -g openclaw@latest --allow-scripts=openclaw
sudo -u openclaw openclaw onboard

Das Flag --allow-scripts=openclaw ist notwendig, da npm 12 Installationsskripte von Paketen standardmäßig blockiert, OpenClaw jedoch eigene Skripte zur Ausführung benötigt. Bei npm 11.15 oder älter, das diese Option nicht kennt, lassen Sie das Flag weg. Das Onboarding als Benutzer openclaw sorgt dafür, dass die Konfiguration des Agenten in dessen Home-Verzeichnis, /opt/openclaw, landet und nicht in dem von root. Das Projekt bietet zudem ein curl -fsSL https://openclaw.ai/install.sh | bash-Installationsskript an, das die gleiche Installation in einer Zeile durchführt. Lassen Sie das Flag --install-daemon während des Onboardings weg: Es würde den eigenen Dienst von OpenClaw registrieren, während die gehärtete systemd-Unit, die Sie weiter unten erstellen, restriktiver ist.

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.