OpenClaw SSH
Port-Forwarding-Diagnose in der Praxis

Ziel: Loopback-only Control Plane, minimale Angriffsfläche

Das OpenClaw-Gateway multiplext standardmäßig WebSocket und HTTP auf Port 18789. Die Konfigurationsreferenz besagt, dass gateway.bind: "loopback" den Listener auf die lokale Loopback-Adresse beschränkt, während Nicht-Loopback-Bindung Gateway-Authentifizierung erfordert (Token, Passwort oder streng konfigurierter Trusted-Proxy). Für geteilte Remote-Macs ist die beste Lösung: Loopback-Bindung + Token-Modus, wobei Betreiber und Automatisierung über einen verschlüsselten Tunnel auf den Port zugreifen, anstatt 18789 auf der öffentlichen Schnittstelle des Hosts zu exponieren.

Lesen Sie diesen Artikel in Verbindung mit: OpenClaw auf nozcloud Deutschland: Daemon-Onboarding und Compliance-Baseline. Für Kauf oder Konfigurationsanpassungen besuchen Sie die Kaufseite und vergleichen Sie Pakete auf der Preisseite.

Minimale reproduzierbare Schritte (Remote-Mac)

Empfehlung: Führen Sie den folgenden Ablauf zunächst auf einem Testgerät durch. Nach erfolgreicher Verifikation können dieselbe plist, SSH-Konfiguration und CI-Jobs in die Produktionsumgebung übertragen werden.

1. SSH-Grundkonfiguration. Erstellen Sie einen dedizierten macOS-Benutzer für OpenClaw. Installieren Sie nur die geprüfte OpenClaw-Version und verifizieren Sie nicht-interaktives SSH mit Schlüssel (deaktivieren Sie Passwortauthentifizierung für dieses Konto in sshd_config, wenn die Richtlinie dies erlaubt).
2. Bindung und Authentifizierung in JSON5 deklarieren. Behalten Sie in ~/.openclaw/openclaw.json gateway.mode: "local" bei, setzen Sie gateway.bind: "loopback" und konfigurieren Sie gateway.auth.mode: "token" sowie gateway.auth.token: "${OPENCLAW_GATEWAY_TOKEN}". Wenn Token- und Passwort-Objekte gleichzeitig vorhanden sind, geben Sie gateway.auth.mode explizit an, um Mehrdeutigkeiten beim Start zu vermeiden.
3. Token injizieren, keinen Schlüsselpfad in Git committen. Exportieren Sie OPENCLAW_GATEWAY_TOKEN über das EnvironmentVariables-Dictionary des LaunchDaemon oder eine root-eigene Umgebungsdatei mit strengen POSIX-Berechtigungen. Beim ersten Start kann openclaw doctor --generate-gateway-token in einer sicheren Admin-Shell ausgeführt werden.
4. Nicht-interaktive Gesundheitsprüfung. Führen Sie nacheinander openclaw config validate und openclaw doctor --non-interactive aus. --non-interactive überspringt interaktive Eingabeaufforderungen, wendet sichere Migrationen an und vermeidet interaktive OAuth-Aktualisierungen – ideal für Cron und CI.
5. Gateway-Dienst installieren oder neu starten. Verwenden Sie den standardisierten Anbieterprozess (z.B. openclaw gateway install mit Ihren fixierten Parametern). Bestätigen Sie, dass openclaw gateway status zeigt, dass der Listener nur auf der Loopback-Adresse aktiv ist.
6. SSH LocalForward von der lokalen Workstation einrichten. Führen Sie ssh -N -L 18789:127.0.0.1:18789 openclaw-svc@germany-host.example aus (Benutzername und Hostname entsprechend ersetzen). Lokale Tools können dann auf ws://127.0.0.1:18789 zugreifen, während der Datenverkehr über SSH verschlüsselt wird.
7. Token-Pfad verifizieren. Verbinden Sie sich nach dem Aufbau des Tunnels von Ihrem Laptop aus per Bearer-Token zu 127.0.0.1:18789 gemäß Betriebshandbuch. Senden Sie absichtlich einen falschen Token: Sie sollten einen Authentifizierungsfehler und kein stilles Durchleiten sehen – Beweis für durchgängige Durchsetzung.

Compliance-orientierte Angriffsflächen-Checkliste

Die folgenden Punkte sind keine Rechtsberatung; sie übersetzen das "Least-Privilege"-Prinzip in konkrete Gate-Punkte, die Sicherheitsprüfer verifizieren können.

• Keine Klartexttoken in der Shell-Historie: Schlüssel über LaunchDaemon oder CI-Secret-Injector laden, niemals inline in einer geteilten Bildschirmsitzung mit export.
• Betriebs-SSH-Konto vom Dienstkonto trennen: Menschliche Benutzer verwenden eigene UNIX-Principals; der OpenClaw-Daemon-Benutzer sollte keine persönlichen Dotfiles besitzen.
• Gateway-Konfigurationsänderungen im PR überprüfen: Jede Änderung an gateway.bind, gateway.auth, hooks oder gateway.http-Endpunkten erfordert eine Vier-Augen-Prüfung.
• Konfiguration vor Doctor-Reparaturen sichern: Vor Upgrades eine zeitgestempelte Kopie von openclaw.json aufbewahren; bei Verlust von Authentifizierungsmetadaten durch Migration aus dem Artefakt-Speicher wiederherstellen und Dienst neu starten.
• Notfalloperationsverfahren dokumentieren: Wenn jemand während einer Vorfallsreaktion den Bindungsmodus vorübergehend lockert, sofort ein Ticket einreichen und innerhalb des SLA-Fensters zurücksetzen.

Merge-Gate-Lösung (GitHub Actions Pseudocode-Beispiel)

Speichern Sie schreibgeschützte Fixups oder anonymisierte Auszüge der Produktionskonfiguration in Git – niemals Produktionstoken committen. Injizieren Sie über CI-Secrets einen einmaligen OPENCLAW_GATEWAY_TOKEN, damit Validierungspfade mit Umgebungsvariablenersetzung korrekt ausgeführt werden können. Der Job sollte folgende Schritte umfassen:

1. Dieselbe OpenClaw-Minor-Version wie in der Produktion installieren.
2. openclaw config validate auf das zusammengeführte Ergebnis aus eingecheckter Vorlage und Testschlüssel anwenden.
3. openclaw doctor --non-interactive ausführen; Fehler, wenn Warnungen den Richtlinien-Schwellenwert überschreiten (viele Teams behandeln jede Zeile "auth missing" als harten Fehler).
4. Optional: openclaw doctor --deep nachts statt bei jedem PR ausführen – Deep-Scans dauern länger und erfordern möglicherweise erhöhte Berechtigungen.

Upgrade-Probleme gemäß internem Betriebshandbuch lösen; bei Blockierungen bei der Ressourcenbereitstellung oder dem SSH-Zugriff über den untenstehenden Hilfe-Center-Link ein Ticket einreichen.