Speichere deine SSH-Verbindungen,
starte KI-Agenten auf der Remote-Maschine

Ja. AgentsRoom arbeitet als SSH-Verbindungsmanager : speichere ein Profil pro Remote-Server mit Host, Port, Benutzer und Auth-Methode, benenne sie und wähle das, das du brauchst. Dein VPS, deine Staging-Maschine und dein geteilter Dev-Server stehen alle in derselben Liste.

Beides. Eine Verbindung kann sich per SSH-Schlüssel authentifizieren, indem sie auf deine private Schlüsseldatei zeigt, oder per Passwort. AgentsRoom agiert als Standard-SSH-Client, du nutzt also die Methode, die dein Server akzeptiert.

Ja. Genau darum geht es bei dieser Funktion. Öffne eine gespeicherte SSH-Verbindung und starte dann Claude Code, Codex, Antigravity CLI oder einen anderen Agenten im entfernten Terminal. Der Agent läuft auf der entfernten Maschine und arbeitet an den dort liegenden Dateien, nicht auf deinem Laptop.

In deinen lokalen App-Daten auf deiner eigenen Maschine. Schlüssel, Passwörter und Verbindungsdetails werden nie in das Projekt-Repository geschrieben, also fügt die Verbindung zu einem Server keine Konfigurationsdateien oder Secrets zu irgendetwas hinzu, das ein Teamkollege klonen könnte.

Nein. AgentsRoom enthält ein integriertes Terminal über SSH, also sind dein Verbindungsmanager, dein Terminal und deine KI-Agenten in einer App. Du kannst deine gewohnten SSH-Tools behalten, wenn du willst, aber du brauchst keinen zweiten Client offen, nur um den Server zu erreichen.

Ja, über AgentsRoom MCP. Agenten rufen ssh_list auf, um die für das aktuelle Projekt gespeicherten Server (plus deine globalen) zu sehen, und dann ssh_connect, um einen davon als Terminal-Tab zu öffnen. So gibt man einem KI-Agenten SSH-Zugriff: ohne handgeschriebenes ssh-Kommando und ohne Zugangsdaten im Prompt.

Nie. Die MCP-Tools geben ausschließlich Verbindungs-Metadaten preis (Name, Host, Port, Benutzer, Authentifizierungsart). Das Passwort bzw. die Passphrase bleibt im Schlüsselbund deiner Maschine verschlüsselt und wird von AgentsRoom ins Terminal eingespeist, nachdem der Agent die Verbindung per id angefragt hat.

Ja. AgentsRoom liest die Host-Blöcke in ~/.ssh/config und macht daraus gespeicherte Verbindungen, samt der Identity-Datei, die jeder Block deklariert. Alles, was OpenSSH selbst auflöst, funktioniert weiter, ein ProxyJump über einen Bastion-Host eingeschlossen, denn AgentsRoom verbindet sich über den Alias und lässt OpenSSH den Block anwenden, statt ihn nachzubauen.

Ja, mit einer AWS SSM Verbindung. AgentsRoom öffnet die Session mit aws ssm start-session, autorisiert durch das AWS-Profil, das auf deiner Maschine schon konfiguriert ist. Es gibt kein Passwort und keinen Schlüssel, den die App speichern müsste, und die Instanz kann für eingehendes SSH geschlossen bleiben.

Er kann eine vorschlagen, niemals eine speichern. ssh_connection_new öffnet das Anlageformular, vorausgefüllt mit Host, Port und Benutzer, die der Agent in deinem Deploy-Skript oder deiner Dokumentation gefunden hat, und du prüfst es, tippst die Zugangsdaten und speicherst. Vorher wird nichts abgelegt, denn eine Verbindung, die ein Agent anlegen könnte, ohne dass du es siehst, wäre eine Hintertür. Existiert der Host schon in deiner ~/.ssh/config, ist der Import der bessere Weg: Er behält den Alias, deine Bastion-Hosts und deine Schlüssel funktionieren also weiter.

Ja, auf zwei Wegen. Windows Server liefert OpenSSH seit 2019 mit, ein Windows-Rechner wird also wie jede andere SSH-Verbindung gespeichert, und eine Remote-Shell-Option an der Verbindung lässt das Terminal auf einem PowerShell-Prompt (Windows PowerShell oder PowerShell 7) statt in cmd.exe landen. Für einen Host, der nur WinRM spricht, oder für den PowerShell-Endpunkt eines On-Prem-Exchange-Servers speicherst du stattdessen eine WinRM-Verbindung: NTLM oder Kerberos, mit von Hand eingetragenem Domänencontroller und Server-IP, wenn dein Arbeitsplatz nicht in die Domäne aufgenommen ist. Beides funktioniert, egal ob du AgentsRoom unter macOS, Windows oder Linux nutzt; der WinRM-Weg installiert einmalig ein kleines Python-Paket in einem privaten Ordner, der AgentsRoom gehört.

Ja. Der Dialog Neues Projekt fragt, wo das Projekt liegt: Dieser Computer oder Entfernter Server (SSH). Wähle eine gespeicherte Verbindung und den Pfad des Repositorys auf dem Host, und das Projekt öffnet sich von dort: Seine Agenten starten auf dem Server, in diesem Verzeichnis, auf den Dateien, die dort liegen, und nichts wird auf deinen Laptop kopiert. Die Karte jeder gespeicherten Verbindung trägt außerdem einen Button Ein Projekt auf diesem Server öffnen, der denselben Dialog mit vorausgewählter Verbindung öffnet, und ein Projekt deines Kontos, das auf diesem Rechner keinen Ordner hat, lässt sich auf die gleiche Weise auf einem Server öffnen. Rolle, Persona, System-Prompt, Berechtigungsmodus, Skills, Statusverfolgung und das für den Agenten gewählte Codex-Konto reisen mit dem Agenten (das Konto wird vor dem Start auf den Host kopiert, eine Einstellung pro Verbindung, die sich abschalten lässt); die AgentsRoom-MCP-Tools (Backlog, Projektgedächtnis, Skills, Dev-Befehle, Nachrichten zwischen Agenten) reisen ebenfalls mit, werden vor jedem Start auf dem Host installiert und über einen umgekehrten SSH-Tunnel an diesen Computer zurückgebunden, eine standardmäßig aktive Einstellung pro Verbindung, die Node auf dem Host braucht; eine auf dem Host fehlende CLI wird auf dem Host installiert, über SSH, aus dem Banner des Agenten-Terminals; und ein Team-Run funktioniert auf einem Projekt, das auf einem Server geöffnet ist. Ein Ticket mit angehaktem In einem separaten Worktree programmieren bekommt seinen Worktree ebenfalls auf dem Server, unter .worktrees/ des entfernten Checkouts: Der Agent startet darin; das Einzige, was noch einen lokalen Checkout verlangt, ist die Option Eigener Checkout eines Team-Schritts. Auch der eingebettete Browser folgt dem Agenten, wenn der Agent Browserzugriff hat. Umgebungsvariablen und die Kontoprofile der anderen Anbieter bleiben an diesen Computer gebunden, und das Agentenformular weist darauf hin, solange das Projekt auf einem Server liegt. Eine Voraussetzung: Der Host muss mit einer Linux- oder macOS-Shell antworten. Ein per SSH erreichter Windows-Server liefert Terminal und PowerShell, aber noch kein Remote-Projekt; leg WSL als Standard-Shell seines OpenSSH-Dienstes fest, und er verhält sich wie ein Linux-Host.