OpenClaw und SSH: per Tunnel ins Dashboard – und der Agent erreicht deine Server ohne Schlüssel

15. Okt. 2026 · Termalin Team mcpai-agentssshsecuritytutorial

Hinter dem Begriff „OpenClaw SSH“ verstecken sich zwei verschiedene Aufgaben, und sie zu verwechseln ist der Punkt, an dem Leute hängenbleiben. Die eine ist, OpenClaw selbst zu erreichen: Sein Dashboard läuft auf localhost, du öffnest es also über einen SSH-Tunnel. Die andere ist das Gegenteil – den OpenClaw-Agenten Befehle auf deinen eigenen Servern ausführen zu lassen. Dieser Beitrag macht beides, und für das Zweite zeigt er einen Weg, der nie einen SSH-Schlüssel dorthin legt, wo der Agent ihn lesen kann.

Eine Offenlegung vorweg: Wir bauen Termalin, die schlüssellose Option in Teil 2. OpenClaw ist ein quelloffenes Agenten-Gateway, das du selbst hostest – es läuft auf einer Kiste, liefert ein Web-Dashboard aus und installiert „Skills“ aus seinem Marktplatz ClawHub. Wir beschreiben die anderen Ansätze so fair, wie wir es für unseren wünschen würden.

Zwei Dinge, die Leute mit „OpenClaw SSH“ meinen

OpenClaw über SSH erreichen. Das Dashboard ist an localhost gebunden, du leitest seinen Port also auf deine Maschine weiter. Das ist Teil 1.
OpenClaw deine Server erreichen lassen. Du willst, dass der Agent Befehle auf anderen Kisten ausführt. Das ist Teil 2, und das ist der Teil, den man sorgfältig angehen sollte.

Teil 1 – das OpenClaw-Dashboard über einen SSH-Tunnel öffnen

Das OpenClaw-Gateway bindet sich mit Absicht an 127.0.0.1:18789 auf dem Host, auf dem es läuft. Das Dashboard ist eine administrative Steuerebene, keine öffentliche Website. Leite diesen Port von deinem Laptop über deinen bestehenden SSH-Login weiter:

ssh -N -o ServerAliveInterval=30 -L 18789:127.0.0.1:18789 user@vps

Öffne dann http://127.0.0.1:18789 in deinem Browser. -N bedeutet „keine Shell, nur der Tunnel“; ServerAliveInterval=30 hält die Verbindung davon ab, untätig zu werden. Der Verkehr nutzt die SSH-Sitzung, der du bereits vertraust, also wird nichts Neues dem Internet ausgesetzt.

Binde das Gateway nicht an 0.0.0.0, um dir den Tunnel zu sparen. Das stellt die Steuerebene deines Agenten ins öffentliche Internet, und wer den Port findet, hat den Agenten. OpenClaws eigene Docs sagen dasselbe: Nutze einen SSH-Tunnel, lege den Gateway-Port nicht offen. Lass es auf 127.0.0.1 und erreiche es über SSH.

Wenn der Tunnel nicht verbindet

„Connection refused“, „check failed“ oder eine leere Seite bedeuten meist eines davon:

Das Gateway läuft nicht oder ist auf einem anderen Port. Prüf auf der Kiste mit ss -tlnp | grep 18789.
Dein lokaler Port 18789 ist schon belegt. Wähl einen anderen lokalen Port: -L 28789:127.0.0.1:18789, dann öffne http://127.0.0.1:28789.
Du hast eine Shell statt eines Tunnels bekommen. Du hast -N weggelassen.

Mehr Fälle in SSH-Verbindung abgelehnt oder Timeout.

Den Dashboard-Tunnel am Leben halten

Ein einfacher ssh -L-Tunnel stoppt, wenn dein Netz abbricht. Für einen dauerhaft offenen Tunnel nutz autossh oder einen kleinen systemd-Dienst oder einen Tunnel-Manager, der für dich neu verbindet. Die Mechanik lokaler und entfernter Weiterleitungen behandelt SSH-Portweiterleitung und Tunnel (auf Englisch).

Teil 2 – OpenClaw Befehle auf deinen anderen Servern ausführen lassen

Das ist der Teil, den die meisten wollen: OpenClaw sieht, dass ein Dienst ausgefallen ist, und behebt es auf der echten Kiste. Der übliche Weg ist, dem Agenten einen SSH-Schlüssel zu geben – einen Schlüssel in ~/.ssh auf dem Gateway-Host oder einen SSH-Skill aus ClawHub. Es funktioniert. Es ist auch die Konstellation mit dem größten Risiko, also lohnt es sich, sie zu verstehen, bevor du danach greifst.

Der riskante Teil: ein Schlüssel auf dem Gateway

Ein Skill-Marktplatz ist Code, den du nicht geschrieben hast und der neben deinem Schlüssel läuft. Anfang 2026 prüfte Koi Securitys „ClawHavoc“-Untersuchung 2.857 ClawHub-Skills und stufte 341 als bösartig ein. Mehrere waren darauf ausgelegt, SSH-Schlüssel und Zugangsdaten zu stehlen; die meisten installierten den AMOS-Stealer über gefälschte „Voraussetzungen“, und einige griffen die eigene .env-Datei des Agenten ab.

Nimm den Fehlermodus dazu, den jeder Agent hat – Prompt-Injection aus einer Webseite oder E-Mail, die er liest –, und die Konsequenz ist klar. Ein SSH-Schlüssel auf dem Gateway ist eine volle Shell auf jedem Host, der ihm vertraut, erreichbar für alles, was den Agenten steuern kann. Ihn zu widerrufen bedeutet, diesen Schlüssel auf all diesen Hosts zu rotieren.

Das Ziel für Teil 2 ist also, OpenClaw die gewünschten Befehle ausführen zu lassen – ohne einen Schlüssel, den er – oder ein bösartiger Skill – abgreifen kann.

Der schlüssellose Weg: ein Connector, dann Termalin als entfernter MCP-Server

Zwei Teile.

Erstens: Installier einen Termalin-Connector auf jedem Server, den OpenClaw erreichen soll. Es ist eine Ein-Zeilen-Installation und nur ausgehend: Er lauscht nie auf einem Port, funktioniert also hinter NAT oder CGNAT und braucht nichts in deiner Firewall geöffnet. Beim Anbinden wird das sshd des Servers so gesetzt, dass es Termalins SSH-Zertifizierungsstelle vertraut, und jeder Login nutzt danach ein kurzlebiges Zertifikat, das für dein Konto ausgestellt wird. Kein langlebiger Schlüssel liegt auf der Kiste, und keiner wird je an den Agenten gegeben.

Zweitens: Füg Termalin in OpenClaw als entfernten MCP-Server hinzu. MCP (auf Englisch) ist die Art, wie OpenClaw mit Tools spricht, die es nicht selbst mitbringt. Termalins gehosteter Endpoint stellt deine über einen Connector angebundenen Server als Tools bereit: hosts_list, ssh_exec, ssh_exec_many, SFTP-Lese- und -Schreibzugriffe, server_metrics, alerts_list und mehr.

OpenClaw liest eine JSON5-Konfiguration aus ~/.openclaw/openclaw.json und lädt sie automatisch neu. Zuerst eine Stolperfalle: Lässt du transport weg, nutzt das aktuelle OpenClaw (2026.10.x) standardmäßig SSE. Termalin spricht Streamable HTTP, du musst also "transport": "streamable-http" setzen, sonst scheitert die Verbindung.

Es gibt zwei Wege zur Authentifizierung.

API-Schlüssel – gut für ein Gateway, das auf einem VPS läuft. Erstell einen Schlüssel im Termalin-Web-Kabinett, grenz ihn auf die Server ein, die dieser Agent anfassen soll, und leg den Wert als TERMALIN_API_KEY in die Umgebung. Füg den Server dann mit einem Befehl hinzu:

openclaw mcp set termalin '{"url":"https://termal.in/api/v1/mcp","transport":"streamable-http","headers":{"Authorization":"Bearer ${TERMALIN_API_KEY}"}}'

Oder schreib dasselbe in ~/.openclaw/openclaw.json:

{
  "mcp": {
    "servers": {
      "termalin": {
        "url": "https://termal.in/api/v1/mcp",
        "transport": "streamable-http",
        "headers": {
          "Authorization": "Bearer ${TERMALIN_API_KEY}"
        }
      }
    }
  }
}

Nutz die ${TERMALIN_API_KEY}-Referenz, nicht den literalen Schlüssel. openclaw mcp doctor warnt, wenn es ein Token direkt in headers geschrieben findet, und Header-Werte werden in seinen Logs geschwärzt.

OAuth – gut, wenn sich eine Person anmeldet. Richte den Server auf https://termal.in/mcp, setz auth auf oauth und melde dich dann an:

openclaw mcp set termalin '{"url":"https://termal.in/mcp","transport":"streamable-http","auth":"oauth"}'
openclaw mcp login termalin
openclaw mcp doctor termalin --probe

openclaw mcp login gibt eine Autorisierungs-URL aus und wartet auf einen Loopback-Callback (http://127.0.0.1:<port>/callback). Termalins OAuth akzeptiert diese Loopback-Redirect-URIs, du bestätigst die Anmeldung also in deinem Browser und das Token wird gespeichert – es gibt keinen Schlüssel zum Einfügen. Läuft OpenClaw auf einem Headless-VPS und dein Browser auf einem Laptop, schließ es von Hand mit openclaw mcp login termalin --code <code> ab. Beachte: Ist auth: "oauth" gesetzt, ignoriert OpenClaw jeden statischen Authorization-Header für diesen Server – wähl also eine Methode.

So oder so bestätigt openclaw mcp doctor termalin --probe, dass der Server erreichbar ist, und listet seine Tools auf, und die Termalin-Tools erscheinen dann für den Agenten. (Du kannst einen Server auch aus der Control UI hinzufügen: chat → + → Connectors → Add MCP server…, nur für Admins.)

Entscheide zuerst, was es darf, und protokolliere alles

Ein dauerhaft laufender Agent sollte klein anfangen. Gib dieser Verbindung in der KI-Apps-Karte von Termalin eine Befehlsrichtlinie: nur lesend, eine Liste exakt erlaubter Befehle oder voller Zugriff. Fang mit nur lesend an – „Wie geht es meinen Servern“, Plattenplatz, fehlgeschlagene Dienste, die letzten Zeilen eines Logs, über server_metrics und alerts_list. Weite es dann auf eine enge Liste erlaubter Befehle aus, dann auf Schreibzugriffe, Schritt für Schritt. Die Begründung für enge Listen erlaubter Befehle pro Host (auf Englisch) gilt hier direkt.

Alles, was der Agent ausführt, ist aktenkundig. Jeder Befehl landet in der Sitzungsaufzeichnung, im Live-Watch-Grid und im Audit-Log (auf Englisch), markiert als der des Agenten. Weil das Geheimnis eine Termalin-Zugangsberechtigung ist und kein über Hosts verstreuter SSH-Schlüssel, ist das Abschalten des Agenten ein Schalter, keine Schlüsselrotation. Teilen sich mehrere Leute ein OpenClaw, kann OpenClaw jedem Absender eine eigene Identität geben (oauth.identity: "per-requester"), damit die Audit-Spur pro Person bleibt.

Wenn der MCP-Server nicht verbindet

Er verbindet, zeigt aber keine Tools oder scheitert am Handshake. Du hast transport weggelassen und OpenClaw ist auf SSE zurückgefallen. Setz "transport": "streamable-http".
401 Unauthorized. Der API-Schlüssel fehlt oder liegt außerhalb seines Umfangs, oder du bist auf der OAuth-URL (/mcp), ohne openclaw mcp login ausgeführt zu haben. Der Schlüssel-Endpoint ist /api/v1/mcp, der OAuth-Endpoint ist /mcp.
${TERMALIN_API_KEY} kommt leer an. Die Variable ist nicht in der Umgebung gesetzt, in der OpenClaw läuft. Exportier sie dort, wo das Gateway startet.
Ein erwarteter Server fehlt in hosts_list. Er hat noch keinen Connector oder liegt außerhalb des Umfangs des Schlüssels.

Führ openclaw mcp status --verbose und openclaw mcp doctor termalin --probe aus, um zu sehen, welche Stufe scheitert.

Faire Alternativen

Der schlüssellose Weg ist nicht der einzige. Zwei andere sind je nach Bedarf vernünftig.

Gib dem Agenten direkt einen Schlüssel. Leg einen SSH-Schlüssel in ~/.ssh auf dem Gateway-Host, oder installier einen ClawHub-SSH-Skill (ssh-executor, ssh-full, sshx und andere), der einen Schlüssel, ein Passwort oder einen Tresor-Eintrag liest. Das ist am schnellsten eingerichtet und hängt von nichts Gehostetem ab. Der Haken ist genau das oben beschriebene Risiko: Der Schlüssel ist für alles lesbar, was der Agent ausführt, seine Reichweite ist jeder Host, der ihm vertraut, und ihn zu widerrufen bedeutet, auf allen Schlüssel zu rotieren. Wenn du das machst, nutz einen eigenen Schlüssel mit geringen Rechten, beschränk ihn hart mit command= in authorized_keys und verwende nie deinen persönlichen Schlüssel wieder.

Betreib einen eigenständigen SSH-MCP-Server, der den Schlüssel hält. Ein kleiner selbst gehosteter MCP-Server mit einem ssh_exec-Tool hält den Schlüssel in seiner eigenen Konfiguration, außerhalb des Kontexts des Modells. Das ist eine echte Verbesserung – ein geleaktes Transkript enthält die Zugangsdaten nicht mehr. Aber die meisten davon kommen ohne Befehlsrichtlinie, ohne Live-Ansicht und ohne Audit-Spur, sodass jeder Tool-Aufruf alles auf jedem konfigurierten Host ausführen kann, und dein Protokoll des Geschehenen ist, was auch immer der Agent meldet. Wir haben diese und jede andere Konstellation danach eingeordnet, was ein Kompromittieren kostet, in einem KI-Agenten SSH-Zugriff geben, nach Blast Radius (auf Englisch).

Häufige Fragen

Unterstützt OpenClaw MCP? Ja. Das aktuelle OpenClaw (2026.10.x) verbindet sich über HTTP mit entfernten MCP-Servern. Füg einen mit openclaw mcp set oder openclaw mcp add hinzu, oder aus der Control UI (chat → + → Connectors → Add MCP server…, nur für Admins). Setz "transport": "streamable-http" für Server wie Termalin, weil der Standard sonst SSE ist.

Kann OpenClaw per SSH auf meinen Server? Ja, auf zwei Arten. Direkt, wenn du ihm einen Schlüssel über das Exec-Tool oder einen ClawHub-SSH-Skill gibst. Oder schlüssellos, indem du es mit einem MCP-Server verbindest, der den Zugriff für es hält – das Connector-plus-MCP-Setup von oben, bei dem nie ein Schlüssel den Agenten erreicht.

Ist es sicher, OpenClaw meinen SSH-Schlüssel zu geben? Behandle es als hochriskant. Ein Schlüssel auf dem Gateway ist für jeden Skill und jede eingeschleuste Anweisung lesbar, der der Agent folgt, und ClawHub hat Skills ausgeliefert, die genau das stehlen sollen (Koi Security stufte Anfang 2026 341 Skills als bösartig ein). Wenn es sein muss, nutz einen Wegwerf-Schlüssel mit geringen Rechten und command=-Beschränkungen – nie deinen persönlichen Schlüssel.

Wie behebe ich „openclaw ssh connection refused“? Für den Dashboard-Tunnel prüf, dass das Gateway läuft und an 127.0.0.1:18789 gebunden ist (ss -tlnp | grep 18789 auf der Kiste), stell sicher, dass dein lokaler Port frei ist, und behalt -N am ssh -L-Befehl. Mehr Fälle in SSH-Verbindung abgelehnt oder Timeout.

Muss ich irgendwelche Ports öffnen? Nein. Der Dashboard-Tunnel nutzt deine bestehende SSH-Verbindung, und ein Termalin-Connector ist nur ausgehend – er lauscht nie auf einem Port, funktioniert also hinter NAT und CGNAT, ohne dass in deiner Firewall etwas geöffnet wird.

Termalin ist ein plattformübergreifender SSH-Client mit gehostetem MCP-Server, einem Schlüsselverwahrer und einer Agenten-Richtlinie pro Host. Der gehostete Endpoint und der Connector-basierte Zugriff sind auf Pro (10 $/Monat oder 8 $/Monat bei jährlicher Abrechnung) und Team verfügbar, mit einer 14-tägigen Pro-Testphase und ohne Kreditkarte – siehe MCP, den Connector oder SSH für KI-Agenten.