guest@6admin.io:~$

The Bastion et Guacamole : les deux battants de la porte d'entrée

Il y a deux populations dans toute infrastructure et elles posent la même question à des outils différents. Les gens du shell demandent: “je fais quoi pour me connecter au serveur et qui peut le prouver après coup?” Les gens du bureau demandent: “comment atteindre ce poste Windows sans VPN et sans client installé?” Il existe un outil remarquable de chaque côté et tous les deux méritent mieux qu’une mention en bas de page: The Bastion d’OVHcloud pour la première population, Apache Guacamole pour la seconde. Ensemble, ils forment les deux battants d’une même porte d’entrée: l’un tient le compte des mains sur clavier, l’autre des mains sur souris.

The Bastion : la traçabilité comme fonction première

Un bastion SSH classique est un jump host déguisé: on s’y connecte, il rebondit et l’audit se résume à des logs de connexion. The Bastion fait sauter le déguisement en cassant le protocole SSH entre l’entrée et la sortie: la connexion d’entrée authentifie la personne, la connexion de sortie authentifie le bastion et plus rien ne circule implicitement entre les deux. C’est le point d’architecture qui rend tout le reste possible.

Ce qui rend l’outil précieux, c’est le modèle d’habilitation. Chaque opérateur a un compte individuel, les accès se gèrent par groupes avec délégation de rôles (l’équipe réseau gère ses propres ACL sans toucher au reste) et les machines ne connaissent que les groupes, jamais les personnes, si bien qu’un départ se traite en retirant une adhésion et pas en re-émettant vingt clés. La session interactive est enregistrée en ttyrec standard (rejouable avec n’importe quel lecteur), les logs partent en syslog pour le SIEM, la MFA TOTP s’ajoute sur la connexion d’entrée et l’attestation des clés PIV est vérifiable à l’entrée. Les vieux équipements qui ne parlent que telnet ou ne connaissent pas les clés publiques restent joignables par autologin en sortie, tandis que l’entrée reste en clé forte: la dette d’hier ne contamine pas la porte.

Et le détail qui me fait rester: l’outil n’exige rien de l’environnement. Pas de base de données, pas de daemon tiers, pas d’agent sur les machines cibles: un client ssh quelconque à l’entrée, un sshd quelconque en sortie, un cluster actif/actif pour la disponibilité. Le bastion d’une équipe SRE est un composant critique et celui-là tombe rarement.

Guacamole : le bureau dans l’onglet

De l’autre battant, Apache Guacamole résout un problème que les gens du shell sous-estiment: le poste Windows, l’application graphique, la console RDP qu’un opérateur doit ouvrir trois fois par semaine depuis un laptop qui n’a pas le droit d’installer de client. Guacamole est une gateway clientless: RDP, VNC et SSH rendus en HTML5 dans un onglet de navigateur, derrière un webapp Java et le daemon guacd qui parle les protocoles natifs.

Ce que ça change dans les faits: plus de client à déployer et patcher sur les postes, l’accès se donne et se révoque côté serveur (authentification par base, LDAP ou extension maison, 2FA TOTP en couche), les sessions peuvent s’enregistrer et le périmètre réseau se réduit à “le webapp est joignable, guacd parle aux cibles”. Le serveur Windows ne se révèle plus à internet: il se révèle à guacd, derrière la porte.

Ensemble et en prod

Le montage qui tient la route est simple à décrire: The Bastion pour tout ce qui est terminal et scriptable (y compris l’API JSON over SSH pour l’automatisation et les délégations), Guacamole pour tout ce qui est bureau et console graphique, les deux devant un pare-feu qui ne laisse passer que leurs adresses d’entrée. Les outils ne se recouvrent presque pas: l’un trace des shells et des transferts de fichiers, l’autre des bureaux; l’un habille l’humain qui écrit des commandes, l’autre l’humain qui clique. Et les deux partagent la propriété qui compte: l’accès se prouve après coup, par l’enregistrement de session et se gère par abstractions (groupes, comptes, ACL) plutôt que par copie de clés.

[edit: 2026] L’implémentation Ansible de tout ceci: les rôles ssh et ssh-users .