Einem lokalen LLM sicheren SSH-Zugriff auf deine Server geben

7. Aug. 2026 · Termalin Team sshai-agentslocal-llmsecurity

Der sichere Weg, einem lokalen Modell SSH-Zugriff zu geben, ist, ihm nie einen Schlüssel zu geben. Lass es ein Tool aufrufen – einen MCP-Server, der als Verwahrer auftritt –, der die Schlüssel hält (oder kurzlebige Zertifikate ausstellt), nur die von dir gelisteten Hosts erreicht, eine Liste erlaubter Befehle pro Host durchsetzt und jeden einzelnen protokolliert. Dann kann ein gekaperter Prompt eine Aktion nur über den Verwahrer anfragen; er kann nicht deine Identität übernehmen oder einen Host erreichen, den du nicht gelistet hast. Was die meisten zuerst falsch machen: Das Modell auf deiner eigenen Hardware zu betreiben schützt deine Prompts, nicht deine Server – „es ist lokal, also ist es sicher“ stimmt nicht und ändert nichts daran, was passiert, wenn dieses Modell eine Shell bekommt.

Lokale Modelle haben gerade ihren Moment. Ollama auf einer Workstation, ein Modell mit offenen Gewichten hinter deinem eigenen Endpoint, ein selbst gehosteter Coding-Agent – du betreibst sie aus guten Gründen: Privatsphäre, Kosten, keine Rate-Limits, läuft im Flugzeug. Und sobald ein Modell schon deine Prompts verarbeitet, ist der nächste naheliegende Schritt, es auf deine Infrastruktur zu richten: ein Log verfolgen, einen Dienst neu starten, die Migration ausführen – und genau da landet die eigentliche Frage.

Warum „lokal“ den Server-Zugriff nicht sicher macht

Zwei Dinge bleiben genauso gefährlich, ob das Modell in einem Rechenzentrum läuft oder auf der Kiste unter deinem Schreibtisch.

Der Schlüssel ist weiterhin eine Inhaber-Zugangsberechtigung. Leg id_ed25519 in die Umgebung des Agenten, damit er ssh selbst ausführen kann, und wer – oder was – diese Bytes hält, ist du, auf jedem Host, der dem Schlüssel vertraut. Das Modell lokal zu betreiben ändert daran nichts; es verschiebt die Kopie nur auf eine Maschine, die dir zufällig gehört. Und du kannst es trotzdem nicht zurücknehmen: Sobald der Schlüssel durch den Kontext des Modells gelaufen ist – eine Umgebungsvariable, eine eingehängte Datei, ein Tool-Aufruf, ein Transkript –, kannst du nicht mehr beweisen, dass er nicht irgendwo gelandet ist, wo er nicht hingehört. Die einzige ehrliche Antwort auf „Hat das Modell meinen Schlüssel gesehen?“ ist, ihn auf jedem Host zu rotieren.

Ein lokales Modell wird genauso verwirrt. Prompt-Injection braucht kein Cloud-Modell. Eine vergiftete Log-Zeile, ein bösartiger Dateiname, ein mit einer Falle versehenes Tool-Ergebnis, ein übereifriger Plan – ein lokales Modell handelt danach genauso bereitwillig wie ein gehostetes. Wenn überhaupt, ist das Risiko größer, weil Leute lokalen Setups mehr vertrauen, sie mit weniger Leitplanken verdrahten und ihnen breiteren Zugriff geben, gerade weil „es ja auf meiner Maschine ist“. Das ist der falsche Instinkt: Das Urteilsvermögen des Modells ist nicht besser, weil die Gewichte lokal liegen.

Das Ziel ist also dasselbe wie bei jedem Agenten – das Modell die Arbeit tun zu lassen, ohne je die Zugangsberechtigung zu halten, und jede Aktion eingegrenzt, sichtbar und umkehrbar zu machen.

Drei Wege, es schlecht zu machen

Den rohen Schlüssel einfügen. Der direkte Weg, und der schlechteste: kein Umfang, kein Ablaufdatum und die Unumkehrbarkeit von oben. Der Schlüssel, der nach Staging deployt, erreicht meist auch die Produktionsdatenbank zwei Sprünge weiter.

Ein langlebiges Token ausstellen. Ein Deploy-Token oder eine „Automatisierungs“-Zugangsberechtigung, die nie abläuft. Es wirkt ordentlicher als ein Schlüssel, ist aber dasselbe Inhaber-Problem mit ein paar Schritten mehr. Wenn das Widerrufen bedeutet, sich daran zu erinnern, dass es existiert, wird es das Experiment überleben, das es geschaffen hat.

Gib ihm sein eigenes Root-Login und geh weg. Der richtige Instinkt – eine eigene Identität – falsch umgesetzt. Leg einen öffentlichen Schlüssel in authorized_keys für einen Bot-Nutzer, und du hast Zugriff ohne Audit-Spur gebaut: Nichts unterscheidet die Befehle des Modells von denen anderer, und wenn um 2 Uhr nachts etwas kaputtgeht, rekonstruierst du seine Sitzung aus der Bash-History und einem Bauchgefühl.

Der rote Faden: Das Modell hält eine dauerhafte Zugangsberechtigung, und die Beobachtbarkeit ist ein nachträglicher Einfall.

Das Muster, das funktioniert: ein Verwahrer, keine Kopie

Dreh es um. Das Modell sollte die Zugangsberechtigung überhaupt nie halten.

Das Modell fragt an; ein Verwahrer signiert. Ein Vermittler hält die Schlüssel (oder stellt kurzlebige Zertifikate aus) und authentifiziert für das Modell. Kompromittier den Kontext des Modells, und du bekommst die Fähigkeit, Aktionen über den Vermittler anzufragen – nicht die Fähigkeit, dich von überall als du auszugeben.
Der Umfang ist ausdrücklich. Das Modell erreicht nur die von dir gelisteten Hosts. Ein neuer Host ist eine neue Entscheidung, kein Standard.
Befehle werden kontrolliert. Entscheide pro Host, ob das Modell eine volle Shell, eine Liste erlaubter Befehle oder nichts bekommt – sodass „nginx neu starten“ auf der Web-Schicht erlaubt ist und „irgendetwas“ nie.
Ein Mensch kann zusehen – live. Nicht erst im Nachhinein, und die Aufzeichnung unterscheidet „das hat das Modell gemacht“ von „das habe ich gemacht“.
Widerruf ist ein Schalter, keine Rotation. Weil nie etwas geteilt wurde, kostet das Abschalten des Zugriffs nichts.

Nichts davon ist exotisch – so funktioniert zertifikatsbasiertes SSH bei ernsthaften Infra-Teams ungefähr schon heute. Der Haken war immer, dass es selbst zu verdrahten ein Projekt ist, also springen Leute zu einer der schlechten Optionen von oben.

Die Verdrahtung mit einem lokalen Modell

MCP – das Model Context Protocol – ist der saubere Weg dafür, und es ist client-unabhängig: Jeder MCP-fähige Client kann es steuern, es spielt also keine Rolle, ob dein Modell Claude ist, ein Modell mit offenen Gewichten hinter Ollama oder etwas, das du selbst hostest.

Betreib dein lokales Modell über einen MCP-fähigen Client (einen Coding-Agenten oder Chat-Client, der MCP spricht).
Richte ihn auf einen MCP-Server, der SSH vorlagert – einen, der für das Modell authentifiziert, statt ihm einen Schlüssel zu geben.
Schalte nur die Hosts ein, die du willst, und setz die Befehlsrichtlinie jedes Hosts (voller Zugriff / Liste erlaubter Befehle / gesperrt).
Behalt die Sitzung im Blick und lass sie in ein Audit-Log schreiben, sodass jeder Befehl, den das Modell ausführt, zuordenbar und abspielbar ist.

Das Modell bekommt Tools – eine Sitzung öffnen, einen Befehl ausführen, eine Datei lesen oder schreiben – und der Verwahrer übernimmt die Authentifizierung. Dein Schlüssel gelangt nie in die Umgebung des Modells, weder auf deiner Maschine noch sonstwo. Und weil der Verwahrer die Zugangsberechtigung hält statt des Modells, trägt dieselbe Verdrahtung in dem Moment weiter, in dem du stattdessen zu einem gehosteten Agenten greifst – Claude Code über SSH und OpenAI Codex über SSH stellen genau dieses Muster mit einem Cloud-Modell am anderen Ende bereit.

Wie Termalin es macht

Termalin ist ein SSH-Client mit integriertem MCP-Server, sodass dieses Muster der Standard ist statt eines Projekts.

Auf deiner Maschine registrierst du den mitgelieferten lokalen Server bei deinem Agenten (claude mcp add termalin -- <path>/termalin-mcp oder das Äquivalent für einen beliebigen MCP-Client). Das Modell erreicht nur die Hosts, die du freischaltest – der Agentenzugriff ist standardmäßig aus –, und die Authentifizierung läuft über Termalins Schlüsselverwahrer: Du entsperrst deine Schlüssel einmal, Termalin signiert für das Modell, und es gibt nie eine Schlüsseldatei, die das Modell lesen könnte.
Pro Host setzt du die Richtlinie – voller Zugriff, eine Liste erlaubter Befehle oder gesperrt –, sodass ein lokales Modell, das verwirrt wird, nichts ausführen kann, was du auf dieser Kiste nie erlaubt hast.
Du siehst dabei zu. Agenten-Sitzungen laufen als Live-Terminal-Tabs; das Watch Grid spiegelt sie, und die Kacheln, die ein Modell steuert, leuchten. Jeder Befehl wird in der Sitzungsaufzeichnung markiert – nur die Ausgabe, nie deine Tastenanschläge – und in ein Audit-Log geschrieben, mit dem Gerät und der IP, von der er kam.
Keine App läuft? Richte das Modell auf Termalins gehosteten MCP-Endpoint mit einem API-Schlüssel, der auf bestimmte Server begrenzt ist, ein Ablaufdatum trägt, einer Befehlsrichtlinie unterliegt und jeden Lauf mit einem kurzlebigen Zertifikat authentifiziert – sodass selbst ein geleakter Schlüssel keinen ungelisteten Host erreichen oder außerhalb seiner erlaubten Befehle laufen kann.

So oder so gilt die Eigenschaft, die du wolltest: Dein lokales Modell kann deine Server bedienen, und es hat nie einen Schlüssel gesehen.

Fang mit einem langweiligen Host an

Fang nicht mit Produktion an. Bind eine Kiste mit geringem Einsatz an – einen Staging-Server, einen Spielzeug-VPS –, setz sie auf eine Liste erlaubter Befehle und gib dem Modell eine echte Aufgabe: das Log verfolgen, bis der Fehler auftaucht, die Konfiguration reparieren, den Dienst neu starten. Halt das Grid offen, während es arbeitet. Was du in der ersten Stunde lernst – wie es sich verhält, wo es zögert, was es mit Mehrdeutigkeit macht –, sagt dir, ob der zweite Host angebunden wird und mit wie viel Leine.

Das ist der stille Gewinn des Verwahrmodells: Du erweiterst einen Host nach dem anderen, weil kein Schritt, den du machst, einer ist, den du nicht zurücknehmen kannst – egal, wo das Modell läuft.

Termalin ist ein kostenloser, plattformübergreifender SSH-Client mit integriertem MCP-Server, einem Schlüsselverwahrer und einer Agenten-Richtlinie pro Host – lade ihn herunter oder lies, wie er Schlüssel sicher handhabt.