De Termius à Termix : rapatrier sa console SSH chez soi

Un client SSH, c'est l'outil qu'un administrateur ouvre le plus souvent dans sa journée. Pendant des années le nôtre était Termius : beau, synchronisé entre le poste et le téléphone, avec des dossiers, des identifiants partagés et une bibliothèque de commandes. Nous l'avons remplacé en septembre par Termix, une console web open source hébergée sur notre propre réseau d'administration. Ce n'est pas une histoire de fonctionnalités : Termius en a davantage. C'est une histoire de qui détient quoi.

Ce que l'on confie à un client SSH SaaS #

Regardez ce que contient votre client SSH : la liste complète de vos machines, avec leurs adresses, leurs ports, leurs comptes. Vos clés privées, si vous avez accepté la synchronisation. Vos mots de passe, vos extraits de commandes, parfois vos tunnels. C'est, mot pour mot, la cartographie de votre système d'information et les moyens d'y entrer. Chez un éditeur SaaS, tout cela est chiffré et synchronisé via ses serveurs, hors Union européenne, sous un abonnement. Nous n'avons aucune raison de douter de la qualité de ce chiffrement. Mais nous n'avions aucun moyen de la vérifier, aucun contrôle sur l'endroit, et une dépendance de plus le jour où l'abonnement, l'éditeur ou sa politique changent. Pour un parc que nous facturons à des clients comme hébergé et administré en France, c'était une incohérence que nous portions depuis trop longtemps.

Termix : une console web, chez nous #

Termix (Termix-SSH/Termix) est une plateforme web auto-hébergée : terminal SSH multi-onglets, gestionnaire de fichiers, tunnels, bureau distant via Guacamole, intégration Docker, enregistrement de session, et une application mobile. Le tout dans un conteneur, épinglé sur une version précise, avec une base SQLite chiffrée au repos. Nous l'avons installé sur une petite VM Debian 13 de notre réseau d'administration, avec deux principes : aucun mot de passe local (authentification uniquement par notre IdP Authentik, douzième service branché dessus) et aucune clé qui ouvre directement les serveurs (nous y revenons plus bas).

⟷ faites défiler

Peupler 42 hôtes sans les taper : l'API, et la bonne source #

Recopier 42 fiches à la main est le meilleur moyen d'y mettre des erreurs. Nous avons donc importé l'inventaire par l'API de Termix, en deux passes : d'abord le rebond (les 26 machines du réseau interne y passent), puis les clients de ce rebond, parce qu'une fiche ne peut référencer qu'un hôte de rebond déjà existant. Dossiers par zone, un identifiant partagé, et un réglage indispensable : le nom d'utilisateur porté par la fiche doit primer sur celui de l'identifiant, sinon toute la flotte se connecte en root alors qu'elle mélange quatre comptes différents.

Première leçon, et elle ne concerne pas Termix : l'import a été bâti sur ce que déclare le cluster (l'API de l'hyperviseur), pas sur notre fichier d'inventaire. Bien nous en a pris : le fichier contenait quatre machines qui n'existaient plus, une adresse attribuée à la mauvaise VM et deux entrées historiques barrées. Pour peupler un outil, partez toujours de la source de vérité, jamais du document qui est censé la refléter.

Les pièges que la documentation ne dit pas #

• Le TLS n'est pas une option. Sans ENABLE_SSL=true, le mot de passe transite en clair et la configuration CORS par défaut est très permissive. La documentation le liste comme faille connue ; personne ne le lit avant l'incident.
• Le chiffrement est dérivé du mot de passe de l'utilisateur. Réinitialiser un mot de passe hors session détruit toutes les données chiffrées de ce compte. Corollaire : ne créez jamais le compte d'un collègue à sa place.
• Le fichier d'environnement naît en 644 avec le secret JWT et la clé de base dedans. À remettre en 600 à la main. Et un signal d'usage quotidien part vers l'éditeur par défaut, désactivable dans les réglages.
• La route de listing est au singulier (/host/db/host) ; l'exemple officiel donne le pluriel, qui renvoie 404. Pire : /hosts renvoie l'application web en 200. Vérifiez le type de contenu, jamais le code seul.
• Une mise à jour en masse répond « 43 mis à jour, 0 échec » en ne changeant rien si le champ n'est pas dans sa liste blanche. Ne faites jamais confiance à ce code retour : relisez la fiche.
• L'enregistrement de session est indésactivable dans la version que nous utilisons : l'interrupteur par hôte existe dans la documentation, pas dans le code des routes. Nous vivons avec, rétention au minimum. Bug remonté en amont.

Le piège qui a failli noyer le bastion #

Termix vérifie périodiquement que chaque hôte répond, par une connexion TCP ouverte puis refermée. Inoffensif contre un serveur SSH ordinaire. Mais nos fiches ne visent plus les serveurs : elles visent notre bastion, qui enregistre chaque connexion. Quarante fiches sondées toutes les soixante secondes, c'est environ 5 200 sessions fantômes par jour, 1,7 Go d'enregistrements quotidiens, et une piste d'audit noyée sous du bruit indiscernable de vraies connexions. Le réglage global ne peut que ralentir le sondage (borné à une heure), pas l'éteindre. Il faut le couper fiche par fiche puis redémarrer le service, parce que la mise à jour d'une fiche ne recharge pas les minuteurs.

// PUT /host/db/host/:id - à poser sur chaque fiche, puis redémarrer Termix
{ "statsConfig": {
    "statusCheckEnabled": false,
    "metricsEnabled": false,
    "disableTcpPing": true
} }

SSO : deux surprises #

Le lien avec l'IdP se fait par variables d'environnement, avec inscription automatique au premier login et attribution du rôle administrateur par appartenance à un groupe. Deux surprises. La première : l'URL de retour est construite à partir de l'en-tête Host de la requête. Accédez à la console par une autre adresse que celle déclarée à l'IdP, et le login échoue en 400. La seconde, plus sérieuse : la liste d'utilisateurs autorisés ne s'applique pas au tout premier compte. Le premier qui réussit un login SSO devient administrateur, quelle que soit l'allowlist. La seule vraie barrière est donc l'affectation de l'application côté IdP : ne l'élargissez jamais avant votre propre premier login.

Ce que la console n'est pas #

Il faut être net : Termix apporte du confort, pas de la sécurité. Une console web qui détient une clé ouvrant 42 machines est une cible de très grande valeur, et c'est exactement ce que nous avions les premiers jours. La consolidation est venue d'ailleurs : toutes les fiches ont été repointées vers notre bastion Warpgate, et la clé de Termix a été retirée des 42 serveurs. Elle ne sert plus qu'à se présenter au bastion ; ce sont les clés du bastion qui ouvrent les machines, et chaque session y est enregistrée. La console peut disparaître demain, rien de ce qui compte n'y vit. C'est l'objet de l'article suivant.

Reprendre la main sur son outillage d'administration fait partie de ce que nous entendons par infogérance souveraine : pas seulement héberger en France, mais savoir à tout instant où vit la carte de votre système d'information. Si la vôtre est dans le cloud d'un client SSH, parlons-en.