Er nutzt den OpenSSH-Client, der bereits auf Ihrem Rechner ist: Ihre Schlüssel, Ihre ~/.ssh/config, Ihre Jump-Hosts, Ihr Agent-Forwarding. Nichts wird mitgeliefert, nichts muss kompiliert werden, keine nativen Bindungen.
Funktioniert mit Claude Code, Codex CLI, opencode, Gemini CLI, Qwen Code, Hermes und anderen MCP-Clients.
Installation · Werkzeuge · Einrichtung · Sicherheit · Roadmap · Dokumentation · Changelog
Keine globale Installation erforderlich. npx lädt das Paket bei der ersten Verwendung herunter:
npx -y @hypnosis/ssh-mcp-serverFügen Sie es Claude Code für jedes Projekt hinzu:
claude mcp add ssh -s user \
-e SSH_PROFILES_FILE="$HOME/.claude/ssh-profiles.json" \
-- npx -y @hypnosis/ssh-mcp-serverErstellen Sie dann ~/.claude/ssh-profiles.json mit mindestens einer Maschine:
{
"profiles": {
"production": {
"host": "server.example.com",
"username": "admin",
"privateKeyPath": "~/.ssh/your_private_key"
}
}
}Das reicht, um sich zu verbinden.
Codex, opencode, Qwen Code und andere Clients werden in Einrichtung des SSH-MCP-Servers behandelt.
Node.js 18+ und ein System-ssh-Client im PATH. Verwenden Sie unter Windows ein schlüsselbasiertes Profil; Passwort- und Passphrase-Profile sind derzeit nicht verfügbar.
Bevorzugen Sie eine feste Version, Offline-Arbeit oder eine Registry-Prüfung weniger pro Start: npm install -g @hypnosis/ssh-mcp-server, und verwenden Sie dann ssh-mcp-server als Befehl statt npx.
Related MCP server: ssh-mcp-server
DevOps- und SRE-Teams, die schnellere Audits, Incident-Checks und routinemäßige Serverarbeiten wünschen.
Vibe-Coder und Indie-Builder, die mit einem KI-Assistenten entwickeln und das, was sie bauen, auf eigenen Servern betreiben.
Sysadmins und Plattformingenieure, die strukturierte Werkzeuge statt einer uneingeschränkten Roh-Shell wollen.
Entwickler und kleine Teams, die eine eigene VPS ohne dediziertes Betriebsteam betreiben.
Homelab-, NAS- und Router-Besitzer, deren nützliche Hardware ihre modernen Protokolle überlebt hat.
Eine rohe Shell gibt einem KI-Agenten einen Feuerwehrschlauch: wiederholte Befehle, ASCII-Tabellen und Log-Dumps. Es verbrennt Tokens, um dieses Rauschen in ein Bild des Servers zu verwandeln – Ihr Geld.
Speziell entwickelte Werkzeuge bündeln Routineprüfungen, begrenzen lautes Output und liefern den Teil, der zählt. Der Agent verbringt weniger Zeit damit, Terminalausgaben zu übersetzen, und kommt schneller zur Lösung.
Strukturierte Antworten sagen, was gefunden wurde, was nicht gemessen werden konnte und was abgeschnitten wurde. Das lässt dem Agenten weniger Raum, Lücken mit einer Halluzination zu füllen – und gibt Ihnen weniger schlechte Fixes, ruhigere Deploys und zuverlässigeren Code.
Keine gebündelte SSH-Implementierung, keine nativen Bindungen, kein Neubau pro Plattform. Befehle nutzen den System-ssh-Client, sodass Ihre Schlüssel, Ihre ~/.ssh/config, Ihre Jump-Hosts und Ihr Agent-Forwarding genau so funktionieren wie im Terminal. Wenn unterstützt, bedeutet eine gemeinsame multiplexte Verbindung pro Ziel, dass Sie sich einmal authentifizieren, nicht bei jedem Befehl.
Senden Sie eine Datei an einen Router mit einem modernen scp, und Sie erhalten Folgendes:
scp app.conf router:/etc/
# scp: subsystem request failed on channel 0Nichts ist kaputt – ein aktuelles scp spricht das neue Protokoll, und der Router kennt es nicht. In einem Terminal gehen Sie jetzt ein Forum lesen und kommen mit einem zusätzlichen Flag zurück. Hier tun Sie nichts: Die Übertragung wird versucht, die Ablehnung erkannt, das alte Protokoll stattdessen verwendet, und diese Maschine wird gemerkt, sodass die nächste Datei direkt dorthin geht.
Fallbacks für ältere SSH-Clients und fehlende Tools
Alte Geräte bekommen einen Fallback, keine Sackgasse. Wenn eine moderne Funktion fehlt, nimmt der Server, wo möglich, den älteren Weg:
Ihre Maschine | Was Sie bekommen |
Ein Router oder NAS, zu klein für modernen Dateitransfer | Die Datei landet trotzdem – das alte Protokoll wird automatisch verwendet |
Ein Server von vor zehn Jahren | Der Workflow funktioniert weiterhin; er öffnet nur eine frische Verbindung pro Befehl, statt eine wiederzuverwenden |
Ein abgespecktes Image ohne Möglichkeit, eine Datei zu hashen | Der Upload sagt „konnte nicht verifiziert werden“ statt eine Übereinstimmung zu behaupten, die niemand geprüft hat |
Eine Box, auf der ein Werkzeug einfach nicht installiert ist | Die Antwort sagt „nicht gemessen“ – nie eine Null, die wie „nichts da“ liest |
Auf der offiziellen MCP-SDK aufgebaut, durchgängig TypeScript, über 2500 Unit-Tests plus eine Live-Suite, die gegen echte Container statt Mocks läuft.
Situation: Ein Deploy ist gerade rausgegangen. Der Server fühlt sich langsam an, und Sie wissen nicht, ob Festplatte, Speicher, Dienste, Container oder Fehler schuld sind.
Frage: „Ist diese Box gesund?“
$ uptime
10:42:17 up 18 days, 3:21, 2 users, load average: 0.42, 0.31, 0.28
$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 ext4 40G 35G 5.0G 87% /
overlay overlay 40G 35G 5.0G 87% /var/lib/docker/overlay2/...
$ free -h
total used free shared buff/cache available
Mem: 7.7Gi 4.9Gi 612Mi 121Mi 2.2Gi 2.5Gi
$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● api-worker.service loaded failed failed API background worker
$ docker ps -a
CONTAINER ID IMAGE STATUS PORTS
8e14d0b41c2a api:latest Up 3 minutes 0.0.0.0:8080->8080/tcp
65b894af2430 worker:latest Exited (1) 2 minutes ago
$ ss -tulpn
Netid State Local Address:Port Process
tcp LISTEN 0.0.0.0:22 users:(("sshd",pid=842,fd=3))
tcp LISTEN 0.0.0.0:8080 users:(("docker-proxy",pid=1942,fd=4))
$ journalctl -p err --since -1h | tail -50
Aug 20 10:39:14 prod api-worker[22104]: database connection timed out
Aug 20 10:39:14 prod systemd[1]: api-worker.service: Failed with result 'exit-code'.Das ist immer noch ein gekürztes Ergebnis. Ein vollständiger Check benötigt weitere Befehle für CPU, Dienstzustände, Containeranzahl und aktuelle Fehler, jeweils mit eigenem Ausgabeformat. Schlimmer noch: Eine Box ohne ss kann so aussehen, als hätte sie null Listener, wenn der Port-Check nie lief.
ssh_snapshot({ "profile": "production" }){
"disk_pct": 87,
"mem_pct": 64,
"cpu_pct": 12,
"load": "0.42 0.31 0.28",
"containers": 7,
"ports": 14,
"services_running": 3,
"recent_errors": 21,
"unavailable": []
}Rohes SSH | Strukturiertes MCP | Ihr Gewinn |
Mehrere Befehle und ASCII-Tabellen | Benannte Felder in einem Ergebnis | Ein Aufruf, benannte Felder und weniger Roundtrips |
Ein fehlendes Werkzeug kann wie leere Ausgabe aussehen |
| Weniger Rätselraten und weniger schlechte Fixes |
Sie sortieren durch Festplatten, Dienste und Fehler | Die Problemsignale sind bereits sichtbar | Schnelleres Debugging |
Ein vollständiges ssh_audit_baseline-Ergebnis kann länger sein als ein paar rohe Befehlsausgaben – etwa 1.077 Tokens gegenüber 765 in unserer Labormessung. Die Ersparnis kommt vom vollständigen Workflow, nicht davon, eine Antwort kürzer zu machen.
In einer echten Troubleshooting-Sitzung reduzierten speziell entwickelte Werkzeuge 49 einzelne Befehlsaufrufe auf 4 MCP-Aufrufe. Jeder weitere Aufruf startet eine weitere Modellrunde mit dem angesammelten Gespräch. Prompt-Caching kann die Kosten für wiederholte Eingaben senken, aber neue Befehle und ihre Ausgabe verbrauchen weiterhin Kontext. Weniger Roundtrips bedeuten weniger Tokens über die Sitzung, weniger wiederholte Analyse und einen schnelleren Weg zur Antwort.
Brauchen Sie das ganze Bild statt nur den Puls? ssh_audit_baseline bündelt System, Festplatte, Speicher, Ports, sshd, fehlgeschlagene Units, Docker, Firewall und Updates. Ergebnisse erscheinen als KRITISCH / WARNUNG / OK; nicht gemessene Abschnitte werden benannt, statt still als Null zu lesen.
Situation: Die API läuft in Timeouts, aber dieselbe Meldung kann in nginx, syslog, journald oder einem Anwendungslog sein, das Sie mit Ihrem normalen Benutzer nicht lesen können.
Frage: „Woher kam dieser Fehler?“
$ grep -i "timeout" /var/log/nginx/error.log
2026/08/20 10:38:54 [error] upstream timed out while reading response header
$ grep -i "timeout" /var/log/syslog
Aug 20 10:39:14 prod api-worker[22104]: database connection timed out
$ grep -i "timeout" /var/log/app/*.log 2>/dev/null
$ journalctl -u api --since "1 hour ago" | grep -i timeout
Aug 20 10:39:14 prod api[22104]: database connection timed out after 30000msDer dritte Befehl sieht sauber aus, aber 2>/dev/null hat auch einen Berechtigungsfehler versteckt. „Nichts gefunden“ und „nichts gelesen“ sehen jetzt identisch aus. Ein vielbeschäftigtes Log kann auch Tausende von Zeilen zurückgeben und den Rest des Vorfalls aus dem Kontext des Agenten drängen.
ssh_log_search({ "profile": "production",
"path": ["/var/log/nginx/error.log", "/var/log/syslog", "/var/log/app/*.log"],
"query": "timeout", "context": 2, "since": "1h" }){
"matches": 34,
"lines": [
{ "file": "/var/log/nginx/error.log", "line": 4821,
"text": "upstream timed out while reading response header", "context": false },
{ "file": "/var/log/nginx/error.log", "line": 4822,
"text": "client closed connection", "context": true }
],
"files_searched": 6,
"files_unreadable": ["/var/log/app/private"],
"files_skipped": 12,
"files_undated": [],
"limited": false,
"truncated": false
}Rohes SSH | Strukturiertes MCP | Ihr Gewinn |
Vier Suchen und vier Ausgaben | Eine Suche über Dateien und Globs | Weniger Tokens und Roundtrips |
Berechtigungsfehler können verschwinden |
| Keine falsche „Logs sind sauber“-Schlussfolgerung |
Ausgabe kann ohne nützliche Obergrenze wachsen |
| Sicherere Entscheidungen aus Teilergebnissen |
since verwendet die Serveruhr, namesOnly: true gibt nur passende Pfade zurück, und ssh_log_tail liest die letzten N Zeilen aus mehreren Logs in einem Aufruf.
Situation: Sie müssen eine nginx-Konfiguration auf einem Live-Server ersetzen. Eine abgebrochene Verbindung, falscher Modus oder ungeprüfter Kopiervorgang könnten den Dienst mit einer kaputten Datei zurücklassen.
Frage: „Kann ich diese Konfiguration ersetzen, ohne eine partielle Datei zu hinterlassen?“
$ sudo sh -c 'cat > /etc/nginx/conf.d/api.conf' <<'EOF'
server {
listen 80;
location / { proxy_pass http://127.0.0.1:8080; }
}
EOF
$ echo $?
0Exit-Code Null sagt, dass die Shell fertig wurde. Es beweist nicht, welche Bytes gelandet sind, und > hat die alte Datei abgeschnitten, bevor das erste Byte der neuen ankam. Wenn die Verbindung mitten im Schreiben abbricht, bleibt der Dienst mit einer partiellen Konfiguration zurück.
ssh_file_write({ "profile": "production",
"files": [{ "path": "/etc/nginx/conf.d/api.conf",
"content": "server {\n listen 80;\n location / { proxy_pass http://127.0.0.1:8080; }\n}\n",
"mode": "644", "sudo": true, "verify": true }] }){
"files": [{ "path": "/etc/nginx/conf.d/api.conf", "written": true,
"verified": "verified", "reason": null, "bytes": 79 }]
}Raw SSH | Strukturiertes MCP | Ihr Vorteil |
Das Ziel wird abgeschnitten, bevor der Kopiervorgang abgeschlossen ist | Eine vollständige temporäre Datei ersetzt es mit einer einzigen Umbenennung | Keine halb geschriebene Konfiguration |
Nur Exit-Code | Bytes und Verifikationsergebnis sind benannt | Sie wissen, was tatsächlich angekommen ist |
Berechtigungen leben im Shell-Text |
| Vorhersehbare Eigentümerschaft und weniger Anführungszeichenfehler |
verified hat drei ehrliche Ergebnisse: verified, unavailable wenn der Server kein Hash-
Werkzeug hat, und skipped wenn die Verifikation nicht angefordert wurde. Für Lesevorgänge
akzeptiert ssh_file_read eine Liste von Pfaden; ssh_file_list behandelt Glob-Muster,
Rekursion, Größen und Modi.
Situation: Ein Deployment ist bereit, aber nginx-Syntax, Dienststatus und aktuelle Fehler müssen alle geprüft werden, bevor der Traffic umgeleitet wird. Ein fehlgeschlagener Check sollte nicht in einem kombinierten Dump verschwinden.
Frage: „Haben alle Preflight-Checks bestanden?“
$ ssh admin@server.example.com 'sudo nginx -t'
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ ssh admin@server.example.com 'sudo systemctl is-active nginx'
active
$ ssh admin@server.example.com 'sudo tail -5 /var/log/nginx/error.log'
2026/08/20 10:38:54 [error] upstream timed out while reading response headerDrei Verbindungen liefern drei unzusammenhängende Ausgaben. Wenn die Befehle mit ; verbunden
werden, meldet die Shell nur den letzten Exit-Code; wenn sie mit && verbunden werden,
verschwinden spätere Checks nach dem ersten Fehler.
ssh_exec({ "profile": "production",
"command": ["nginx -t", "systemctl is-active nginx",
"tail -5 /var/log/nginx/error.log"],
"sudo": true }){
"commands": [
{ "command": "nginx -t", "exit_code": 0, "truncated": false, "clipped_bytes": 0,
"stdout": "", "stderr": "nginx: configuration file /etc/nginx/nginx.conf test is successful\n" },
{ "command": "systemctl is-active nginx", "exit_code": 0, "truncated": false,
"clipped_bytes": 0, "stdout": "active\n", "stderr": "" },
{ "command": "tail -5 /var/log/nginx/error.log", "exit_code": 0, "truncated": false,
"clipped_bytes": 0, "stdout": "2026/08/21 09:14:02 [error] upstream timed out\n", "stderr": "" }
],
"job_id": null
}Raw SSH | Strukturiertes MCP | Ihr Vorteil |
Drei Aufrufe und unzusammenhängende Ausgaben | Eine geordnete Befehlsliste | Weniger Roundtrips |
Eine kombinierte Shell kann Zwischenstatus verbergen | Jeder Befehl behält seinen eigenen | Kein übersehener fehlgeschlagener Check |
|
| Weniger Anführungszeichenfehler |
Die Schutzprüfung für destruktive Befehle prüft die vollständige Liste, bevor der erste Befehl ausgeführt wird. Wenn ein Eintrag abgelehnt wird, werden alle anderen Einträge als nicht ausgeführt markiert und nichts wird an den Server gesendet.
Jeder Befehl trägt sein eigenes stdout und stderr. Ein Befehl, der ausgeführt wurde und
nichts ausgegeben hat, hat einen leeren String; ein Befehl, der nie ausgeführt wurde, hat
überhaupt kein solches Feld, sodass die beiden nicht verwechselt werden können. Ausgabe über
128 KB pro Befehl behält beide Enden — den Kopf für Tabellen, das Ende für Logs — mit einer
Naht dazwischen, die die Menge benennt, und clipped_bytes sagt, wie viel abgeschnitten wurde.
Das Abschneiden erfolgt an Byte-Grenzen und tritt zurück an die Kante eines Zeichens, sodass
eine abgeschnittene Antwort niemals ein Ersatzzeichen trägt.
sudo erreicht den Server ohne Terminal: Wenn das Profil ein Passwort hat, wird es sudo
über die Standardeingabe übergeben. Ein Profil, das sich per Schlüssel authentifiziert, hat
kein Passwort anzubieten, daher funktioniert sudo dort nur, wo es bereits passwortlos
eingerichtet ist — und ein Befehl, der seine eigene Standardeingabe liest, bekommt niemals
das Passwort, das sonst in den Daten landen würde.
Situation: Ein Backup oder eine Migration läuft länger als die Agent-Sitzung. Die Verbindung kann geschlossen werden, aber Sie benötigen später weiterhin ihren Status, ihre Ausgabe und ihren Exit-Code.
Frage: „Überlebt dieser Job das Gespräch?“
$ ssh admin@server.example.com 'pg_dump app | gzip > /srv/backups/app.sql.gz'
client_loop: send disconnect: Broken pipeDas Terminal ist weg. Sie müssen sich jetzt neu verbinden, den Prozess finden, die Zieldatei prüfen und raten, ob das Backup abgeschlossen oder auf halbem Weg gestoppt wurde.
ssh_exec({ "profile": "production",
"command": "pg_dump app | gzip > /srv/backups/app.sql.gz",
"detach": true }){
"commands": [{
"command": "pg_dump app | gzip > /srv/backups/app.sql.gz",
"exit_code": null,
"truncated": false,
"timed_out": false,
"blocked": false,
"blocked_reason": null,
"not_run": false,
"warning": null
}],
"job_id": "mst0f2q1-9ab3c4d5"
}Raw SSH | Strukturiertes MCP | Ihr Vorteil |
Der Job ist an eine SSH-Sitzung gebunden | Der entfernte Job hat eine persistente ID | Sichere Trennungen und Neustarts |
Neuverbinden bedeutet Suchen nach Prozessen und Dateien | Status und Exit-Code haben benannte Zustände | Kein Raten, ob er fertig ist |
Erneutes Lesen der Ausgabe wiederholt alten Text | Die Ausgabe wird ab einem Byte-Offset fortgesetzt | Geringerer Token-Verbrauch bei langen Jobs |
Der Job-Status liegt auf der entfernten Festplatte, nicht im Speicher dieses Servers.
ssh_job_status unterscheidet running, finished und lost; ssh_job_output setzt ab dem
letzten Byte-Offset fort; und ssh_job_kill signalisiert die gesamte Prozessgruppe statt nur
ihrer Shell.
Situation: Ein aktueller OpenSSH-Client versucht SFTP, aber der Router oder das NAS versteht nur das klassische scp-Protokoll. Die Datei muss trotzdem intakt ankommen und ihr Ziel sicher ersetzen.
Frage: „Kann dieses alte Gerät weiterhin eine verifizierte Datei empfangen?“
$ scp app.conf operator@router:/etc/app.conf
subsystem request failed on channel 0
scp: Connection closedDer übliche nächste Schritt ist, sich an das Legacy-Flag zu erinnern, den Kopiervorgang zu wiederholen und dann einen separaten Hash-Befehl auszuführen — falls das Gerät überhaupt ein Hash-Werkzeug hat.
ssh_upload({ "profile": "router", "local_path": "./app.conf",
"remote_path": "/etc/app.conf", "sudo": true,
"mode": "644", "owner": "root:root", "verify": true }){
"files": [{
"path": "/etc/app.conf",
"written": true,
"verified": "verified",
"reason": null,
"bytes": 1284
}]
}Raw SSH | Strukturiertes MCP | Ihr Vorteil |
Moderner SFTP-Modus stoppt beim ersten Fehler | Klassischer scp-Fallback ist automatisch und wird gemerkt | Alte Geräte funktionieren weiter |
Ein erfolgreicher Kopiervorgang beweist keine Integrität | SHA-256-Verifikation hat ein benanntes Ergebnis | Korruption wird nicht mit Erfolg verwechselt |
Direktes Ersetzen kann ein partielles Ziel hinterlassen | Eine temporäre Datei wird nach der Übertragung an Ort und Stelle verschoben | Die Arbeitsdatei überlebt Unterbrechungen |
Wenn das Gerät weder sha256sum noch openssl hat, sagt das Ergebnis unavailable und
benennt den Grund, statt eine falsche Übereinstimmung zu melden. Ganze Verzeichnisse verwenden
recursive: true und verifizieren ihre Hashes in einer Batch.
Die Schutzprüfung läuft lokal, bevor ein Befehl SSH erreicht. Sie trennt Operationen, die wiederhergestellt werden können, von solchen, die den Container zerstören, der die Daten enthält, und sie prüft die Befehlsreihenfolge innerhalb von Ketten und Batches.
Eine sichere Backup-und-Ersetzen-Sequenz:
cp -r /srv/app /srv/app.bak && mv /srv/app /srv/app-old && rm -rf /srv/appDieselben Operationen in der falschen Reihenfolge:
rm -rf /srv/app && cp -r /srv/app /srv/app.bak && mv /srv/app /srv/app-old
# REFUSED before the first command runsDie Shell würde das Verzeichnis löschen und erst dann feststellen, dass die Backup-Quelle
verschwunden ist. Die Schutzprüfung sieht, dass spätere Schritte ein Ziel lesen, das bereits
durch einen früheren Schritt zerstört wurde, also bleibt der gesamte Aufruf auf Ihrer Maschine.
Dieselbe Prüfung erfasst dropdb app && pg_dump app > backup.sql.
Verweigert — der Container selbst | Nur gewarnt — sein Inhalt |
|
|
|
|
| Bearbeiten eines einzelnen Jobs |
|
|
|
|
docker compose down -v wird verweigert, weil -v benannte Docker-Volumes entfernt,
einschließlich eines Datenbank-Volumes. Ohne -v wird das Stoppen der Dienste nicht als
dieselbe irreversible Aktion behandelt.
Rekursives Löschen des Dateisystem-Roots, eines Home-Verzeichnisses oder von Systembäumen wie
/etc, /var und /usr wird ebenfalls verweigert, auch wenn ein Symlink dorthin führt. Ein
unaufgelöstes Ziel wie rm -rf "$DIR"/* wird ebenfalls verweigert: „konnte nicht geprüft
werden“ wird nicht als „sicher“ behandelt.
Nichts ist dauerhaft verboten. Fügen Sie # CONFIRMED-DESTRUCTIVE zu einem geprüften Befehl
hinzu und er wird durchgelassen. Wenn die Schutzprüfung einen Eintrag in einer Batch ablehnt,
stoppt die gesamte Batch vor der Ausführung, sodass der Server niemals nach einer halb
ausgeführten Operation zurückgelassen wird.
Die Schutzprüfung arbeitet innerhalb eines einzelnen Aufrufs. Sie kann ein Löschen in einer Aufrufung nicht mit einem Lesen in der nächsten verbinden oder über Werkzeuge nachdenken, die sie nicht erkennt. Sie ist ein Sicherheitsgurt, keine Policy-Engine: Wiederherstellbare Operationen bleiben Ihre Entscheidung. Pfadbeschränkungen und Anführungszeichenregeln sind in docs/security.md dokumentiert.
18 Werkzeuge. Vollständige Parameter und Beispiele finden Sie in docs/tools.md.
Standard-MCP-Annotationen teilen Clients mit, welche Werkzeuge schreibgeschützt, destruktiv, idempotent oder offen sind. Siehe die vollständige Tabelle.
Werkzeug | Was es tut |
| Einen Befehl oder eine Batch ausführen, mit der Schutzprüfung für destruktive Befehle und optionalem Detach |
| Eine oder mehrere Dateien lesen, Text oder Binär |
| Dateien mit atomarer Umbenennung und optionaler SHA-256-Verifikation schreiben |
| Ein Verzeichnis auflisten, mit optionalem Glob und Rekursion |
Werkzeug | Was es tut |
| Status eines Hintergrundjobs: running, finished oder lost |
| Gesammelte Ausgabe ab einem Byte-Offset lesen |
| Jobs auflisten, abgeschlossene nach Ablauf ihrer TTL entfernen |
| Die gesamte Prozessgruppe eines Jobs signalisieren |
Werkzeug | Was es tut |
| Letzte N Zeilen eines oder mehrerer Logs, Glob unterstützt |
| Mustersuche über Logs |
| Einmaliger Gesundheits-Snapshot: Dienste, Ressourcen, Docker, Netzwerk, Fehler |
| Transportsteuerung: stats, reload, test, list, close |
Binärsichere Übertragungen mit Integritätsprüfungen. Details in docs/transfer.md.
Werkzeug | Was es tut |
| Eine Datei oder ein Verzeichnis hochladen |
| Eine Datei oder ein Verzeichnis herunterladen |
Für Binärdateien und große Dateien verwenden Sie
ssh_upload/ssh_download— Base64- Chunks und Heredocs sind nicht binärsicher oder atomar.
Schreibgeschützt und in einem einzigen Roundtrip gebündelt. Details in docs/audit.md.
Werkzeug | Was es tut |
| System, Festplatte, Speicher, Netzwerk, ssh, Dienste, Docker, Firewall, Updates |
| Zertifikatsablauf, SAN, Kette und Erneuerungs-Hook für eine Domain |
| Wohin die Festplatte ging: |
|
|
Windows verwendet den Kompatibilitätsmodus automatisch. Wenn Verbindungs-Multiplexing nicht verfügbar ist, wechselt der Server auf eine Verbindung pro Befehl. Dieselben Tools bleiben über schlüsselbasiertes SSH verfügbar – keine separate Einrichtung oder Windows-spezifische Implementierung erforderlich.
Der Schutz vor destruktiven Befehlen wird in Schutz vor destruktiven Befehlen für KI-Agenten behandelt.
Führen Sie zuerst das Paket aus In 30 Sekunden installieren aus, und erstellen Sie dann eine Profildatei.
Legen Sie sie dort ab, wo Sie möchten – neben der eigenen Konfiguration Ihres Agenten ist die übliche Wahl. Die Beispiele unten verwenden ~/.claude/ssh-profiles.json; für andere Agenten tauschen Sie das Verzeichnis aus (~/.codex/, ~/.qwen/, ~/.config/opencode/):
{
"profiles": {
"production": {
"host": "server.example.com",
"username": "admin",
"port": 22,
"privateKeyPath": "~/.ssh/your_private_key"
}
}
}Ein SSH-Profil explizit auswählen
Es gibt kein Profil, auf das der Server zurückfällt: Jedes ist eine andere Maschine, und ein Befehl, der an die falsche Maschine gesendet wird, kann durch eine Fehlermeldung im Nachhinein nicht rückgängig gemacht werden. Fragen Sie ohne Namen, und die Antwort listet die Namen zur Auswahl auf:
ssh_exec({ command: "uptime" })
→ No profile specified. Name one explicitly: productionEin Profil, das der Server nicht für SSH verwenden kann – kein host, kein username oder mode: "local" – wird ohne Beschwerde übersprungen, und Felder, die er nicht erkennt, werden unangetastet gelassen, sodass die Datei mit anderen Tools geteilt werden kann. Ein Profil mit einem defekten Feld ist ein anderer Fall: Es wird zusammen mit dem Feld und dem Wert benannt, und seine gesunden Nachbarn funktionieren weiter.
Jedes Profil akzeptiert optional einen pathSecurity-Block, der Pfade, die Datei-Tools berühren dürfen, auf eine Whitelist oder Blacklist setzt – siehe docs/security.md.
Schlüssel bevorzugen. Wenn ein Passwort oder eine Passphrase für verschlüsselte Schlüssel unvermeidbar ist, bewahren Sie sie in einer separaten Secrets-Datei auf, niemals im Profil selbst:
{
"secretsFile": "~/.config/ssh-mcp/secrets.json",
"profiles": {
"production": {
"host": "server.example.com",
"username": "admin"
}
}
}Die Secrets-Datei ist nach Profilname verschlüsselt – siehe secrets.json.example:
{
"production": { "password": "..." }
}Die Secrets-Datei darf nur von Ihnen lesbar sein (chmod 600). Relative Pfade werden von der Profildatei aus aufgelöst; Secrets bleiben aus argv heraus und werden in Protokollen maskiert. Siehe Sicherheit der Anmeldedaten.
Wählen Sie den Client, den Sie verwenden, und zeigen Sie auf dieselbe Profildatei.
Claude Code
Ein Befehl; -s user macht den Server in jedem Projekt verfügbar:
claude mcp add ssh -s user \
-e SSH_PROFILES_FILE="$HOME/.claude/ssh-profiles.json" \
-- npx -y @hypnosis/ssh-mcp-serverCodex CLI
codex mcp add ssh \
--env SSH_PROFILES_FILE="$HOME/.codex/ssh-profiles.json" \
-- npx -y @hypnosis/ssh-mcp-serveropencode
Fügen Sie es in ~/.config/opencode/opencode.json ein:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"ssh": {
"type": "local",
"command": ["npx", "-y", "@hypnosis/ssh-mcp-server"],
"enabled": true,
"environment": {
"SSH_PROFILES_FILE": "~/.config/opencode/ssh-profiles.json"
}
}
}
}Qwen Code
Ein Befehl, derselbe wie die anderen:
qwen mcp add ssh \
-e SSH_PROFILES_FILE="$HOME/.qwen/ssh-profiles.json" \
npx -y @hypnosis/ssh-mcp-serverAndere MCP-Clients
Gemini CLI, Hermes, Cline, ein Editor-Plugin oder Ihr eigener Agent funktionieren auf dieselbe Weise. Alles, was sie brauchen, ist ein auszuführender Befehl und eine Umgebungsvariable.
Starten Sie den Client neu und führen Sie dann ssh_monitor({ action: "list" }) aus, um zu bestätigen, dass das Profil geladen wurde.
Variable | Was sie tut | Standard |
| Pfad zur Profile-JSON – erforderlich | — |
|
|
|
| Fallback, nur verwendet, wenn |
|
| Zeitstempel in Protokollzeilen |
|
| Sekunden, die eine gemeinsame Verbindung nach dem letzten Befehl aktiv bleibt; |
|
| Wo Control-Sockets liegen |
|
| Profil-Cache-TTL, ms |
|
| Profildatei neu laden, wenn sie sich ändert |
|
Die gemeinsame Verbindung überlebt diesen Prozess absichtlich: Sie beim Beenden zu schließen, würde den Kanal abschneiden, den ein anderes Fenster auf derselben Maschine verwendet.
Abbruch: Das Schließen von SSH kann den Remote-Befehl weiterlaufen lassen. Verwenden Sie getrennte Jobs, wenn Kontrolle wichtig ist.
Atomare Schreibvorgänge: BSD und macOS können Dateisystem-übergreifende Umbenennungen nicht vorab prüfen.
Vollständiger Testlauf gegen macOS-SSH-Hosts
End-to-End-Kompatibilitätslauf auf Windows
Multi-Host-Audits – Gesundheitszustand über mehrere SSH-Profile in einem Aufruf vergleichen
Profile aus der vorhandenen ~/.ssh/config importieren
Fortsetzbare Übertragungen für große Dateien und instabile Verbindungen
Remote-Operations-Zeitachse – Befehle, Übertragungen und Schutzentscheidungen in einem Audit-Trail
Fertige SSH-Fehlerbehebungs-Playbooks
Antworten, die das Modell erreichen – ERLEDIGT: Befehlsausgabe, übereinstimmende Protokollzeilen, Maschinennamen und Snapshot-Abschnitte reisen in den Feldern, nicht nur im Text
Kleinere MCP-Tool-Schemas – ERLEDIGT: Die Tool-Liste wurde um 10 % leichter, und ein getrennter Job zeigt jetzt die letzten Zeilen, die er geschrieben hat, anstatt blind abgefragt zu werden
npm install
npm run build # tsc
npx tsc --noEmit # types, plus dead declarations
npm run test:unit # unit tests
npm run lab:up # start the two test containers
npm run test:live # live suite against those containersDie Live-Suite läuft gegen echte Container – einen BusyBox, einen coreutils – weil die beiden sich leise widersprechen, und ein Mock stimmt mit dem überein, der es geschrieben hat. Siehe docs/architecture.md für das Layout.
Wenn Ihnen das Tool gefällt, geben Sie ihm einen Stern auf GitHub – das hilft mehr Menschen, das Projekt zu entdecken.
Issues und Pull-Requests sind willkommen unter github.com/hypnosis/ssh-mcp-server.
MIT – siehe LICENSE.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hypnosis/ssh-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server