Le script que j’en avais marre de lancer : la naissance de WarpgateSH

Tue, 11 Aug 2026 11:57:53 +0200

Au travail, j’utilise Teleport. Les accès sont là quand j’en ai besoin, l’expérience est fluide et je n’ai pas à réfléchir au fichier SSH qui se cache derrière. À force de profiter de ce confort, une question a commencé à me trotter dans la tête : pourquoi est-ce que je n’avais pas quelque chose d’aussi naturel dans mon homelab ?

Chez moi, Warpgate faisait déjà très bien la partie importante du travail. Il filtrait les accès à mes serveurs, s’intégrait à Authentik pour le SSO (Single Sign-On) et me permettait de gérer précisément qui pouvait atteindre quoi. Je ne cherchais pas un énième jump host ni une énorme plateforme. Je voulais quelque chose de simple, avec juste assez de contrôle pour mon usage.

Le petit caillou dans la chaussure se trouvait sur mon Mac.

Le script qui fonctionnait… quand je pensais à le lancer

J’avais écrit un script capable d’interroger Warpgate et de générer les alias nécessaires dans ma configuration SSH. Une fois exécuté, le résultat était exactement celui que je voulais :

1

ssh dmz-nextcloud-01

La même cible fonctionnait aussi dans scp, rsync, Ansible et les autres outils qui savent parler à OpenSSH. Sur le papier, le problème était réglé.

Dans la vraie vie, il restait une étape assez importante : il fallait penser à lancer le script.

Quand une machine apparaissait dans Warpgate, elle n’apparaissait pas magiquement sur mon poste. Quand les accès évoluaient, mon fichier local ne suivait pas tout seul. J’avais automatisé la génération, mais pas le moment où elle devait se produire. C’était pas ouf.

C’est cette petite friction, répétée suffisamment souvent, qui a déclenché le projet. Je ne voulais plus d’une commande supplémentaire à retenir après chaque changement d’infrastructure. Je voulais que Warpgate reste la source de vérité et que mon Mac suive naturellement.

Teleport m’a donné l’idée, Warpgate lui a donné sa forme

Mon expérience de Teleport au travail m’a montré à quel point une CLI capable d’interagir directement avec le serveur pouvait rendre les accès beaucoup plus fluides. Je ne voulais pourtant pas reproduire Teleport fonctionnalité par fonctionnalité. Le contexte n’était pas le même et mon besoin était beaucoup plus modeste.

Pour mon homelab, j’avais choisi Warpgate plutôt que Teleport Community Edition. La première raison était simple : Warpgate est entièrement open source. Il s’intégrait également très bien avec mon Authentik existant, sans m’obliger à revoir toute mon architecture d’authentification.

Surtout, son périmètre correspondait à ce que je cherchais. Je voulais filtrer les connexions, gérer les autorisations avec suffisamment de granularité et ajouter une couche de contrôle devant les serveurs, tout en gardant quelque chose que je pouvais comprendre et exploiter tranquillement pendant mon temps libre.

Petit shout-out, donc, au projet Warpgate et à ses mainteneurs. WarpgateSH existe parce que leur outil m’a donné une base suffisamment agréable pour avoir envie de prolonger l’expérience jusque sur le poste utilisateur.

D’abord une idée, puis beaucoup de questions

Au début, j’imaginais presque un petit utilitaire : récupérer les cibles autorisées, écrire un fichier SSH et passer à autre chose. Évidemment, le projet a commencé à poser des questions dès que j’ai essayé de lui donner une forme sérieuse.

Est-ce que la CLI devait être le produit principal ou seulement un complément à une application macOS ? Fallait-il gérer plusieurs instances Warpgate ? Que faire si une synchronisation échouait ? Comment conserver des alias agréables sans écraser une entrée déjà présente dans mon fichier SSH ? Et comment éviter de concevoir quelque chose de tellement lié à mon homelab que personne d’autre ne pourrait l’utiliser ?

Je n’avais pas de calendrier à tenir. Le vrai défi était là : prendre le temps de réfléchir à l’architecture avant de transformer mon premier script en un second script, simplement plus joli.

Une décision s’est imposée assez vite. La CLI resterait l’interface principale, et l’application graphique viendrait l’accompagner. Même avec toutes les fenêtres du monde fermées, je devais toujours pouvoir taper :

1

ssh une-cible

OpenSSH continuerait donc d’établir les connexions. WarpgateSH se contenterait de maintenir les informations locales à jour en arrière-plan. Cette séparation correspondait bien à mon objectif : améliorer mon quotidien sans remplacer les outils qui fonctionnaient déjà.

Rust sur macOS, avec Linux dans un coin de la tête

Le choix de la technologie a été l’autre gros morceau de réflexion. J’ai une petite affinité avec Rust, et ce projet lui allait plutôt bien : une CLI, un agent qui tourne en arrière-plan, des fichiers à manipuler proprement et l’envie d’obtenir un binaire solide.

Rust me donnait aussi une base portable. Je voulais commencer sur macOS, parce que c’est mon poste quotidien et le meilleur endroit pour éprouver réellement l’outil. Mais j’affectionne également Linux et je ne voulais pas découvrir dans six mois que toute l’architecture dépendait d’un détail impossible à transposer.

Le cœur, la CLI et l’agent sont donc écrits en Rust. Pour le compagnon graphique, j’ai choisi Tauri avec React. Cela me permet de construire une application légère pour macOS sans fermer la porte à une version Linux plus tard.

Il y a eu des tâtonnements, bien sûr. Le nom provisoire warpctl était déjà utilisé ailleurs. wsh, que je trouvais pratique, entrait lui aussi en collision avec d’autres outils. Le projet a fini par devenir WarpgateSH, avec la commande warpgatesh. Un peu plus long à taper, mais beaucoup plus simple à retrouver sur GitHub — et nettement moins susceptible de marcher sur les plates-bandes du voisin.

Le moment où le prototype est devenu réel

Le vrai déclic n’est pas arrivé pendant une discussion d’architecture ni devant une suite de tests verte.

Il est arrivé lorsque j’ai créé un jeton personnel depuis l’interface de Warpgate, que je l’ai donné au prototype et que la liste de mes serveurs est apparue. Les 41 cibles associées à mon compte étaient là, récupérées directement depuis Warpgate, sans utiliser le compte administrateur et sans relancer mon ancien script.

À ce moment-là, l’idée avait enfin dépassé le stade du README.

J’ai pu lancer une connexion avec la CLI :

1

warpgatesh dmz-nextcloud-01

Puis avec OpenSSH, exactement comme avant :

1

ssh dmz-nextcloud-01

C’était le résultat que je cherchais depuis le début. Warpgate gérait les accès, l’agent synchronisait les changements et mes habitudes dans le terminal ne bougeaient pas d’un millimètre.

Le compagnon macOS a ajouté le dernier morceau visible. Je pouvais voir l’état de l’agent, rechercher une cible, lancer une connexion et observer les actualisations sans revenir au terminal. Voir la liste évoluer dans l’interface pendant que l’agent travaillait en arrière-plan a rendu le projet beaucoup plus concret. Ce n’était plus seulement un outil que je développais : c’était déjà quelque chose que je pouvais utiliser.

Le résultat, pour l’instant

WarpgateSH n’est pas encore une application grand public parfaitement emballée. La distribution macOS, la signature pour les autres utilisateurs et les derniers détails du compagnon demandent encore du travail. Linux viendra ensuite, après une vraie période d’utilisation quotidienne sur mon Mac.

Mais la promesse initiale est déjà tenue : je n’ai plus besoin de lancer manuellement mon script pour retrouver les accès Warpgate sur mon poste. Je peux utiliser la CLI quand j’en ai envie, rester avec OpenSSH quand je préfère, et consulter l’application lorsque j’ai besoin d’une vue plus visuelle.

Le plus amusant, c’est que tout est parti d’une tâche qui prenait seulement quelques secondes. Lancer un script n’était pas un drame. C’était simplement le genre de petite corvée qui finit par rappeler, à chaque répétition, qu’elle ne devrait probablement plus exister.

Le projet est public et disponible ici : github.com/M0okz/warpgatesh.

Si WarpgateSH peut éviter à d’autres utilisateurs de maintenir leurs alias SSH à la main, le petit agacement de départ aura finalement servi à quelque chose.

À l’occasion, j’essaierai de vous faire un petit billet sur mon « flow » complet : du déploiement d’une ressource dans mon homelab jusqu’à la première connexion au serveur.