Befreien Sie Ihre Agents und geben Sie ihnen SSH-Zugriff

Jede moderne Plattform bietet deinem Agenten dieselben drei Integrationsmöglichkeiten: einen MCP-Server zum Registrieren, einen API-Key zum Speichern und Aktualisieren oder eine Skill-Datei zum Installieren, die dem Agenten beibringt, wie die ersten beiden funktionieren. Etwas zum Konfigurieren. Etwas, das durchsickern kann. Etwas, das veraltet.

Oberik gibt deinem Agenten stattdessen SSH-Zugriff.

Nicht dir – du agierst in diesem Kontext als Proxy –, sondern tatsächlich SSH-Zugriff für deinen Agenten.

1 ssh ssh.oberik.com

SSH ist die Oberfläche, die ein Coding-Agent nutzt, wenn er mit Oberik interagieren muss (z. B. einen Workspace einrichten, sein Capability-Limit setzen, Tokens generieren, mit dem von uns gehosteten Agenten chatten usw.). Keine Konfigurationsdatei, kein Token in einer Umgebungsvariable, nichts installiert. Dein Rechner hat den Client bereits, und er weiß bereits, wie er die eine erforderliche Anmeldeinformation verwaltet.

Warum nicht MCP?

Kurz gesagt: das Ausgabeproblem.

MCP ist zum Industriestandard geworden, weil es ein echtes Problem gelöst hat. Du schreibst ein Tool einmal, und jeder Agent kann es auf die gleiche Weise aufrufen. Wir sind nicht dagegen. Oberik lädt deine eigenen MCP-Server direkt in den von uns gehosteten Agenten, pro Mandant, und das ist ein guter Weg für einen Agenten, um auf Tools zuzugreifen. Wir sprechen hier über eine andere Richtung: wie etwas das Konto konfiguriert.

So einfach es auch zu verwenden ist, MCP hat einen grundlegenden Fehler: Wenn ein Tool ausgeführt wird, wird die gesamte Ausgabe in den Kontext des Modells geschoben. Das Modell muss alles lesen. Es kann nicht entscheiden: „Ich wollte nur das dritte Feld“, denn sobald der Text ankommt, ist das Filtern bereits fehlgeschlagen.

MCP unterstützt Filterung und Paginierung im Prinzip. In der Praxis muss das jemand in jedes Tool einbauen, und wenn es fehlt – was dank Vibe Coding häufig vorkommen kann –, schluckt das Modell einfach die rohe Nutzlast und bezahlt dafür in Tokens und Aufmerksamkeit.

Mit SSH stellt der Agent seine eigene Ansicht zusammen, anstatt die zu akzeptieren, die ihm ein Tool aushändigt.

1$ ssh ssh.oberik.com 'documents --json' | jq -r '.data[].name'
2$ ssh ssh.oberik.com 'audit --limit 20 --json' | jq -r '.data[] | "\(.at) \(.command)"'

Der Filter läuft in einer Pipe auf dem Rechner. Sofort, kostenlos, genau so schmal, wie der Agent es wollte. Das Modell liest eine Zeile statt zehn Seiten.

Zwei Dinge machen das möglich. Erstens verwendet jede Antwort ein einzeiliges Format wie {"ok":…, "command":…, "message":…, "data":…}. Das macht jq zur beabsichtigten Methode, die Ausgabe zu lesen, nicht zu einem Workaround.

Der JSON-Modus verhindert auch, dass die Interaktion deinen Stream unterbricht. Wenn einem Befehl ein erforderliches Feld fehlt, teilt er dir mit, was fehlt, anstatt ein Formular zu öffnen. Wenn ein Befehl destruktiv sein könnte, fordert er dich auf, ihn mit --yes erneut auszuführen, anstatt anzuhalten und um Bestätigung zu bitten.

Für eine Zeile mit mehreren Befehlen setze format json; an den Anfang. Das setzt das Format einmal, sodass du das Flag nicht wiederholen musst.

Ein Detail ist wissenswert. Das Flag muss innerhalb der Anführungszeichen stehen. ssh [ssh.oberik.com](https://ssh.oberik.com/) --json 'documents' funktioniert nicht, weil ssh Optionen nach dem Ziel als eigene behandelt. Es ignoriert das Flag, und der Client antwortet mit seiner eigenen Nutzungsausgabe. Da diese Ausgabe weder Oberik noch das Flag erwähnt, kann der Host dadurch defekt erscheinen.

Was wir damit sagen wollen: Wir haben diese Modelle darauf trainiert, den Computer zu benutzen – lass sie den Computer benutzen.

Warum nicht eine API?

Kurz gesagt: das Anmeldedatenproblem.

Versteh uns nicht falsch, wir haben eine API in Oberik, und sie ist gut. Sie ist das, was dein Produkt in der Produktion aufruft, und sie ist das, was das SSH-Gateway selbst unter der Haube verwendet.

Aber wenn du dir ansiehst, was sie vom Aufrufer verlangt:

1. ein Token holen
2. es speichern
3. es aktualisieren
4. es aus Logs und aus dem Kontext des Modells heraushalten.

Jeder dieser Schritte wird zur Verantwortung des Agenten, und der Kontext eines Agenten ist kein sicherer Ort für ein Geheimnis. Jeder, der schon einmal gesehen hat, wie ein Modell seine eigenen Umgebungsvariablen ausgibt, weiß das. Ich meine, wenn du aufpasst, wirst du feststellen, dass dein Lieblings-Coding-Agent standardmäßig so tut, als würde er ein Auge zudrücken, wenn er einen sensiblen Schlüssel in deinem Prompt erkennt. Aber ein Schlüssel, der in einen Agenten eingefügt wird, landet nicht nur in der Shell-Historie; er geht auch an einen Modellanbieter, in Logs, in jedes Transkript, das die Umgebung führt.

Die API ist da, aber sie ist nicht der Hauptweg, den wir für Agenten entwickelt haben, um sich selbst einzurichten. Über SSH hält der Agent den einen Anmeldedatentyp, den dein Betriebssystem bereits schützen sollte: einen SSH-Key, und die private Hälfte wird nie übertragen. Die Authentifizierung bei Oberik legt nichts Geheimes in den Kontext des Modells, weil es nichts gibt, was dort hineingehört.

Warum nicht ein CLI?

Kurz gesagt: das Veraltungsproblem.

Die Installation eines CLI ist eine Verpflichtung, die man von der Umgebung jedes Integrators verlangt, und wir wollten nicht so dreist sein, wo wir doch erst unsere ersten Schritte machen. Um ehrlich zu sein, wir wollten überhaupt kein CLI, da es im Grunde eine eingefrorene Kopie des Produkts ist. Die Steuerungsebene von Oberik wird mit mehr Feedback wachsen, was bedeutet, dass wir, wenn wir uns für ein CLI entschieden hätten, ständig ein neues Release pushen und den Benutzer zum Update auffordern müssten.

Wir haben das im Grunde gelöst, indem unsere SSH-Oberfläche generiert und nicht geschrieben wird. Jede Route in unserer Steuerungsebene registriert sich zusammen mit ihrer Beschreibung, und diese Beschreibung ist der SSH-Befehl. Eine zum Dashboard hinzugefügte Route erscheint sofort über SSH, sodass wir uns keine Sorgen um eine Gateway-Änderung machen müssen.

Nichts zu aktualisieren, weil nichts installiert ist.

Warum nicht ein Skill?

Kurz gesagt: das Anleitungsproblem.

Der Trend bei Produkten, die sich an Agenten richten, sind Skills. Eine schriftliche Prozedur, die dein Agent installiert und die ihm sagt, wie er das Produkt aufrufen soll. Skills sind wirklich nützlich, aber es ist im Wesentlichen eine ausgefallene README-Datei. Ein Skill ist Dokumentation, keine Fähigkeit. Er gibt deinem Agenten keine Möglichkeit zu handeln; er braucht immer noch MCP oder eine API darunter, um etwas zu tun, und du erbst dieses Problem ebenfalls.

Darüber hinaus ist ein Skill eine eingefrorene Kopie der Nutzung eines sich bewegenden Produkts. Die gleiche Veraltung wie bei einem CLI. Er sitzt im Kontext des Agenten, bevor der Agent überhaupt etwas getan hat, und verbraucht Aufmerksamkeit und Tokens für Anweisungen, die die Oberfläche einfach auf Anfrage ausgeben könnte.

Unsere Antwort auf „Woher weiß der Agent, was Oberik kann“ ist keine Datei, die er installiert. Es ist ein Aufruf zur Erkundung für den Agenten:

1$ ssh ssh.oberik.com 'discover'                  # jeder Befehl, seine Parameter und deren Typen
2$ ssh ssh.oberik.com 'docs'                      # jede Seite, mit dem, was sie abdeckt
3$ ssh ssh.oberik.com 'docs search capability'    # die Zeilen, die etwas erwähnen

Die Oberfläche beschreibt sich selbst, zur Verbindungszeit, aus dem Live-Produkt. Und docs ist derselbe Text wie die Docs-Website, also ist nichts eine Zusammenfassung von etwas anderem. Die Anweisungen können nie veralten, weil sie das Produkt sind.

Warum SSH?

Kurz gesagt: Es löst alle fünf Probleme auf einmal.

1. Schlüssel sind die Anmeldedaten, die Agenten tatsächlich halten können. SSH-Key-Authentifizierung ist jahrzehntealt, milliardenfach bewährt, und das Protokoll überprüft die Signatur, bevor wir uns überhaupt einen Fingerabdruck ansehen. Wir hatten nicht das Gefühl, das Rad neu erfinden zu müssen. Wir haben einfach aufgehört, das Modell zu bitten, ein Geheimnis zu hüten, und ließen die Maschine die eine Aufgabe erledigen, für die sie immer gebaut wurde.
2. Du bleibst im Loop, ohne ein Passwort zu teilen. Wenn der Agent noch keinen Schlüssel hat, z. B. bei seiner ersten Verbindung zu Oberik, startet er einen Device-Login-Flow. Der Agent führt login link aus, was sofort mit einer URL und einem Code zurückkommt und beides dir anzeigt. Du öffnest die URL in deinem eigenen Browser. Die Seite identifiziert den genauen Schlüssel-Fingerabdruck, der angehängt wird, gibt dir Optionen zum Genehmigen oder Ablehnen und zeigt einen Code, den du mit dem vom Agenten gedruckten vergleichen kannst. Währenddessen führt der Agent login wait aus und wartet auf deine Entscheidung. Dies sind absichtlich separate Befehle. Wenn ein Befehl sowohl den Link generieren als auch warten würde, würde der Agent dir den Link erst zeigen, nachdem die Anfrage abgelaufen ist. Sobald du zustimmst, wird der Schlüssel registriert, und alle zukünftigen Verbindungen werden automatisch angemeldet. Du wirst keinen weiteren Link benötigen. Kein Geheimnis wird jemals in den Chatverlauf des Agenten geschrieben, weil der Prozess keins verwendet.
3. Die Ausgabe ist für Pipes ausgelegt. Fordere JSON mit --json bei einem Befehl an oder verwende format json; einmal am Anfang einer Zeile, und jede Antwort kommt als einzeiliges Envelope zurück. Das macht jq '.data[0].name' zur beabsichtigten Methode, die Ausgabe zu lesen, nicht zu einem Workaround. Der Filter läuft auf dem Rechner, sodass das Modell nur das sieht, was nach dem Filtern übrig bleibt. Fehler verwenden dasselbe Envelope und enthalten den zugrunde liegenden HTTP-Status. Das ermöglicht es einem Wiederholungsversuch, einen 429 von einem 400 zu unterscheiden. Pipes funktionieren auch in beide Richtungen. Das Gateway kann deine Festplatte nicht lesen, daher akzeptieren Befehle, die Dateien annehmen, den Dateinamen als Argument und lesen den Inhalt der Datei aus der Verbindung. Zum Beispiel lädt ssh [ssh.oberik.com](https://ssh.oberik.com/) 'document upload handbook.pdf' < handbook.pdf die Datei hoch.
4. Null Installation. Nichts zu registrieren, nichts zu speichern, nichts im Kontext zu behalten. Kein MCP-Server in der Konfiguration deines Agenten, kein Token in einer Umgebungsvariable, kein CLI im PATH, keine Skill-Datei. Wir bauen ein Entwicklerprodukt, also haben wir das Tool verwendet, das bereits da war und das jeder Agent zu nutzen weiß: SSH.
5. Selbstbeschreibend und von Natur aus vorsichtig. discover gibt den vollständigen Befehls-Katalog aus. Er enthält jeden Befehl, seine Parameter und Typen sowie alle Bestätigungsanforderungen. Der Katalog wird live aus dem Produkt generiert. Er teilt dem Client auch mit, welche Felder Dateibytes anstelle eines Strings erwarten, sodass Uploads nicht falsch erraten werden können. Was er nicht erlaubt, ist das Anvisieren einer Zeile anhand ihrer Nummer. Destruktive Befehle erfordern einen Namen, und der Server überprüft diesen Namen gegen das durch die Verbindung ausgewählte Projekt. Wenn Staging angefordert wird, während Support Bot ausgewählt ist, gibt der Server einen 400 zurück und lässt den Workspace unberührt.

Nichts zu lehren, weil die Oberfläche sich selbst lehrt.

So sieht der Oberik-Login-Flow aus:

Oberik Login Flow

Ist eine SSH-Tür in dein Produkt nicht ein Risiko?

Das ist eine berechtigte Frage, aber die Realität ist fast das Gegenteil.

Das Gateway hat keinen eigenen Zustand oder Berechtigungen. Jeder Befehl läuft durch eine HTTP-Control-Plane-Sitzung, genau wie in der React-App. Ein SSH-Client kann daher nicht mehr tun, als dasselbe Konto in einem Browser tun kann. Wenn du dich abmeldest, den Schlüssel widerrufst oder das Konto löschst, wird die Änderung sofort wirksam, weil es nichts anderes zu widerrufen gibt.

Dieses Terminal ist dem öffentlichen Internet ausgesetzt, sodass sich jeder anonym verbinden kann. Jeder Befehl wird protokolliert, einschließlich der Verbindungsidentität, IP-Adresse, des Schlüssels und des Ergebnisses. Anmeldedaten werden nie gespeichert. Ein mit login eingegebenes Passwort oder ein über --values übergebener Provider-Key wird durch <redacted> ersetzt, bevor der Datensatz geschrieben wird. Das System speichert auch einen Hash des ursprünglichen Befehls, sodass wiederholte Befehle korreliert werden können, ohne die Anmeldedaten wiederherstellbar zu machen. Datensätze werden 30 Tage oder 100.000 Befehle lang aufbewahrt, je nachdem, was zuerst eintritt.

Wiederholte fehlgeschlagene Anmeldungen werden langsamer, anstatt eine Sperre auszulösen. Jemand, der vergessen hat, welches Passwort er verwendet hat, kann es ohne große Reibung weiter versuchen, während eine automatisierte Wiederholungsschleife mit dem falschen Passwort zunehmend nutzlos wird. Das ist der beabsichtigte Kompromiss.

TL;DR

Alle anderen geben deinem Agenten eine API, einen MCP-Server oder eine Skill-Datei. Wir haben ihm ein Terminal gegeben. Es stellt sich heraus, dass es das war, was er wollte.