DeepSeek Harness auf VPS privat per SSH-Tunnel nutzen

Was das DeepSeek Harness ist

Das DeepSeek Harness (dsh) ist eine Node.js-Agentenlaufzeit, die Sie auf einem VPS (virtuellen privaten Server) ausführen können. Der sichere Betriebsmodus bindet sie an 127.0.0.1. Ihr Browser greift anschließend über einen SSH-Tunnel (Secure Shell) darauf zu. Das Harness stellt eine Weboberfläche (Benutzeroberfläche) auf Port 3080 bereit und läuft nicht in einem Terminal. Dieser Webserver verlangt selbst kein Passwort. Ein veröffentlichter Port 3080 gibt daher jedem, der ihn findet, Zugriff auf einen Agenten, der Ihre Dateien liest und Befehle mit den Rechten Ihres Linux-Benutzers ausführt.

DeepSeek hat das Harness am 13. August 2026 unter der MIT-Lizenz als npm-Paket @deepseek-ai/dsh veröffentlicht. Das Projekt bezeichnet sich selbst als Entwicklervorschau und weist darauf hin, dass Änderungen zu erwarten sind, die die Kompatibilität beeinträchtigen. Jede unten genannte Versionsnummer entspricht dem Stand von August 2026. Prüfen Sie daher das Repository, bevor Sie diese Angaben auf einem wichtigen System übernehmen.

Ein Grundsatz zieht sich durch das gesamte Design: Alles ist ein Plugin. Der Modelladapter, die Werkzeugregistrierung, das Sitzungsprotokoll, die Sandbox, der Scheduler und die Agentenschleife selbst sind Plugins, die in einen gemeinsamen Kontext geladen werden. Jedes dieser Plugins kann ersetzt werden. Es gibt keinen privilegierten Kern, den Plugins lediglich erweitern. Das macht das Harness interessant. Gleichzeitig liegt genau darin das einzige wesentliche Risiko.

Ein Harness ist kein Modell

Das Harness führt die Agent-Schleife aus. Die Verarbeitung findet in einem Modell an anderer Stelle statt. Daher funktioniert nichts, bis Sie entweder einen API-Schlüssel (Application Programming Interface) oder die Adresse eines von Ihnen selbst gehosteten Modell-Endpunkts angeben.

Sie konfigurieren dies in der UI unter Settings und anschließend unter Models. Der Katalog enthält fertige Karten für die großen API-Anbieter (DeepSeek, OpenAI, Anthropic), in die Sie einen Schlüssel einfügen. Die interessante Option ist „Add a custom provider“: Sie übernimmt eine Provider-ID, einen Anzeigenamen, eine Basis-URL, ein API-Protokoll und ein Zugangstoken. Sie verwendet das OpenAI-kompatible Protokoll. Daher funktioniert jeder Gateway oder lokale Server, der dieses Protokoll implementiert. Benutzerdefinierte Provider können außerdem den OpenAI-kompatiblen GET /models-Endpunkt abfragen, um die Modellliste automatisch auszufüllen.

So richten Sie das Harness auf ein Modell auf demselben VPS. Ollama stellt unter http://127.0.0.1:11434/v1/ eine OpenAI-kompatible API bereit. Im Feld für den API-Schlüssel muss eine beliebige Zeichenfolge stehen, üblicherweise ollama, weil das Feld erforderlich ist und der Wert anschließend ignoriert wird. Ob ein Modell, das klein genug für Ihren VPS ist, einen Agenten zuverlässig steuern kann, ist die schwierigere Frage. Der Unterschied zwischen Ollama und vLLM als lokalem Modellserver entscheidet darüber, wie viel RAM die Antwort benötigt.

In die UI eingegebene Schlüssel können nur geschrieben, nicht ausgelesen werden. Das Harness speichert sie in $DSH_HOME/.credentials.yaml und hinterlegt in settings.yaml nur eine Referenz auf das Zugangstoken. $DSH_HOME verwendet standardmäßig ~/.dsh. Behandeln Sie diese Datei wie eine Kennwortdatei, denn genau das ist sie: Jeder, der sie lesen kann, kann Ihr API-Budget verbrauchen.

Was Sie vor der Installation benötigen

• einen VPS mit Ubuntu 24.04 oder einem anderen aktuellen Linux-System und SSH-Zugriff
• Node.js 22.19 oder neuer aus der 22.x-Reihe oder Node.js 24 und höher, da das Projekt gegen diese Versionen erstellt und getestet wird
• ein normales Benutzerkonto, nicht root, da der Agent Shell-Befehle unter dem Konto ausführt, das den Prozess gestartet hat
• pnpm im PATH, wenn Sie Plugins installieren möchten, da der Plugin-Befehl dieses Programm über eine Shell aufruft
• Port 3080 in Ihrer Firewall und in der separaten Netzwerk-Firewall Ihres Providers geschlossen

Das Ubuntu-eigene nodejs-Paket ist älter als für den Harness erforderlich. Installieren Sie Node daher über NodeSource oder nvm, statt apt install nodejs zu verwenden. Wenn der VPS neu eingerichtet ist, lohnt es sich, SSH vor allen anderen Schritten abzusichern. Der Tunnel, von dem Sie gleich abhängig sind, ist nur so sicher wie der SSH-Server dahinter.

DeepSeek Harness auf einem VPS installieren und auf eine Version festlegen

node --version
npx @deepseek-ai/dsh@0.1.0-rc.6 web

npx lädt das Paket herunter und führt dessen dsh-Binärdatei aus. web ist ein Alias für --profile web. Damit wird die Browseranwendung gestartet, und der Prozess gibt die Adresse aus, an der er Verbindungen entgegennimmt. Der Standardwert ist http://127.0.0.1:3080.

Legen Sie die Version fest. npx @deepseek-ai/dsh web löst bei jeder Ausführung auf, worauf das Tag latest zu diesem Zeitpunkt zeigt. Das Projekt hat bereits mehrere Release Candidates veröffentlicht und kündigt inkompatible Änderungen an. 0.1.0-rc.6 ist die Version, auf die latest am 13. August 2026 zeigte. Mit einer festgelegten Version verhält sich der heute eingerichtete Server auch im nächsten Monat gleich. Ein Upgrade wird dadurch zu einer bewussten Entscheidung statt zu einer unerwartet festgestellten Änderung.

Für den täglichen Betrieb installieren Sie das Paket einmal, statt die Version bei jedem Start erneut aufzulösen.

npm install -g @deepseek-ai/dsh@0.1.0-rc.6
dsh --profile web --help

Die zweite Zeile sollten Sie ausführen, weil der Launcher und die Webanwendung separate Optionssätze verwenden. dsh --help zeigt die eigenen Optionen des Launchers. dsh --profile web --help zeigt die von der Webanwendung akzeptierten Optionen. Dort finden Sie --port, --host und die mehrfach verwendbare Option --trusted-host.

Prüfen Sie nun, an welcher Adresse der Prozess Verbindungen entgegennimmt.

ss -tlnp | grep 3080

In der Spalte für die lokale Adresse sollte 127.0.0.1:3080 stehen. Wenn dort 0.0.0.0:3080 steht, ist die Benutzeroberfläche aus dem Internet erreichbar. Beenden Sie den Prozess, bevor Sie etwas anderes tun.

Warum Sie Port 3080 niemals veröffentlichen dürfen

Der Webserver verfügt über keine Authentifizierungsschicht. Seine Konfiguration legt einen Listen-Host und einen Listen-Port fest. Das ist die gesamte Angriffsfläche. Die Zugriffskontrolle für Deployments außerhalb von Loopback erfolgt über eine separate Einstellung für vertrauenswürdige Hosts. Dabei handelt es sich nicht um eine Anmeldemaske.

Betrachten Sie nun, was hinter diesem Port läuft. Der Agent bearbeitet Dateien im Workspace und führt Shell-Befehle aus. Ihre Zugangsdaten für den Provider liegen daneben auf der Festplatte. Ein offener Port 3080 ist daher eine Remote-Shell mit Chat-Oberfläche. Sie läuft unter dem Benutzer, der sie gestartet hat, und verwendet Ihren API-Key. Dafür ist kein Exploit erforderlich. Die Angreifer benötigen nur die Portnummer. Scanner finden offene Ports innerhalb weniger Stunden, nachdem ein Host online gegangen ist.

Die CLI (Befehlszeilenschnittstelle) bestätigt das. Ab 0.1.0-rc.6 unterstützt sie --host 0.0.0.0 absichtlich nicht. Statt zu starten, wird ein Verwendungsfehler ausgegeben. Diese Verweigerung ist ein Sicherheitsmerkmal. Suchen Sie daher nicht nach einem Patch, der sie entfernt.

Zwei weitere Deployments sind sinnvoll, wenn ein Tunnel für Sie nicht infrage kommt. Binden Sie den Rechner in ein privates Overlay-Netzwerk ein. Dann besitzt er nur eine Adresse, die ausschließlich Ihre eigenen Geräte routen können. Genau das bietet ein selbst gehosteter Headscale-Steuerungsserver. Oder schalten Sie einen Reverse Proxy davor, der die Anfrage authentifiziert, bevor sie Port 3080 erreicht, beispielsweise ein Authentik-Server für Single Sign-on mit Forward Auth. Ein Reverse Proxy ohne Authentifizierung davor ist keine Sicherheitskontrolle. Er ist nur eine längere URL.

Über die Weboberfläche per SSH-Tunnel zugreifen

Führen Sie diesen Befehl auf Ihrem Laptop aus, nicht auf dem Server.

ssh -N -L 3080:127.0.0.1:3080 you@your-server

-L öffnet Port 3080 auf Ihrem Laptop und leitet alle Verbindungen, die diesen Port erreichen, durch die verschlüsselte SSH-Sitzung weiter. Der Teil 127.0.0.1:3080 wird auf dem Server aufgelöst. Die Verbindung erreicht das Harness daher über Loopback, genau so, als würden Sie direkt am Rechner sitzen. -N gibt an, dass keine entfernte Shell gestartet werden soll, weil Sie nur die Weiterleitung benötigen.

Öffnen Sie anschließend http://127.0.0.1:3080 in Ihrem lokalen Browser. Wenn Port 3080 auf Ihrem Laptop bereits belegt ist, ändern Sie die Zahl auf der linken Seite: ssh -N -L 3180:127.0.0.1:3080 you@your-server. Rufen Sie anschließend http://127.0.0.1:3180 auf. Die Zahl auf der linken Seite ist lokal. Die Zahl auf der rechten Seite gehört zum Server. Daher wird nur die linke Zahl geändert.

Speichern Sie den Befehl in ~/.ssh/config und geben Sie ihn nicht jedes Mal erneut ein.

Host dsh
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  LocalForward 3080 127.0.0.1:3080

Danach startet ssh -N dsh den Tunnel. Wenn der Browser meldet, dass die Verbindung abgelehnt wurde, ist der Tunnel normalerweise aktiv, aber auf der anderen Seite lauscht kein Dienst. SSH leitet den Port unabhängig davon weiter, ob das Harness ausgeführt wird. Prüfen Sie den Server mit dem oben angegebenen Befehl ss.

Harness nach der Abmeldung weiter ausführen

Ein npx-Befehl wird zusammen mit Ihrer Shell beendet. Ein systemd-Benutzerdienst läuft weiter und startet den Harness nach einem Absturz oder Reboot erneut.

loginctl enable-linger $USER
mkdir -p ~/.config/systemd/user
command -v dsh

enable-linger ist wichtig, weil Benutzerdienste normalerweise beendet werden, sobald Ihre letzte Sitzung endet. Ohne diese Einstellung wird der Harness beendet, sobald Sie den Tunnel schließen. Übernehmen Sie den von command -v dsh ausgegebenen absoluten Pfad in die Unit, weil systemd nicht den PATH durchsucht, den Ihre Login-Shell erstellt.

[Unit]
Description=DeepSeek Harness web UI
After=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/projects/site
ExecStart=/usr/local/bin/dsh web
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

WorkingDirectory ist keine rein kosmetische Einstellung. Der dsh-Prozess verwendet sein aufrufendes Verzeichnis als standardmäßigen Speicherort im Dateisystem. Wird ein Dienst im falschen Verzeichnis gestartet, erhält der Agent dadurch den falschen Standardarbeitsbereich. Den Arbeitsbereich können Sie weiterhin in der UI auswählen.

systemctl --user daemon-reload
systemctl --user enable --now dsh
systemctl --user status dsh

Eine Unit, die den Start verweigert, verwendet fast immer einen falschen ExecStart-Pfad oder eine Node-Version, die das Binary ablehnt. journalctl --user -u dsh -n 50 zeigt an, welcher Fall vorliegt. Dasselbe Muster gilt für einen beliebigen Coding-Agent auf einem VPS weiter auszuführen; die Fehlerursachen sind identisch.

Was ein Plugin ausführen darf

Ein Plugin ist ein Modul, das Dienste, typisierte Ereignisse und umkehrbare Effekte zu einem gemeinsamen Kontext beiträgt. Die Erweiterungspunkte sollten Sie besonders genau prüfen:

• einen Modell-Provider auf ctx.llm registrieren
• modellseitige Tools auf ctx.tools hinzufügen
• das Shell-Backend hinter ctx.shell bereitstellen
• Dateisystemzugriff oder Richtlinien hinter ctx.fs bereitstellen
• menschliche Befehle auf ctx.commands registrieren
• Hintergrundaufgaben über ctx.jobs ausführen
• gestartete Prozesse mit einem ctx.sandbox-Backend umschließen
• Anfragen und Tool-Aufrufe über die Ereignisse agent/* und tools/* abfangen
• den dauerhaft gespeicherten Sitzungsstatus erweitern
• die Benutzeroberfläche über ctx.agents steuern

Betrachten Sie diese Liste aus der Sicht eines Angreifers. Ein Plugin kann die Dateisystem- und die Shell-Schicht bereitstellen und sich zwischen jeden Tool-Aufruf des Modells schalten. Zwischen einem Plugin und diesen Schnittstellen steht kein Berechtigungsdialog, weil ein Plugin gewöhnlicher Node-Code ist, der im selben Prozess wie alle anderen Komponenten geladen wird. Ein Plugin zu installieren bedeutet, fremden Code mit den Berechtigungen Ihres Agenten auszuführen. Die Berechtigungen Ihres Agenten entsprechen den Berechtigungen Ihres Unix-Benutzers.

Dies ist dieselbe Vertrauensentscheidung wie beim Einbinden eines MCP-Servers in einen Agenten auf einem VPS, wobei MCP für Model Context Protocol steht. Deshalb beginnt auch das sichere Betreiben eines Coding-Agenten auf einem VPS mit dem Konto, unter dem er ausgeführt wird, und nicht mit dem Modell. Aus demselben Grund sind npm-Lieferkettenangriffe auf Servern besonders schwerwiegend: Der Installationsschritt stellt bereits die Kompromittierung dar, und es wird keine Rückfrage angezeigt.

Woher Plugins kommen

Plugins befinden sich in Profilen. Ein Profil ist eine benannte Zusammensetzung, die unter $DSH_HOME gespeichert wird. Standardmäßig ist dies ~/.dsh. Jedes Profilverzeichnis enthält die externen Plugins, die dort installiert werden. Die CLI verwaltet sie, indem sie Ihre Argumente direkt an pnpm weiterleitet und das Profilverzeichnis als Arbeitsverzeichnis verwendet.

dsh plugin --profile web add github:deepseek-harness/turtle-ui
dsh plugin --profile web remove turtle-ui

Da die Argumente unverändert an pnpm übergeben werden, verhalten sich add, remove, update und why wie in jedem pnpm-Projekt. Ein Plugin kann ein npm-Paket oder eine GitHub-Referenz sein. pnpm muss sich zuerst im PATH befinden. Unter Node 22 und höher stellt corepack enable pnpm es dort bereit.

Die Suche erfolgt über ein GitHub-Thema. Plugin-Autoren fügen ihrem Repository das Thema dsh-plugin hinzu. Über dieses Thema finden Sie vorhandene Plugins. Ein Thema ist eine Bezeichnung, die ein Autor auf sein eigenes Repository anwendet. Niemand prüft oder signiert diese Bezeichnung. Die Themenseite sortiert nach Sternen. Sterne messen die Popularität, nicht die Sicherheit.

Vier Gewohnheiten halten den Aufwand überschaubar. Lesen Sie den Quellcode vor der Installation, da die meisten Plugins klein genug sind, um sie in zehn Minuten zu lesen. Fixieren Sie die exakte Version oder den Commit, statt einem Branch zu folgen. Führen Sie den Harness unter einem Benutzer aus, der nichts anderes besitzt, und auf einem VPS, den Sie bei Bedarf neu aufsetzen würden. Geben Sie dem Agenten einen eigenen API-Schlüssel mit einem eigenen Ausgabenlimit. Dieser Schlüssel muss vom Schlüssel Ihrer Produktionsdienste getrennt sein.

Wenn Sie Designs lieber vergleichen möchten, bevor Sie sich für eines entscheiden, behandelt der Omnigent-Multi-Agent-Harness dasselbe Problem mit einer anderen Struktur. Die Unterschiede werden deutlich, sobald Plugins zum Einsatz kommen.

Was zuerst ausfällt

Node ist zu alt. Das Projekt zielt auf Node 22.19 und neuere Versionen der 22.x-Reihe sowie auf Node 24 und höher ab; diese Versionen werden auch in der CI getestet. Eine ältere Laufzeitumgebung schlägt beim Start fehl, weil der Code Syntax und APIs verwendet, die dort nicht verfügbar sind. Führen Sie zuerst node --version aus.

Port 3080 ist bereits belegt. Möglicherweise läuft ein zweites Harness, ein veralteter Prozess oder eine andere Anwendung, die ebenfalls Port 3080 verwendet. Ermitteln Sie den Prozess mit ss -tlnp | grep 3080. Beenden Sie ihn oder starten Sie das Harness mit dsh web --port 3180 an einem anderen Port. --port gehört zur Webanwendung und wird daher nach web ausgeführt.

Der Browser kann über den Tunnel keine Verbindung herstellen. Stellen Sie sicher, dass Sie 127.0.0.1 und nicht die öffentliche Adresse des Servers aufgerufen haben. Der weitergeleitete Port ist nur auf Ihrem Laptop verfügbar. Prüfen Sie anschließend, ob das Harness auf dem Server Verbindungen annimmt. SSH richtet die Weiterleitung unabhängig davon ein, ob am entfernten Ende ein Dienst antwortet.

dsh plugin schlägt sofort fehl. Der Befehl ist ein Wrapper für pnpm. Fehlt die Binärdatei pnpm, wird der Befehl beendet, bevor die Plugin-Verarbeitung beginnt.

Der Agent kann Ihr Projekt nicht sehen. Der Arbeitsbereich ist standardmäßig das Verzeichnis, in dem der Prozess gestartet wurde. Wenn WorkingDirectory einer Unit auf Ihr Home-Verzeichnis zeigt, erhält der Agent daher Zugriff auf Ihr Home-Verzeichnis. Wählen Sie den Arbeitsbereich in der Benutzeroberfläche aus oder korrigieren Sie die Unit und laden Sie sie neu.

FAQ

Ist es sicher, die Weboberfläche von DeepSeek Harness auf Port 3080 bereitzustellen?

Nein. Der Webserver hat keine eigene Anmeldung. Der dahinterliegende Agent bearbeitet Dateien und führt Shell-Befehle unter dem Benutzerkonto aus, das den Prozess gestartet hat. Ihr Provider-API-Schlüssel liegt auf demselben Datenträger. Lassen Sie den Listener auf 127.0.0.1 gebunden und greifen Sie über einen SSH-Tunnel darauf zu. Auch ein privates Overlay-Netzwerk oder ein Reverse Proxy, der jede Anfrage authentifiziert, bevor sie den Port erreicht, ist geeignet. Ab Version 0.1.0-rc.6 verweigert die CLI --host 0.0.0.0 und beendet sich mit einem Usage-Fehler. Das zeigt, wie die Autoren diese Konfiguration bewerten.

Benötige ich einen DeepSeek-API-Schlüssel, oder kann ich ein lokales Modell verwenden?

Beides ist möglich, weil der Harness eine Laufzeitumgebung und kein Modell ist. Unter Settings und anschließend Models können Sie einen Schlüssel in die Karte eines Katalog-Providers einfügen. Alternativ können Sie "Add a custom provider" auswählen und eine Base-URL angeben, die das OpenAI-kompatible Protokoll unterstützt. Ein lokaler Ollama-Server antwortet unter http://127.0.0.1:11434/v1/ und akzeptiert im Feld für den API-Schlüssel eine beliebige Zeichenfolge. Die Schlüssel werden in $DSH_HOME/.credentials.yaml gespeichert. Der Standardwert dafür ist ~/.dsh/.credentials.yaml.

Welche Berechtigungen erhält ein DeepSeek-Harness-Plugin tatsächlich?

Es erhält die Berechtigungen des Benutzerkontos, unter dem der Harness ausgeführt wird. Ein Plugin besteht aus Node-Code, der in denselben Prozess geladen wird. Zu den Erweiterungspunkten gehören das Shell-Backend, die Dateisystemschicht, die Tool-Registrierung und die Ereignisse, die jeden Tool-Aufruf umschließen. Nichts isoliert ein Plugin von diesen Schnittstellen, sofern das Plugin nicht selbst eine Sandbox bereitstellt. Lesen Sie vor der Installation den Quellcode. Führen Sie den Harness außerdem unter einem Benutzerkonto aus, das keine schützenswerten Dateien besitzt.

Welche Version sollte ich installieren, und wird sie weiterhin funktionieren?

Installieren Sie eine exakt angegebene Version, zum Beispiel npx @deepseek-ai/dsh@0.1.0-rc.6 web. Auf diese Version zeigte der latest-Tag am 13. August 2026. Das Projekt bezeichnet sich als Developer Preview und weist darauf hin, dass inkompatible Änderungen zu erwarten sind. Ein nicht fixierter Befehl kann sich daher von einem Tag auf den nächsten anders verhalten. Prüfen Sie vor einem Upgrade das Repository. Rechnen Sie damit, dass sich Konfigurationsschlüssel und Plugin-Schnittstellen ändern, solange die Versionsnummer mit 0 beginnt.