dsh-Plugins prüfen: Risiken und Berechtigungen verstehen

Was ist ein dsh-Plugin, und was kann es tun?

dsh-Plugins sind Node-Pakete, die der DeepSeek Harness in seinen eigenen Prozess lädt. Bei der Installation wird Code von Dritten mit den Berechtigungen Ihres Agenten auf dem Computer ausgeführt, den Ihr Agent bereits erreichen kann. Zwischen einem geladenen Plugin und dem restlichen Harness gibt es keine weitere Schutzschicht. Vor der Installation sollten Sie daher klären, worauf dieser Code zugreifen kann und wie Sie diesen Zugriff begrenzen.

dsh (DeepSeek Harness) ist der Open-Source-Agent-Harness von DeepSeek AI. Er basiert auf einem Plugin-Framework namens Cordis. In der README des Projekts steht, dass alles ein Plugin ist. Der Modelladapter ist ein Plugin. Auch die Weboberfläche, in die Sie Eingaben machen, ist ein Plugin. Alles, was Sie außerhalb des Projekts installieren, landet im selben Baum und hat dieselbe Vertrauensstufe wie die mitgelieferten Komponenten. Wenn Sie den Harness noch nicht eingerichtet haben, beginnen Sie mit dem DeepSeek Harness auf einem VPS und kehren Sie hierher zurück, bevor Sie weitere Komponenten hinzufügen.

Die Erweiterungspunkte, auf die ein Plugin zugreifen kann, sind im AGENTS.md des Repositorys aufgeführt. Im August 2026 umfassen sie:

• LLM (Large Language Model): der Anbieter, für den Ihr API-Schlüssel bezahlt
• Shell: die Bash-Funktion mit lokalen und pwsh-Anbietern
• Filesystem: richtliniengesteuerter Dateizugriff
• Web: Anbieter für Suche und Abruf
• Subprocess: ein Anbieter für Prozessbäume
• Workflow: Worker-Threads
• Subagent: die Delegation an weitere Agenten
• Settings and credentials: Ihre gespeicherte Konfiguration und Umgebungsvariablen

Ein Plugin registriert außerdem Tools in ctx.tools. Die Dokumentation stellt ausdrücklich klar, dass das Schema eines registrierten Tools in die Prompt-Zusammenstellung aufgenommen wird. Dieser zweite Aspekt wird häufig übersehen. Ein Plugin kann beeinflussen, wofür sich Ihr Agent entscheidet, ohne dass sein eigener Code etwas Ungewöhnliches ausführt. Der Text aus der Beschreibung wird Teil der Eingabe, die das Modell liest. Das entspricht dem Problem von Prompt-Injection-Angriffen gegen Coding-Agenten, mit einem Unterschied: Dieser Text gelangt bei der Installation in das System und bleibt dort, bis Sie das Plugin entfernen.

Wie findet und lädt dsh Plugins?

Es gibt kein globales Plugin-Verzeichnis. Ein laufendes dsh ist ein beim Start aus geordneten Ebenen zusammengesetzter Plugin-Baum. Die Einheit, in der Ihre Auswahl gespeichert wird, ist ein Profil. $DSH_HOME verwendet standardmäßig ~/.dsh. Jedes Profil liegt in $DSH_HOME/profiles/<name>. Die Profile web und headless werden bei der ersten Verwendung anhand der mitgelieferten Vorlagen erstellt.

Ein Profilverzeichnis enthält zwei Dateien, die alles festlegen:

• package.json mit den Abhängigkeiten der Plugins außerhalb des Baums sowie einem dsh.profile-Manifest mit der geordneten Liste bundles
• cordis.patch.yml, Ihre eigene Patch-Ebene über diesen Bundles

ls ~/.dsh
ls ~/.dsh/profiles/web

Beim Start werden die Ebenen in dieser Reihenfolge angewendet. Spätere Ebenen haben Vorrang:

1. ein leerer Root
2. die Bundles des Profils in der Reihenfolge, in der sie im Manifest aufgeführt sind
3. cordis.patch.yml des Profils
4. $DSH_HOME/cordis.patch.yml
5. alle über die Befehlszeile übergebenen --patch <path>-Overlays

Zwei Flags geben das Ergebnis dieser Zusammensetzung aus, ohne etwas zu starten:

dsh --profile web --dump-default-config
dsh --profile web --dump-config

--dump-default-config gibt den zusammengesetzten Baum allein aus. --dump-config fügt die Profil- und Home-Patch-Ebenen hinzu. Damit erhalten Sie die genaueste Übersicht darüber, was beim nächsten Start geladen wird. Prüfen Sie diese Ausgabe, bevor Sie einer übernommenen Maschine vertrauen.

Beachten Sie eine Besonderheit dieser Patch-Dateien. Die Konfiguration besteht hier nicht nur aus passiven Daten, weil das Format !!js-markierte Werte im Block config eines Plugins erlaubt. Ein aus einem Forenbeitrag kopierter cordis.patch.yml-Abschnitt ist Code. Behandeln Sie ihn daher wie ein Shell-Skript aus derselben Quelle.

Was führt dsh plugin add tatsächlich aus?

dsh plugin --profile <name> <args> leitet seine Argumente innerhalb des Verzeichnisses des jeweiligen Profils an pnpm weiter. Deshalb muss pnpm in PATH verfügbar sein. Die Verben stammen von pnpm:

dsh plugin --profile web add '<package-or-git-spec>'
dsh plugin --profile web remove '<package-name>'
dsh plugin --profile web why '<package-name>'
dsh plugin --profile web update

Das Sicherheitsmodell bei der Installation eines dsh-Plugins entspricht daher dem Sicherheitsmodell jeder npm-ähnlichen Abhängigkeit. Hinzu kommt ein weiterer Schritt: Das Ergebnis wird in Ihren Agenten geladen. Das Paket bringt seinen eigenen Abhängigkeitsbaum mit. Jedes Paket in diesem Baum läuft anschließend im selben Prozess. Alles unter wie npm-Lieferkettenangriffe einen Server erreichen gilt hier unverändert.

pnpm 10 und spätere Versionen führen die Build-Skripte einer Abhängigkeit standardmäßig nicht aus. Die Freigabe erfolgt pro Paket über onlyBuiltDependencies oder pnpm approve-builds. Prüfen Sie, welche pnpm-Version installiert ist:

pnpm --version

Diese Voreinstellung ist sinnvoll. Sie ist aber zugleich die am häufigsten überschätzte Sicherheitsfunktion in diesem Ökosystem. Blockierte Build-Skripte verhindern die Ausführung von Code während der Installation. Das Plugin selbst wird dadurch nicht eingeschränkt. Der Zweck eines Plugins besteht darin, dass der Harness es importiert und beim nächsten Start aufruft. Ein Plugin benötigt keinen postinstall-Hook. Es wurde ausdrücklich geladen.

Was Sie vor der Installation eines dsh-Plugins lesen sollten

Laden Sie das veröffentlichte Tarball herunter und lesen Sie es. Beim Entpacken eines Archivs wird nichts ausgeführt.

npm pack '<package-name>@<version>'
tar -tzf '<package-name>-<version>.tgz'
tar -xzf '<package-name>-<version>.tgz'
less package/package.json

Vier Felder in diesem package.json liefern Ihnen die meisten benötigten Informationen. Lesen Sie scripts für preinstall-, install- und postinstall-Einträge. Lesen Sie dependencies bei Namen, die Sie nicht erkennen, oder die sich nur um ein Zeichen von bekannten Namen unterscheiden. Lesen Sie bin für alles, was das Paket in Ihrem PATH benötigt. Lesen Sie main oder exports für die Einstiegsdatei. Öffnen Sie diese Datei anschließend und verfolgen Sie ihren Ablauf.

Lesen Sie danach den Code, der tatsächlich geladen wird. Ein Plugin, das ein Benachrichtigungswerkzeug bereitstellt, hat keinen Grund, ~/.ssh zu lesen, einen Ihnen unbekannten Host aufzurufen oder eine Shell zu starten. Wenn das Paket nur gebündeltes oder minimiertes JavaScript enthält und kein passender Quellcode in einem öffentlichen Repository vorhanden ist, ist das die Antwort. Bevorzugen Sie Plugins, deren Quellcode Sie lesen können, und bevorzugen Sie kleine Plugins.

Sie können das Registry auch ohne Installation prüfen:

pnpm view '<package-name>' dependencies
pnpm view '<package-name>' versions

Ein Paket, das letzte Woche veröffentlicht wurde, nur eine Version besitzt, kein Repository-Feld enthält und einen bekannten Namen nachahmt, ist der älteste Trick in jedem Registry. Downloads mit Prüfsummen verifizieren ist die naheliegende Ergänzung: Sie müssen genau wissen, was Sie heruntergeladen haben, bevor Sie es ausführen lassen.

Version festlegen und Lockfile aufbewahren

Ein frei auflösbarer Versionsbereich bedeutet, dass sich der Code in der Agentenlaufzeit bei jeder Installation oder Aktualisierung ändern kann, ohne dass Sie dies entscheiden. Legen Sie die Version fest.

dsh plugin --profile web add --save-exact '<package-name>@<version>'

Die Position von Flags unterscheidet sich zwischen pnpm-Versionen. Prüfen Sie daher das Ergebnis, statt dem Befehl zu vertrauen. Öffnen Sie anschließend das package.json des Profils und bestätigen Sie, dass die Abhängigkeit als reine Version ohne vorangestelltes ^ oder ~ eingetragen ist. Diese Datei bestimmt, was installiert wird.

Bewahren Sie anschließend das Lockfile auf. Es legt den gesamten transitiven Abhängigkeitsbaum fest und nicht nur den Namen der obersten Abhängigkeit:

find ~/.dsh -maxdepth 3 -name 'pnpm-lock.yaml'

Kopieren Sie es zusammen mit dem package.json des Profils an einen Ort, den Sie sichern. Mit diesen beiden Dateien können Sie auf einem neuen System denselben Abhängigkeitsbaum wiederherstellen. Führen Sie dsh plugin --profile web update aus, wenn Sie Versionen bewusst ändern möchten, niemals nur zum routinemäßigen Aufräumen, und lesen Sie anschließend den Diff des Lockfiles.

Bei einem Plugin, das statt aus einer Registry aus einem Git-Repository installiert wird, legen Sie den Commit statt des Branches fest. Eine Spezifikation der Form github:owner/repo#<full commit sha> liefert einen festen Abhängigkeitsbaum. Ein Branch-Name liefert bei der nächsten Auflösung durch pnpm den Inhalt, den dieser Branch dann enthält. Diese Entscheidung haben Sie damit an jemand anderen übertragen. Für den Harness gilt dieselbe Disziplin: Jeder veröffentlichte dsh-Build ist ein Release-Kandidat, und eine nicht festgelegte Installation kann an einem beliebigen Tag einen anderen Build auflösen. Daher entstehen die meisten Installations- und Versionsfehler bei dsh.

Der Plugin-Markt und der Wert einer „kuratierten“ Auswahl

dsh verfügt über einen Plugin-Markt und wird selbst als Plugin installiert. Das sagt etwas über die Architektur aus:

dsh plugin --profile web add dshmarket

Nach einem Neustart erscheint er unter Settings und anschließend unter Plugin Market. Die README beschreibt die Einschränkungen eindeutig. Installationen sind auf Quellen beschränkt, die in einer kuratierten Registry aufgeführt sind. Alles andere wird abgelehnt. Build-Skripte sind standardmäßig blockiert. Für ihre Aktivierung ist eine Freigabe pro Paket erforderlich. Terminal-Plugins werden gekennzeichnet, bevor sie in ein Webprofil aufgenommen werden. Am wichtigsten ist der Hinweis, dass eine Aufnahme keine Empfehlung darstellt, weil es sich bei den Plugins um Code von Drittanbietern handelt.

Eine kuratierte Liste setzt eine untere Sicherheitsgrenze. Sie prüft den Code jedoch nicht für Sie. Außerdem kann sie nicht vorhersagen, was die nächste Version eines Plugins tut, nachdem der Besitzer eines Maintainer-Kontos gewechselt hat. Behandeln Sie eine Installation mit einem Klick so, wie Sie curl | bash desselben Autors behandeln würden. Ein weiterer Hinweis aus dieser README ist erwähnenswert: Ein exportiertes Backup kann Zugangsdaten aus Ihrer Profilkonfiguration enthalten. Hängen Sie es daher niemals an ein öffentliches Issue an und stellen Sie es nicht auf einer Paste-Plattform bereit. Wenn Sie statt einer Methode eine Ausgangsliste suchen, ist dsh-Plugins, deren Installation sich lohnt der ergänzende Beitrag zu diesem Thema.

dsh als eigener Benutzer ausführen, nicht als root

Eine Überprüfung verringert die Wahrscheinlichkeit, dass etwas Schädliches eindringt. Das Prinzip der geringsten Rechte bestimmt, worauf es anschließend zugreifen kann. Auf einem VPS ist dieser zweite Teil schnell eingerichtet.

Geben Sie dem Harness ein eigenes Unix-Konto mit eigenem Home-Verzeichnis und führen Sie es niemals als root aus:

sudo adduser --disabled-password --gecos "" dshrun
sudo -iu dshrun

Starten Sie den Harness innerhalb dieser Sitzung, damit er sein Home-Verzeichnis unter diesem Konto anlegt:

npx @deepseek-ai/dsh web

Die Weboberfläche wird standardmäßig über http://127.0.0.1:3080 bereitgestellt. Lassen Sie sie dort. Jeder, der diesen Port erreicht, kann einen Agenten mit Shell steuern. Das Veröffentlichen von Port 3080 entspricht daher dem Veröffentlichen einer Root-losen Remote-Shell mit einer benutzerfreundlichen Oberfläche. Greifen Sie stattdessen über einen SSH-Tunnel von Ihrem Laptop darauf zu:

ssh -L 3080:127.0.0.1:3080 you@your-vps

Prüfen Sie anschließend, dass an keiner öffentlichen Adresse ein Dienst lauscht:

ss -lnt | grep 3080

Die lokale Adresse sollte 127.0.0.1:3080 lauten. Wenn sie 0.0.0.0:3080 lautet, ist Ihre Firewall das einzige Hindernis zwischen einem Fremden und Ihrem Agenten. Die Überlegungen zum sicheren Ausführen von Claude Code auf einem VPS gelten unverändert für dsh. Geben Sie dem Agenten ein einziges Arbeitsverzeichnis, das er beschädigen darf, und speichern Sie alles, was Sie nicht neu erstellen können, außerhalb dieses Rechners. Noch besser ist es, den Rechner als entbehrliche VM für Coding-Agenten zu behandeln, weil der Neuaufbau eines VPS eine Stunde dauert, während die Prüfung eines solchen Systems eine Woche kostet.

Wo Ihre Schlüssel liegen und warum Dateiberechtigungen nur begrenzt schützen

dsh speichert API-Schlüssel in $DSH_HOME/.credentials.yaml und Umgebungswerte in $DSH_HOME/.env. Modelleinstellungen liegen in $DSH_HOME/settings.yaml und der Sitzungsverlauf unter $DSH_HOME/storages. Welche Schlüssel in welche dieser Dateien gehören und welche Daten in den einzelnen Modi tatsächlich das System verlassen, wird unter API-Schlüssel, Modelle und Endpunkte in dsh konfigurieren behandelt. Das sollten Sie klären, bevor Sie ein Plugin hinzufügen. Jeder Schlüssel, den Sie einbinden, ist eine weitere Information, die ein Plugin lesen kann. Sichern Sie die beiden sensiblen Dateien ab:

chmod 600 ~/.dsh/.credentials.yaml ~/.dsh/.env
ls -l ~/.dsh

Der Modus 600 erlaubt dem Eigentümer das Lesen und Schreiben und allen anderen keinerlei Zugriff. Das ist sowohl in numerischer als auch in symbolischer Schreibweise wichtig (Numerische und symbolische chmod-Modi). Sie sollten sich jedoch über den tatsächlichen Schutz im Klaren sein. Dateimodi schützen diese Dateien vor anderen Konten auf dem System. Gegen ein Plugin schützen sie nicht, weil das Plugin als derselbe Benutzer wie der Eigentümer ausgeführt wird und innerhalb des Prozesses läuft, der die Dateien liest. Deshalb bedeutet Geheimnisse außerhalb der Reichweite eines KI-Agenten halten, dass Sie sie überhaupt nicht auf dem Rechner speichern. Auf einem dsh-System sollte nur der eine benötigte Model-Schlüssel liegen. Ihre Cloud-Zugangsdaten und Ihre Signaturschlüssel gehören an einen anderen Ort.

Warum ein Plugin, das das Web liest, das Bedrohungsmodell verändert

Die Web-Schnittstelle stellt Plugins Such- und Abrufanbieter bereit. Ein Plugin, das eine Seite in Ihre Sitzung lädt, lädt Text, den ein Angreifer kontrollieren kann. Eine Modellaufforderung trennt Anweisungen nicht von Daten. Daher kann eine abgerufene Seite eine Zeile enthalten, die an Ihren Agenten gerichtet ist. Ein Harness mit Shell-Berechtigung ist dann nur einen gehorsamen Schritt davon entfernt, diese Zeile auszuführen.

Die Kontrolle ist bereits im Harness vorhanden. dsh-base, das erste Bundle in jedem Profil, stellt die Sandbox und die Genehmigungsrichtlinie bereit. Nutzen Sie sie. Eine Sitzung, die nicht vertrauenswürdige Seiten abrufen kann, sollte für alles, was Dateien schreibt oder Befehle ausführt, eine Genehmigung verlangen. So kann eine abgerufene Anweisung nicht selbstständig zu einer Aktion werden. Agentenaktionen durch Genehmigungen absichern erläutert, wie Sie festlegen, wo diese Grenze verläuft. Die Beziehung gilt auch in der anderen Richtung: Ihr eigener Server ist eine Seite, die der Agent einer anderen Person abruft. Das ist der Anwendungsfall für KI-Crawler auf Ihrem Server blockieren.

Wie prüfe ich, was ein Plugin geändert hat?

Erstellen Sie einen Snapshot vor der Installation, installieren Sie das Plugin, erstellen Sie danach einen weiteren Snapshot und lesen Sie anschließend die Unterschiede.

dsh --profile web --dump-config > /tmp/dsh-before.txt
dsh plugin --profile web add '<package-name>@<version>'
dsh --profile web --dump-config > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt

Der Diff zeigt, welche Plugin-Einträge die Installation zum zusammengesetzten Baum hinzugefügt hat. Wenn ein Plugin, das Sie für eine kleine Funktion installiert haben, mehrere Einträge hinzufügt, die Sie nicht erklären können, sollten Sie anhalten und den Quellcode lesen, bevor Sie das Plugin starten. dsh plugin --profile web why <package-name> beantwortet die andere Frage: Welche Ihrer direkten Abhängigkeiten hat ein bestimmtes Paket eingebunden?

Installierte Pakete werden unter $DSH_HOME/profiles/node_modules abgelegt. Sie können den Baum daher auch auf dem Datenträger prüfen:

ls ~/.dsh/profiles/node_modules

Verwenden Sie ein zweites Profil, in dem Sie niemals experimentieren. Wenn eine Installation den Harness beschädigt, zeigt das Booten von dsh --profile <clean-name> innerhalb weniger Sekunden, ob das Plugin die Ursache war.

Wie entferne ich ein dsh-Plugin?

dsh plugin --profile web remove '<package-name>'
dsh --profile web --dump-config > /tmp/dsh-after-removal.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after-removal.txt

Durch das Entfernen der Abhängigkeit wird die Konfiguration nicht immer entfernt. Einträge in cordis.patch.yml des Profils bleiben bestehen, weil diese Datei Ihnen gehört und das Harness sie nicht für Sie neu schreibt. Öffnen Sie die Datei und löschen Sie jeden Block, in dem das entfernte Paket genannt wird.

less ~/.dsh/profiles/web/cordis.patch.yml

Anschließend müssen Sie den Teil berücksichtigen, den kein Deinstallationsbefehl beheben kann. Wenn Sie ein Plugin entfernt haben, weil Sie ihm nicht mehr vertraut haben, hat es bereits alles gelesen, worauf es zugreifen konnte. Rotieren Sie den DeepSeek-API-Schlüssel in der Provider-Konsole und alle anderen Zugangsdaten, die in $DSH_HOME gespeichert waren. Ermitteln Sie anschließend, auf welche Ressourcen im restlichen Netzwerk das Unix-Konto zugreifen konnte, unter dem das Plugin ausgeführt wurde.

Die Kurzfassung

• Lesen Sie das veröffentlichte Tarball vor der Installation, beginnend bei scripts und der Einstiegsdatei.
• Fixieren Sie die exakte Version oder bei einer git-Spezifikation den exakten Commit und behalten Sie die Lock-Datei.
• Installieren Sie in ein Profil und halten Sie ein sauberes Profil bereit, das Sie starten können, wenn etwas ausfällt.
• Vergleichen Sie --dump-config vor und nach jeder Installation.
• Führen Sie den Harness unter einem eigenen Unix-Benutzer auf dem Loopback-Interface aus und greifen Sie über SSH darauf zu.
• Bewahren Sie einen API-Schlüssel auf dem System auf und wechseln Sie ihn an dem Tag, an dem Sie ein Plugin entfernen, dem Sie nicht mehr vertrauen.

Nichts davon ist ein Grund, Plugins zu vermeiden. Das Plugin-Modell macht dsh nützlich. Ein Harness, den Sie nicht erweitern können, werden Sie ersetzen. Es ist ein Grund, zu wissen, was Sie installiert haben, von wem es stammt und in welcher Version es vorliegt. Führen Sie das gesamte System an einem Ort aus, den Sie neu aufbauen können.

FAQ

Isoliert dsh Plugins voneinander?

Nein. Ein Plugin wird über Cordis in den Harness-Prozess geladen und kann auf die dokumentierten Zugriffspunkte zugreifen, darunter Shell, Dateisystem, Web, Subprozesse, Subagenten und Zugangsdaten. dsh-base, das erste Bundle in jedem Profil, stellt die Sandbox- und Freigaberichtlinie bereit. Sie legt fest, was die Tools des Agents tun dürfen, und bietet Ihnen den eigentlichen Schutz. Es gibt keine Berechtigungsgrenze zwischen einzelnen Plugins. Das korrekte Sicherheitsmodell lautet daher: Mit der Installation eines Plugins erweitern Sie Ihr Vertrauen auf dessen Autor und auf jedes Paket in seinem Abhängigkeitsbaum.

Kann ich ein dsh Plugin installieren, ohne dessen Installationsskripte auszuführen?

pnpm 10 und höher blockiert standardmäßig Build-Skripte von Abhängigkeiten. dsh plugin ... add verwendet pnpm, daher führt eine aktuelle pnpm-Installation keine Package-Skripte aus, sofern Sie das betreffende Paket nicht freigeben. Prüfen Sie Ihre Version mit pnpm --version. Dadurch wird ein nicht geprüftes Plugin nicht sicher. Der Code des Plugins wird beim nächsten Booten ausgeführt, weil der Harness ihn gezielt lädt. Keine Einschränkung während der Installation verhindert das.

Wo befinden sich dsh Plugins und ihre Konfiguration tatsächlich?

$DSH_HOME verwendet standardmäßig ~/.dsh. Die Profile befinden sich in $DSH_HOME/profiles/<name>. Jedes Profil enthält ein package.json mit seinen Plugin-Abhängigkeiten, das dsh.profile-Manifest der geordneten Bundles und eine cordis.patch.yml-Patch-Ebene. Installierte Pakete werden unter $DSH_HOME/profiles/node_modules abgelegt. Schlüssel befinden sich in $DSH_HOME/.credentials.yaml, Umgebungswerte in $DSH_HOME/.env, und ein $DSH_HOME/cordis.patch.yml auf Home-Ebene wird auf jedes Profil angewendet. Führen Sie dsh --profile web --dump-config aus, um das zusammengesetzte Ergebnis ohne Booten anzuzeigen.

Ist die Installation aus dem dsh Plugin-Market sicher?

Der Market beschränkt Installationen auf Quellen in einer kuratierten Registry und blockiert Build-Skripte, sofern Sie sie nicht pro Paket freigeben. Das ist eine deutliche Verbesserung gegenüber dem Einfügen eines Paketnamens aus einem Chatfenster. Die eigene README weist dennoch darauf hin, dass eine Aufnahme keine Empfehlung bedeutet, da die Plugins von anderen Personen stammen und Drittanbietercode enthalten. Lesen Sie den Quellcode und pinnen Sie die Version. Betreiben Sie den Harness unter einem Benutzerkonto und idealerweise auf einem Rechner, dessen Verlust Sie verkraften können.