Guide d'utilisation Sessions enregistrées

Sessions enregistrées

Les confirmations et les questions (suppression de sessions, de dossiers, de tunnels et de macros, nom d'un nouveau dossier, actions SFTP) s'ouvrent dans les boîtes de dialogue propres à PlexusTerm : Enter valide un nom saisi et appuie sur le bouton actif d'une confirmation, Escape annule, et Annuler a le focus lorsque l'action supprime quelque chose. Annuler n'effectue jamais l'action.

Le panneau Sessions à gauche conserve les sessions SSH, série, Telnet, Mosh et de terminal local dans des dossiers (chemins du type Prod/DB). Utilisez Nouvelle / Dossier ou les actions qui apparaissent au survol d'un dossier ; double-cliquez sur une session (ou appuyez sur Enter) pour vous connecter, et le champ de recherche filtre par nom, hôte, périphérique série ou shell. Cliquez avec le bouton droit sur une session pour Se connecter, Modifier…, Dupliquer (une copie nommée « (copie) » placée à côté ; un mot de passe enregistré dans le trousseau n'est pas copié) et Supprimer. Cliquez avec le bouton droit sur un dossier pour Nouvelle session ici…, Nouveau dossier ici…, Tout connecter (chaque session qu'il contient et celles de ses sous-dossiers, chacune dans son propre onglet) et Supprimer le dossier. Tant que le fichier des sessions ne peut pas être lu, les menus ne proposent que la connexion. La boîte de dialogue de modification comporte un sélecteur Type de session (SSH, Série, Telnet, Mosh ou Terminal local) qui affiche les champs correspondants. Les sessions série conservent le chemin du périphérique et les paramètres de ligne, et les sessions Telnet l'hôte et le port ; les deux s'ouvrent directement, sans aucun mot de passe. Les sessions Mosh indiquent la session SSH enregistrée avec laquelle elles se connectent et une commande de serveur facultative. Les sessions de terminal local conservent un shell (celui par défaut du système, un shell détecté ou n'importe quel programme, comme dans Paramètres du terminal), ses arguments et un Dossier de départ (~ est votre dossier personnel ; vide démarre aussi là), de sorte qu'un PowerShell, une distribution WSL ou un dossier de projet est à un double-clic ; leurs onglets portent le nom du shell.

Les sessions sont stockées dans ~/.config/dev.plexusterm.app/sessions.json (écrit de manière atomique, mode 0600) ; chaque entrée a un kind (ssh, serial, telnet, mosh ou local), et les entrées écrites sans lui par des versions antérieures sont chargées comme sessions SSH. Le fichier ne contient jamais de mots de passe ni de phrases secrètes de clés (voir Mots de passe enregistrés). Les versions antérieures aux sessions de terminal local ne peuvent pas lire un fichier qui en contient une ; elles affichent donc l'erreur ci-dessous au lieu des sessions. Si le fichier ne peut pas être lu, le panneau affiche l'erreur et désactive la modification afin que le fichier ne soit jamais écrasé.

Mots de passe enregistrés

Les sessions à mot de passe enregistrées (onglets de terminal, Mosh et tunnels) se connectent d'abord : PlexusTerm essaie vos clés (voir Sessions SSH), puis le mot de passe enregistré dans le trousseau, et ne demande le mot de passe que lorsque le serveur en a encore besoin. Cette demande comporte une case Enregistrer le mot de passe dans le trousseau du système, décochée par défaut. Les sessions de connexion rapide reçoivent le mot de passe dans la boîte de dialogue de connexion et ne l'enregistrent jamais. Installer dans le générateur de clés SSH demande toujours avant de se connecter.

  • Les mots de passe ne sont conservés que dans le trousseau du système via l'API Secret Service (GNOME Keyring, KWallet), sous le service dev.plexusterm.app avec l'identifiant de la session comme compte et le libellé PlexusTerm: user@host:port. Ils ne sont jamais écrits dans sessions.json ni dans tunnels.json.
  • Un mot de passe n'est enregistré qu'après une connexion réussie. Les connexions suivantes le lisent dans le backend ; il n'est jamais renvoyé à l'interface.
  • Un mot de passe enregistré est lié au user@host:port pour lequel il a été saisi et n'est jamais envoyé ailleurs. Modifier l'hôte, le port ou le nom d'utilisateur d'une session (ou cesser d'utiliser l'authentification par mot de passe) oublie le mot de passe enregistré ; les mots de passe enregistrés par des versions antérieures, qui n'ont pas cette liaison, sont redemandés une fois.
  • Si le trousseau ne peut pas enregistrer ou supprimer le mot de passe (par exemple parce qu'il est verrouillé et ne répond pas dans les 10 secondes), la connexion s'ouvre quand même et un avertissement s'affiche : une ligne jaune dans l'onglet du terminal, ou une note sous le tunnel.
  • Si le mot de passe enregistré est refusé, la demande apparaît avec la case cochée : une connexion réussie le remplace, et décocher la case le supprime. Si aucun mot de passe utilisable n'est enregistré, la demande apparaît décochée, comme lors d'une première connexion.
  • Oublier le mot de passe enregistré dans la boîte de dialogue de modification de la session le supprime ; supprimer une session, ou un dossier qui la contient, le supprime aussi.
  • Sans Secret Service, la case est désactivée et les mots de passe sont demandés à chaque connexion.
  • Les phrases secrètes des clés ne sont jamais enregistrées.

Hôtes de rebond

Une session SSH enregistrée peut atteindre son serveur en passant par 3 hôtes de rebond (bastions) au maximum, comme ssh -J. Dans la boîte de dialogue de modification de la session, Hôtes de rebond liste d'autres sessions SSH enregistrées dans l'ordre où elles sont traversées : ajoutez-les depuis la liste, montez-les ou descendez-les, ou retirez-les. Les sessions de connexion rapide n'ont pas d'hôtes de rebond.

  • PlexusTerm se connecte au premier hôte de rebond, ouvre depuis celui-ci une connexion redirigée vers l'adresse et le port de l'hôte suivant, se connecte à celui-ci, et ainsi de suite jusqu'au serveur de la session. Chaque hôte est atteint depuis le précédent ; son adresse doit donc avoir un sens à cet endroit (par exemple une IP privée derrière le bastion).
  • Chaque hôte est vérifié par rapport à ~/.ssh/known_hosts avec sa propre adresse et son propre port ; un hôte de rebond inconnu affiche la demande de confiance qui le nomme (« bastion — hôte de rebond 1 sur 2 »).
  • Chaque hôte se connecte avec la méthode de sa propre session enregistrée (clé, agent ou mot de passe). Les hôtes à mot de passe essaient d'abord vos clés, puis le mot de passe enregistré dans le trousseau ; un hôte qui a encore besoin d'un mot de passe le demande pendant la connexion, un à la fois (« Mot de passe pour bastion — hôte de rebond 1 sur 2 »), chaque demande avec sa propre case Enregistrer le mot de passe dans le trousseau du système.
  • Si un hôte de rebond a ses propres hôtes de rebond, ceux-ci sont traversés en premier. Une session ne peut pas être son propre hôte de rebond, et les chaînes avec des boucles, des sessions répétées, plus de 3 hôtes au total, ou des sessions de rebond supprimées ou non SSH sont refusées avec une erreur.
  • Les erreurs nomment l'hôte qui a échoué, par exemple via bastion (jump host 1): authentication failed.
  • Le navigateur SFTP de l'onglet utilise la même connexion, et les tunnels SSH dont la session a des hôtes de rebond passent aussi par eux. Fermer l'onglet (ou arrêter le tunnel) ferme toutes les connexions de la chaîne.
  • Supprimer une session que d'autres sessions utilisent comme hôte de rebond demande une confirmation et la retire de leurs hôtes de rebond.

Importer des sessions depuis un fichier .ini

Importer → Depuis un fichier .ini… dans le panneau Sessions lit un fichier de sessions .ini avec des sections [Bookmarks] (en UTF-8, ou dans la page de codes Windows-1252 dans laquelle ces fichiers sont souvent écrits) et affiche un aperçu avant tout enregistrement :

  • Les sessions SSH des sections [Bookmarks] / [Bookmarks_N] sont importées avec leur hôte, leur port (22 s'il est absent ou non valide) et leur nom d'utilisateur, et les sessions Telnet avec leur hôte et leur port (23 s'il est absent ou non valide), dans un dossier Imported qui conserve le chemin de dossier enregistré dans le fichier.
  • Les sessions SSH importées utilisent l'authentification par mot de passe ; modifiez-la ensuite avec Modifier. Les chemins des clés privées ne sont pas importés.
  • Les autres types de session (RDP, VNC, Série, WSL, FTP, ...), les entrées sans hôte et les lignes non reconnues sont ignorés et comptés par type dans l'aperçu.
  • Les sessions déjà enregistrées avec le même type, dossier, nom, hôte, port et nom d'utilisateur sont ignorées comme doublons.
  • Les mots de passe ne sont jamais importés : la section [Passwords] et toute autre section ne sont pas lues.

Importer des hôtes depuis ~/.ssh/config

Importer → Depuis ~/.ssh/config lit la configuration du client OpenSSH de votre dossier personnel (~/.ssh/config, également sous Windows) et affiche le même aperçu :

  • Chaque alias Host concret devient une session SSH portant son nom, dans Imported/SSH config. Les motifs génériques (*, ?) et négatifs (!) ne sont pas importés comme sessions, mais leurs options s'appliquent aux hôtes qu'ils désignent, tout comme les options placées avant le premier Host ; comme avec ssh, la première valeur de chaque option l'emporte.
  • HostName (l'alias s'il est absent ; %h est remplacé par l'alias), User (vide s'il est absent), Port (22 s'il est absent ou non valide) et le premier IdentityFile sont lus. Un hôte avec un IdentityFile utilise cette clé privée (%d devient ~) ; un hôte sans utilise l'authentification par mot de passe.
  • Les sauts ProxyJump qui sont des hôtes du même fichier deviennent les hôtes de rebond de la session (3 au maximum). Les autres sauts, comme user@gateway:2222, et ProxyCommand ne sont pas pris en charge : l'hôte est importé sans eux et compté dans l'aperçu.
  • Les lignes Include et les blocs Match ne sont pas suivis et sont comptés dans l'aperçu. Toutes les autres options sont ignorées.
  • Les hôtes déjà importés de la même manière sont ignorés comme doublons ; importer à nouveau n'ajoute donc que les nouveaux hôtes.