Benutzerhandbuch Gespeicherte Sitzungen

Gespeicherte Sitzungen

Bestätigungen und Fragen (Sitzungen, Ordner, Tunnel und Makros löschen, einen neuen Ordner benennen, die SFTP-Aktionen) öffnen sich in PlexusTerms eigenen Dialogen: Enter übernimmt einen eingegebenen Namen und drückt die fokussierte Schaltfläche einer Bestätigung, Escape bricht ab, und Abbrechen hat den Fokus, wenn die Aktion etwas löscht. Abbrechen führt die Aktion nie aus.

Das Panel Sitzungen links bewahrt SSH-, serielle, Telnet-, Mosh- und lokale Terminal-Sitzungen in Ordnern auf (Pfade im Stil Prod/DB). Verwende Neu / Ordner oder die Aktionen, die beim Überfahren eines Ordners erscheinen; doppelklicke auf eine Sitzung (oder drück Enter), um dich zu verbinden, und das Suchfeld filtert nach Name, Host, seriellem Gerät oder Shell. Rechtsklick auf eine Sitzung bietet Verbinden, Bearbeiten…, Duplizieren (eine Kopie namens „ (Kopie)“ direkt daneben; ein im Schlüsselbund gespeichertes Passwort wird nicht kopiert) und Löschen. Rechtsklick auf einen Ordner bietet Neue Sitzung hier…, Neuer Ordner hier…, Alle verbinden (jede Sitzung darin und in seinen Unterordnern, jede in einem eigenen Tab) und Ordner löschen. Solange die Sitzungsdatei nicht gelesen werden kann, bieten die Menüs nur das Verbinden an. Der Bearbeitungsdialog hat eine Auswahl Sitzungstyp (SSH, Seriell, Telnet, Mosh oder Lokales Terminal), die die passenden Felder zeigt. Serielle Sitzungen speichern den Gerätepfad und die Leitungseinstellungen, Telnet-Sitzungen den Host und den Port; beide öffnen direkt, ohne Passwort. Mosh-Sitzungen nennen die gespeicherte SSH-Sitzung, mit der sie sich anmelden, und einen optionalen Serverbefehl. Lokale Terminal-Sitzungen speichern eine Shell (die Systemstandard-Shell, eine erkannte oder ein beliebiges Programm, wie in den Terminal-Einstellungen), ihre Argumente und ein Startverzeichnis (~ ist dein Benutzerverzeichnis; leer startet ebenfalls dort), sodass eine PowerShell, eine WSL-Distribution oder ein Projektordner nur einen Doppelklick entfernt ist; ihre Tabs tragen den Namen der Shell.

Sitzungen werden in ~/.config/dev.plexusterm.app/sessions.json gespeichert (atomar geschrieben, Modus 0600); jeder Eintrag hat einen kind (ssh, serial, telnet, mosh oder local), und Einträge früherer Versionen ohne dieses Feld werden als SSH-Sitzungen geladen. Die Datei enthält nie Passwörter oder Passphrasen von Schlüsseln (siehe Gespeicherte Passwörter). Versionen vor den lokalen Terminal-Sitzungen können eine Datei, die eine solche enthält, nicht lesen und zeigen daher statt der Sitzungen den unten beschriebenen Fehler. Kann die Datei nicht gelesen werden, zeigt das Panel den Fehler und deaktiviert das Bearbeiten, damit die Datei nie überschrieben wird.

Gespeicherte Passwörter

Sitzungen mit gespeichertem Passwort (Terminal-Tabs, Mosh und Tunnel) verbinden sich zuerst: PlexusTerm probiert deine Schlüssel (siehe SSH-Sitzungen), dann das im Schlüsselbund gespeicherte Passwort, und fragt nur dann nach dem Passwort, wenn der Server es weiterhin braucht. Diese Abfrage hat ein Kontrollkästchen Passwort im Systemschlüsselbund speichern, standardmäßig nicht angehakt. Schnellverbindungen nehmen das Passwort im Verbindungsdialog entgegen und speichern es nie. Installieren im SSH-Schlüsselgenerator fragt weiterhin vor dem Verbinden.

  • Passwörter werden nur im Systemschlüsselbund über die Secret-Service-API (GNOME Keyring, KWallet) aufbewahrt, unter dem Dienst dev.plexusterm.app mit der Sitzungs-ID als Konto und der Bezeichnung PlexusTerm: user@host:port. Sie werden nie in sessions.json oder tunnels.json geschrieben.
  • Ein Passwort wird erst nach einer erfolgreichen Anmeldung gespeichert. Spätere Verbindungen lesen es im Backend; es wird nie an die Benutzeroberfläche zurückgegeben.
  • Ein gespeichertes Passwort ist an das user@host:port gebunden, für das es eingegeben wurde, und wird nur dorthin gesendet. Ändert man Host, Port oder Benutzernamen einer Sitzung (oder stellt sie von Passwort-Authentifizierung um), wird das gespeicherte Passwort vergessen; Passwörter früherer Versionen, die keine solche Bindung haben, werden einmal erneut abgefragt.
  • Kann der Schlüsselbund das Passwort nicht speichern oder löschen (zum Beispiel weil er gesperrt ist und nicht innerhalb von 10 Sekunden antwortet), wird die Verbindung trotzdem geöffnet und eine Warnung angezeigt: eine gelbe Zeile im Terminal-Tab oder ein Hinweis unter dem Tunnel.
  • Wird das gespeicherte Passwort abgelehnt, erscheint die Abfrage mit angehaktem Kontrollkästchen: Eine erfolgreiche Anmeldung ersetzt es, und das Abwählen des Kontrollkästchens löscht es. Ist kein brauchbares Passwort gespeichert, erscheint die Abfrage nicht angehakt, wie bei einer ersten Anmeldung.
  • Gespeichertes Passwort vergessen im Bearbeitungsdialog der Sitzung löscht es; das Löschen einer Sitzung oder eines Ordners, der sie enthält, löscht es ebenfalls.
  • Ohne Secret Service ist das Kontrollkästchen deaktiviert, und Passwörter werden bei jeder Verbindung abgefragt.
  • Passphrasen von Schlüsseln werden nie gespeichert.

Jump-Hosts

Eine gespeicherte SSH-Sitzung kann ihren Server über bis zu 3 Jump-Hosts (Bastionen) erreichen, wie ssh -J. Im Bearbeitungsdialog der Sitzung listet Jump-Hosts andere gespeicherte SSH-Sitzungen in der Reihenfolge, in der sie durchlaufen werden: Füge sie aus der Liste hinzu, verschiebe sie nach oben oder unten oder entferne sie. Schnellverbindungen haben keine Jump-Hosts.

  • PlexusTerm meldet sich am ersten Jump-Host an, öffnet von dort eine weitergeleitete Verbindung zu Adresse und Port des nächsten Hosts, meldet sich dort an und so weiter bis zum eigenen Server der Sitzung. Jeder Host wird vom vorherigen aus erreicht, daher muss seine Adresse dort sinnvoll sein (z. B. eine private IP hinter der Bastion).
  • Jeder Host wird mit seiner eigenen Adresse und seinem eigenen Port gegen ~/.ssh/known_hosts geprüft; ein unbekannter Jump-Host zeigt die Vertrauensabfrage mit seinem Namen („bastion – Jump-Host 1 von 2“).
  • Jeder Host meldet sich mit der Methode seiner eigenen gespeicherten Sitzung an (Schlüssel, Agent oder Passwort). Hosts mit Passwort probieren zuerst deine Schlüssel, dann das im Schlüsselbund gespeicherte Passwort; ein Host, der weiterhin ein Passwort braucht, wird beim Verbinden abgefragt, einer nach dem anderen („Passwort für bastion – Jump-Host 1 von 2“), jede Abfrage mit ihrem eigenen Kontrollkästchen Passwort im Systemschlüsselbund speichern.
  • Hat ein Jump-Host eigene Jump-Hosts, werden diese zuerst durchlaufen. Eine Sitzung kann nicht ihr eigener Jump-Host sein, und Ketten mit Zyklen, wiederholten Sitzungen, insgesamt mehr als 3 Hosts oder gelöschten bzw. Nicht-SSH-Jump-Sitzungen werden mit einem Fehler abgelehnt.
  • Fehler nennen den Host, der fehlgeschlagen ist, z. B. via bastion (jump host 1): authentication failed.
  • Der SFTP-Browser des Tabs verwendet dieselbe Verbindung, und SSH-Tunnel, deren Sitzung Jump-Hosts hat, laufen ebenfalls über diese. Das Schließen des Tabs (oder das Stoppen des Tunnels) schließt jede Verbindung der Kette.
  • Das Löschen einer Sitzung, die andere Sitzungen als Jump-Host verwenden, fragt nach einer Bestätigung und entfernt sie aus deren Jump-Hosts.

Sitzungen aus einer .ini-Datei importieren

Importieren → Aus einer .ini-Datei… im Panel Sitzungen liest eine Sitzungs-.ini-Datei mit [Bookmarks]-Abschnitten (UTF-8 oder die Codepage Windows-1252, in der diese Dateien oft geschrieben sind) und zeigt eine Vorschau, bevor etwas gespeichert wird:

  • SSH-Sitzungen aus den Abschnitten [Bookmarks] / [Bookmarks_N] werden mit Host, Port (22, wenn er fehlt oder ungültig ist) und Benutzernamen importiert, Telnet-Sitzungen mit Host und Port (23, wenn er fehlt oder ungültig ist), unter einem Ordner Imported, der den in der Datei gespeicherten Ordnerpfad beibehält.
  • Importierte SSH-Sitzungen verwenden Passwort-Authentifizierung; ändere das später mit Bearbeiten. Pfade zu privaten Schlüsseln werden nicht importiert.
  • Andere Sitzungstypen (RDP, VNC, Serial, WSL, FTP, ...), Einträge ohne Host und nicht erkannte Zeilen werden übersprungen und in der Vorschau pro Typ gezählt.
  • Bereits gespeicherte Sitzungen mit gleichem Typ, Ordner, Namen, Host, Port und Benutzernamen werden als Duplikate übersprungen.
  • Passwörter werden nie importiert: Der Abschnitt [Passwords] und alle anderen Abschnitte werden nicht gelesen.

Hosts aus ~/.ssh/config importieren

Importieren → Aus ~/.ssh/config liest die OpenSSH-Clientkonfiguration deines Benutzerordners (~/.ssh/config, auch unter Windows) und zeigt dieselbe Vorschau:

  • Jeder konkrete Host-Alias wird zu einer SSH-Sitzung mit seinem Namen, unter Imported/SSH config. Platzhaltermuster (*, ?) und negierte Muster (!) werden nicht als Sitzungen importiert, aber ihre Optionen gelten für die Hosts, auf die sie passen, ebenso wie Optionen vor dem ersten Host; wie bei ssh gewinnt der erste Wert jeder Option.
  • HostName (der Alias, wenn er fehlt; %h wird durch den Alias ersetzt), User (leer, wenn er fehlt), Port (22, wenn er fehlt oder ungültig ist) und das erste IdentityFile werden gelesen. Ein Host mit IdentityFile verwendet diesen privaten Schlüssel (%d wird zu ~); einer ohne verwendet Passwort-Authentifizierung.
  • ProxyJump-Sprünge, die Hosts derselben Datei sind, werden zu den Jump-Hosts der Sitzung (höchstens 3). Andere Sprünge wie user@gateway:2222 und ProxyCommand werden nicht unterstützt: Der Host wird ohne sie importiert und in der Vorschau gezählt.
  • Include-Zeilen und Match-Blöcke werden nicht verfolgt und in der Vorschau gezählt. Jede andere Option wird ignoriert.
  • Bereits auf dieselbe Weise importierte Hosts werden als Duplikate übersprungen, sodass ein erneuter Import nur neue Hosts hinzufügt.