Auf einem LeanVPS Remote-Mac in Deutschland soll das OpenClaw-Gateway idealerweise nur auf Loopback lauschen, während Operatoren und CI den Dienst über SSH LocalForward auf 127.0.0.1:18789 erreichen. Ergänzend binden Sie Gateway-Authentifizierung an ein Geheimnis aus der Umgebung (OPENCLAW_GATEWAY_TOKEN) und verankern Merge-Gates mit openclaw config validate sowie openclaw doctor --non-interactive. Der Text fokussiert minimalen Expositionsradius und wiederholbare Kommandos — keine Rechtsberatung.

Typische Fehlkonfigurationen (Angriffsfläche)

Teams mieten einen dedizierten Mac, aktivieren schnell den Gateway-Dienst und vergessen dabei, dass jede Abweichung vom Loopback-Default neue Schutzzonen erzwingt. Drei Muster tauchen wiederholt auf:

  1. LAN- oder breites Binden ohne konsistente TLS-Terminierung: Jede Schnittstelle außerhalb von 127.0.0.1 muss mit Firewall, Reverse-Proxy und klarer Auth-Story gepaart sein; sonst wächst die exponierte Oberfläche schneller als die Dokumentation.
  2. Tokens in Repos, Tickets oder Shell-Historie: Sobald gateway.auth.token im Klartext versioniert wird, verliert jedes Merge-Gate an Aussagekraft — rotieren Sie Geheimnisse aus dem Pfad der IaC heraus.
  3. CI ohne headless Doctor: Interaktive Reparaturpfade blockieren Runner; fehlende --non-interactive-Läufe erlauben, dass kaputte Supervisor-Metadaten unbemerkt in Produktion wandern.

Entscheidungsmatrix: Zugriffsmodell vs. Betriebsaufwand

Die folgende Tabelle ordnet gängige Zugriffsmuster nach Netto-Exposition und typischem Pflegeaufwand. Sie dient der Abstimmung zwischen Security und On-Call-Last — keine Aussage zu regulatorischer Konformität.

Modell Listener Expositionsgrad Operativer Aufwand
A · Loopback + SSH LocalForward 127.0.0.1:18789 nur auf dem Host Niedrig (kein öffentlicher Port) SSH-Schlüsselrotation, AllowTcpForwarding policy prüfen
B · LAN-Bind mit Firmen-TLS Privates RFC1918-Interface Mittel (Segmentierung nötig) Zertifikate, ACL, kontinuierliche Portscans
C · Öffentliches Binden 0.0.0.0 / öffentliche IP Hoch WAF, Rate-Limits, 24/7-Alerts — nur mit dediziertem Team
Compliance-Leitplanke Minimalprinzip Prüffrage vor Go-Live
Geheimnisverwaltung LaunchDaemon-EnvironmentVariables oder EnvironmentFile mit chmod 600 Liegt das Token außerhalb von Git und Backups ohne Verschlüsselung?
Observability Strukturierte Felder statt kompletter WebSocket-Payloads Welche personenbezogenen Datenfelder bleiben nach Reduktion übrig?
Änderungskontrolle Peer-Review für gateway.* und SSH-Serveroptionen Wer darf GatewayPort oder Forwarding-Regeln ohne Zweitmeinung ändern?
18789
Standard-Gateway-Port (konfigurierbar)
SSH
LocalForward statt öffentlichem Dienst
CI
doctor + config validate als Gate

Minimal reproduzierbare Schrittfolge

  1. Host bereitstellen: Instanz in der Konsole wählen, dedizierten Automatisierungsbenutzer anlegen und SSH ausschließlich mit Schlüsseln erlauben (PasswordAuthentication no).
  2. Gateway-Topologie setzen: Laut öffentlichem Gateway-Runbook gateway.mode=local, gateway.bind=loopback und gateway.auth.mode=token mit Referenz auf ${OPENCLAW_GATEWAY_TOKEN} pflegen — siehe docs.openclaw.ai/gateway für Bind-Reihenfolge, Standard-Port und Auth-Pfade.
  3. Token injizieren: Zufallswert erzeugen, in der LaunchDaemon-Plist als Umgebungsvariable hinterlegen oder in eine root-eigene Datei schreiben; optional einmalig openclaw doctor --generate-gateway-token auf einer gesicherten Admin-Sitzung ausführen, danach Klartext aus Repos entfernen.
  4. Headless Healthcheck: Nach Installation openclaw doctor --non-interactive und openclaw config validate laufen lassen — dokumentiert in docs.clawd.bot/doctor beschreibt, dass sichere Migrationen ohne TTY angewendet werden, während riskante Reparaturen übersprungen werden.
  5. SSH-Forward vom Arbeitsrechner: ssh -N -L 18789:127.0.0.1:18789 automation@<de-host> starten; lokale Tools sprechen ws://127.0.0.1:18789, während der Listener ausschließlich auf dem Remote-Loopback bleibt.
  6. Merge-Gate: In CI dieselbe OpenClaw-Version wie auf dem Host pinnen, Secrets aus dem Secret-Store injizieren und bei jedem Pull Request openclaw config validate plus openclaw doctor --non-interactive ausführen; bei Exit-Code ≠ 0 den Merge blockieren.
Hinweis zur Nachvollziehbarkeit: Dokumentieren Sie OpenClaw-Build-Hash, SSH-Konfiguration (AllowTcpForwarding, PermitOpen) und die exakte Forward-Zeile in Ihrem Runbook. So bleibt der Loopback-only-Pfad auch nach Personwechsel auditierbar.

Öffentliche Dokumentation (Gateway-Auth & Doctor)

Bind-Modi, Port-Auflösung und die Kombination aus gateway.auth.token bzw. Umgebungsvariablen wie OPENCLAW_GATEWAY_TOKEN sind im Gateway-Runbook zusammengefasst (https://docs.openclaw.ai/gateway). Für automatisierte Healthchecks verweisen wir explizit auf die Doctor-Referenz (https://docs.clawd.bot/doctor), die das Flag --non-interactive erläutert und welche Aktionen ohne menschliche Bestätigung ausgeführt werden dürfen.

Ergänzend zum Netzwerk-Fokus dieses Artikels beschreibt unser OpenClaw-Onboarding am Deutschland-Node (Daemon, Outbound-Whitelist, Audit-Minimalismus) die übergreifende Betriebsbaseline. Standort- und Paketkontext finden Sie auf der öffentlichen Seite Mac in Deutschland mieten; Supportpfade starten in der Hilfe.

SSH-Server eng an LocalForward koppeln

Weil der Forward-Tunnel dasselbe Geheimnisstransportproblem wie jede andere Fernwartung hat, sollten sshd-Defaults überprüft und dort verschärft werden, wo Ihre Policy es zulässt. Typische Ergänzungen neben generellem Schlüsselzwang sind:

  • PermitOpen auf 127.0.0.1:18789 (oder den effektiven Gateway-Port) begrenzen, damit Automation nicht beliebige Ziele durch den Tunnel adressieren kann.
  • Match User-Blöcke für den Automation-Account von administrativen Konten trennen und X11Forwarding no sowie unnötige Subsysteme deaktivieren.
  • ClientAliveInterval und sinnvolle MaxSessions setzen, damit hängengebliebene Forward-Sitzungen sichtbar werden und nicht unbegrenzt Ressourcen binden.

Diese Maßnahmen ersetzen keine zentrale Firewall vor dem Host, begrenzen aber die Schadensspanne, falls ein einzelner Schlüssel kompromittiert wird. Dokumentieren Sie Änderungen im selben Repository wie Ihre LaunchDaemon-Plists, damit CI und menschliche Reviewer denselben Diff sehen.

LeanVPS stellt Infrastruktur bereit; OpenClaw wird von Drittanbietern gepflegt. Halten Sie Konfiguration und CLI-Flags stets gegen die jeweils aktuelle Upstream-Dokumentation — Versionsdrift kann Flags oder Defaults ändern.
Frankfurt · physisch dedizierter Cloud-Mac

Deutschland-Node mieten und Gateway hart schließen

Wählen Sie Speicher- und Laufzeitoptionen passend zu parallelen Builds und lang laufenden OpenClaw-Diensten; anschließend Loopback, Token und CI-Gates wie oben ausrollen.

Jetzt Deutschland-Paket ansehen Tarife vergleichen