Piloter ses serveurs avec un émulateur de terminal web

Sommaire

Brève histoire de l’administration système

Si l’on suit sur quelques décennies l’évolution des pratiques, l’administration de serveurs apparaît comme une succession de milieux techniques où coexistent plusieurs “espèces” d’outils et de gestes professionnels. Plutôt qu’une rupture entre “anciens” et “modernes”, on observe des couches qui se superposent, se transforment et, parfois, survivent longtemps après leur apogée.

Ère de l’administration physique (années 1950–1970)

À partir du début des années 1950, avec la diffusion commerciale des premiers ordinateurs centraux et mini-ordinateurs, l’administration est indissociable de la présence au plus près des machines. L’exploitation se fait dans la salle informatique : consoles dédiées, panneaux de voyants, interrupteurs en façade, lecteurs de cartes et de bandes. L’administrateur — souvent encore appelé opérateur ou exploitant — surveille la machine, intervient sur les périphériques, relance les traitements, et saisit les commandes directement sur un clavier relié à la console.

Dans ce contexte, “gérer un serveur” revient à prendre soin d’un équipement unique, localisé dans un lieu précis, à l’aide d’outils fournis par le constructeur. Les frontières entre administration système, exploitation quotidienne et maintenance matérielle restent floues, tant les gestes sont liés au support physique.

Ère des terminaux et du temps partagé (années 1960–1980)

Au tournant des années 1960, les systèmes multi-utilisateurs et le partage de temps se développent. Des systèmes de temps partagé sont expérimentés au début des années 1960, puis se généralisent dans les années 1970. Les utilisateurs comme les administrateurs accèdent alors aux machines via des terminaux reliés par des lignes série ou des concentrateurs de communication.

L’administration se déplace progressivement de la console centrale vers ces terminaux : création de comptes, gestion des quotas, surveillance des files d’impression, configuration des périphériques. La distance géographique augmente, mais reste le plus souvent limitée au site ou au campus. Le serveur est toujours une machine bien identifiée, mais désormais accessible à travers un réseau interne rudimentaire.

Ère des réseaux et de l’accès distant généralisé (années 1980–1990)

À partir des années 1980, la normalisation des protocoles de communication et la diffusion de TCP/IP transforment l’accès aux systèmes. Des protocoles comme Telnet, conçus à la fin des années 1960 et largement popularisés avec les systèmes Unix dans les années 1980, permettent à un administrateur de se connecter à un serveur depuis un autre, au sein d’un réseau local ou, graduellement, à travers des interconnexions plus vastes.

Les tâches restent proches de celles des décennies précédentes, mais l’échelle change : un même administrateur peut gérer un nombre croissant de machines, réparties sur plusieurs sites, parfois dans plusieurs pays. Les premières formes d’automatisation apparaissent sous la forme de scripts maison, souvent adaptés à un environnement précis.

Ère de l’administration distante sécurisée (milieu des années 1990 – années 2000)

L’essor d’Internet public au début des années 1990 met en évidence les limites de l’administration à distance en clair. Au milieu des années 1990, la conception de SSH, dont la première version a été publiée en 1995, marque un tournant : le chiffrement des connexions, l’authentification par clés et la possibilité de créer des tunnels sécurisés deviennent progressivement la norme pour l’administration distante des systèmes Unix et apparentés. Dans le monde Windows, Remote Desktop Protocol est introduit à la fin des années 1990 et rend l’administration graphique à distance beaucoup plus accessible.

Au début des années 2000, l’image de l’administrateur typique est celle d’une personne qui se connecte en SSH ou via un bureau distant, enchaîne des commandes, entretient quelques scripts et mémorise — ou documente soigneusement — les noms d’hôtes, ports, clés et mots de passe. C’est dans cette période que se cristallise ce que j’appelle, par simplification affectueuse, la paléoinformatique : une pratique très manuelle, mais efficace tant que le nombre de machines reste raisonnable.

Ère de l’automatisation et de l’infrastructure comme code (années 1990–2010)

Dès le début des années 1990, des outils de gestion de configuration apparaissent pour décrire l’état souhaité d’un système plutôt que de se limiter à des suites de commandes individuelles. CFEngine, par exemple, est conçu à partir de 1993, ouvrant la voie à une approche plus déclarative. Au milieu des années 2000, de nouveaux outils comme Puppet (créé en 2005), puis Chef (présenté à partir de 2009) et Ansible (développé au début des années 2010) étendent cette logique à des parcs de serveurs de plus en plus vastes.

Parallèlement, les années 2000 popularisent l’idée d’Infrastructure as code, où les configurations et les déploiements sont versionnés, relus et testés comme du logiciel. Le terme “DevOps” apparaît vers la fin des années 2000 et devient, au cours des années 2010, un cadre de référence pour rapprocher développement, exploitation et automatisation. Dans ce milieu, le terminal conserve une place importante, mais il sert surtout à piloter des outils qui agissent sur des dizaines ou des centaines de machines à la fois.

Ère de la virtualisation massive, du cloud et des plateformes (années 2000–2020)

La virtualisation, qui progresse fortement à partir de la fin des années 1990 et du début des années 2000, ajoute une nouvelle couche d’abstraction. Les administrateurs gèrent désormais des dizaines ou des centaines de machines virtuelles réparties sur un même matériel physique. Au milieu des années 2000, les premières offres de cloud à grande échelle rendent possible la location de ressources informatiques à la demande, sans investissement matériel initial.

Dans les années 2010, l’essor des conteneurs, des orchestrateurs de clusters et des services managés renforce cette tendance : on administre moins des serveurs individuels que des ensembles de services, de pods, de projets ou d’environnements. Les consoles web, les interfaces de programmation, les lignes de commande spécialisées et les chaînes d’intégration continue deviennent des outils centraux de l’administration.

On trouve encore des systèmes administrés uniquement en local, des serveurs isolés accessibles exclusivement en SSH, et des environnements entièrement pilotés par des pipelines automatisés. Pour un même parc, il n’est pas rare de retrouver plusieurs couches de ces pratiques, héritées d’histoires et de contraintes différentes.

Administrer ses propres serveurs à la maison

La figure qui nous intéresse désormais n’est plus celle de l’administrateur professionnel dans un centre de données, mais celle du passionné qui entretient son propre “parc” chez lui, dans un bureau, un salon ou une cave aménagée. Son terrain de jeu mélange volontiers une machine de bureau qui fait office de serveur, un ou plusieurs petits boîtiers dédiés, parfois un hyperviseur et, de plus en plus souvent, quelques instances perdues dans le cloud.

Dans ce milieu, l’objectif n’est pas forcément d’industrialiser à l’extrême, mais de garder la main sur des machines que l’on connaît parfois intimement. Les outils choisis reflètent autant des habitudes personnelles que des contraintes matérielles ou financières, et dessinent quelques grands scénarios récurrents du point de vue, très concret, de la façon dont on se connecte aux machines.

Pour beaucoup de passionnés, l’histoire commence avec une seule machine polyvalente, utilisée à la fois comme poste de travail principal et comme serveur. La majorité des interactions d’administration se font alors directement sur cette machine, via une session graphique ou un terminal local, et les rares connexions distantes nécessaires passent par quelques commandes ssh lancées depuis un ordinateur portable ou un second poste au sein du réseau domestique.

Vient ensuite le cas, très répandu, du petit parc domestique : un serveur principal, un boîtier de stockage, quelques micro-ordinateurs de type Raspberry Pi, un routeur un peu plus évolué, parfois un point d’accès dédié. Ici, ssh devient l’outil le plus utilisé pour piloter les machines depuis un poste central, souvent complété par les interfaces web déjà intégrées à certains équipements, comme le routeur ou le système de stockage en réseau.

Un autre profil courant est celui de l’hyperviseur domestique, où une machine plus puissante héberge plusieurs machines virtuelles ou conteneurs. Selon les habitudes et les besoins, l’administrateur peut se connecter directement en ssh aux invités pour les opérations courantes, ou bien passer par l’interface de gestion de l’hyperviseur dans son navigateur lorsqu’il doit créer, arrêter ou déplacer des environnements, ce qui ajoute alors un niveau supplémentaire entre son terminal et le service visé.

Enfin, de nombreux passionnés élargissent leur parc en y ajoutant quelques serveurs privés virtuels ou services hébergés dans le cloud. L’accès à ces ressources distantes se fait le plus souvent comme à des machines locales : ssh pour l’administration système, une interface web du fournisseur pour la création ou la suppression d’instances, parfois un réseau privé virtuel pour les intégrer plus étroitement au réseau domestique.

Quel que soit le profil exact, le quotidien de ces administrateurs tourne ainsi autour d’un émulateur de terminal — généralement installé par défaut — sur leur poste de travail, d’un navigateur ouvert sur différentes consoles d’administration, et d’une poignée d’habitudes bien ancrées pour retrouver rapidement la bonne machine. Dans ce paysage, de nombreux outils modernes proposent un terminal web intégré, en particulier dans les consoles des fournisseurs cloud ou de certaines plateformes d’administration, mais il est difficile de mesurer dans quelles proportions ces fonctions sont réellement utilisées au quotidien. Pour la plupart des passionnés, le client ssh classique reste le point d’entrée principal vers les machines, tandis que les terminaux web servent surtout de complément ponctuel, inséré dans une application plus vaste plutôt que comme outil central d’administration.

Je vais pourtant prendre le contre-pied de ce paysage majoritaire et explorer la possibilité de faire d’un terminal web l’outil d’administration principal de mes serveurs. Avant de détailler l’outil lui-même, il me faut d’abord poser les raisons et les contraintes qui rendent ce choix, en apparence marginal, pertinent dans mon cas.

La niche du terminal web

Il existe des émulateurs de terminal pour tous les systèmes d’exploitation courants, en général préinstallés par défaut. Si l’on dispose déjà d’un client ssh classique sur son poste ou sur le réseau local, pourquoi ne pas s’en servir ?

Par ailleurs, de nombreux outils modernes d’administration intègrent déjà leur propre terminal web au sein d’un écosystème plus vaste. D’ailleurs, avec l’Infrastructure as Code, on pourrait penser que les jours de la ligne de commande sont comptés, sans verser dans le techno-catastrophisme.

Notons pourtant que les terminaux web ne sont pas une invention récente. Depuis bien longtemps, des outils comme Anyterm (milieu des années 2000), Shell In A Box (fin des années 2000) ou Gate One (début des années 2010) proposaient déjà un accès à un shell Unix au travers d’un simple navigateur, avec des approches techniques variées (CGI, puis AJAX, et enfin WebSocket). Au fil des années 2010, le concept s’est cependant nettement professionnalisé. La bibliothèque xterm.js, apparue en 2014, sert de base à des terminaux intégrés dans des outils très répandus comme Visual Studio Code, l’IDE Theia ou des environnements de développement en ligne tels que Gitpod, et l’on retrouve des approches similaires dans de nombreux tableaux de bord et plateformes DevOps, qu’ils s’appuient sur xterm.js ou sur des bibliothèques voisines.

En conséquence, la recherche et l’utilisation active d’un émulateur de terminal basé sur le web n’est pas forcément aussi absurde que ça en a l’air au premier abord. Au contraire, cela reflète la convergence d’un besoin élémentaire (gérer une ou plusieurs machines à distance) et l’utilisation d’un environnement universel (le navigateur). Et vouloir extraire cet usage spécifique de l’écosystème dans lequel on le trouve habituellement (agglomération d’outils de gestion système unifiés dans une interface commune) permet d’adopter une approche plus UNIX du terminal web (mais moins, évidemment, qu’un émulateur traditionnel, dont je cherche précisément le remplacement).

Paysage logiciel

Mes exigences

Je refuse toute solution basée sur docker ou podman. Je n’utilise pas de conteneur, dans aucun contexte, donc je ne veux pas les introduire pour quelque chose d’aussi trivial. L’application doit être disponible dans les dépôts de NixOS. Ceci exclut d’office bon nombre de solutions, en particulier des solutions que j’estime lourdes, destinées à des environnements que je n’exploite pas.

Je veux un véritable émulateur de terminal web, qui me donne un accès complet au système, au même titre que n’importe quel émulateur de terminal non-web. L’expérience utilisateur (UX) doit être rigoureusement identique : je ne dois pas dépendre d’un shell particulier ou confiné dans un environnement de type sandbox. Je ne veux pas non plus devoir installer un agent sur chaque machine : le serveur SSH se suffit à lui-même. Cette exigence exclut la plupart de ce que l’on appelle “les bastions”.

Je veux une application qui ne m’oblige pas à l’exposer sur le web. Oui, je veux une application web, mais le web existe aussi à l’intérieur du réseau local. Ici, je vise spécifiquement les applications qui exigeraient de mettre en place un système de certificats par un fournisseur externe (au hasard, Let’s Encrypt). Un certificat auto-signé sera bien suffisant, et ne serait même pas nécessaire en pratique. Il est pertinent que ce soit un comportement par défaut, mais il n’est pas pertinent que ce soit un comportement obligatoire, à partir du moment où ce comportement est le fruit d’une décision arbitraire du créateur de l’application. Je dois pouvoir choisir, en mon âme et conscience, ce que je veux faire, même si la majorité estime que c’est une mauvaise idée.

Sélection finale

Cet ensemble d’exigences, que d’aucun sera libre de juger selon ses propres critères, a rapidement réduit les possibilités.

La plus lourde d’entre elles est Apache Guacamole. Outre sa lourdeur (notamment due à Tomcat, le serveur web intégré et non désactivable), sa configuration s’est avérée pénible à cause d’une sémantique XML particulièrement verbeuse, empêchant la réutilisation propre de certains blocs de définition.

Il faut dire que Guacamole est taillé pour bien davantage que SSH : le client web est capable de faire du RDP et du VNC, des technologies de connexion à distance que je n’exploiterai jamais. Malheureusement, même en ne faisant que du SSH, ce client s’est avéré trop bugué pour remplir correctement sa fonction.

De l’autre côté du spectre, j’ai testé ttyd. Minimaliste, il ne coche pas tous mes critères de fonctionnalités, en particulier la gestion d’une liste d’hôtes auxquels me connecter. ttyd se montrerait intéressant si j’avais décidé de ne pas centraliser mes accès SSH. Il pourrait même se montrer utile dans le cas où je devrais songer à prévenir un single point of failure, ce qui n’est pas dans mes priorités. Je ne sauve pas des vies.

J’ai testé Sshwifty, qui, au début, ne m’a pas laissé une très bonne impression. J’y suis revenu plus sérieusement après avoir testé les propositions vues précédemment, en m’attardant un peu plus sur son fonctionnement et ses possibilités de configuration qui, finalement, correspondent bien à ce que je cherche à faire.

{
  services.sshwifty = {
    enable = true;
    settings = {
      # Je ne veux pas gérer les remotes depuis l'interface
      "OnlyAllowPresetRemotes" = true;
      "Servers" = [{
        "ListenInterface" = "127.0.0.1";
        "ListenPort" = 8182;
      }];
      # C'est ici que je rempli ma liste d'hôtes.
      "Presets" = [
        {
          "Title" = "router";
          "Type" = "SSH";
          "Host" = "router.home.arpa";
          "Meta" = {
            "User" = "richard";
            "Authentication" = "Private Key";
            "Private Key" =
              "file:///[...]";
            "Fingerprint" =
              "SHA256:[...]";
          };
        }
        {
          "Title" = "server-main";
          "Type" = "SSH";
          "Host" = "server-main.home.arpa";
          "Meta" = {
            "Encoding" = "utf-8";
            "User" = "richard";
            "Authentication" = "Private Key";
            "Private Key" =
              "file:///[...]";
            "Fingerprint" =
              "SHA256:[...]";
          };
        }
        # etc.
      ];
    };
  };
}

Je peux stocker mes clés comme bon me semble, je n’ai pas à les stocker directement dans la configuration (au contraire de Guacamole, à moins que je sois allé trop vite dans la lecture de la documentation). Je dois récupérer l’empreinte de chaque serveur (qui s’affiche à toute connexion préliminaire, donc facile à obtenir) pour supprimer une étape de la connexion au client. C’est toujours ça de pris, étant donné qu’aucune connexion ne se fait littéralement en un seul clic.

En effet, l’UX de Sshwifty n’est pas des plus agréables. Par exemple, un clic et beaucoup d’espace vide auraient pu être économisés en affichant directement sur la page d’accueil la liste des hôtes configurés, au lieu de ne pouvoir y accéder que depuis le menu “+”.

En outre, malgré l’absence de paramètre ajustable une fois un hôte sélectionné, on aurait pu passer directement à l’étape de connexion…

…qui elle-même aurait pu être évitée pour les mêmes raisons :

Cela dit, une fois le shell disponible, ça fonctionne bien, même avec fish et tide configurés pour afficher des icônes.

Sshwifty exige un reverse-proxy fournissant un accès sécurisé. Sans cela, la connexion au websocket posera problème. Heureusement, l’application ne m’impose pas une façon de faire particulière : je peux donc utiliser mon serveur caddy en place, et lui faire générer un certificat auto-signé, sans jamais faire appel à ACME/Let’s Encrypt, et donc sans jamais contacter l’extérieur du réseau.

{
  services.caddy = {
    enable = true;

    # Pas de HTTPS automatique sur ce serveur, c'est mon frontend qui s'en occupe
    globalConfig = ''
      auto_https off
      servers {
        trusted_proxies static private_ranges
      }
    '';

    # Sur mon backend, les vhosts se font par port et non par domaine.
    # Malgré tout, j'ai besoin de préciser le FQDN du serveur pour générer le
    # certificat.
    virtualHosts = {
        # [...]
        "server-main.home.arpa:30083".extraConfig = ''
            reverse_proxy http://127.0.0.1:8182
            tls internal
        '';
        # [...]
    };
  };
}

Conclusion

Outre la passionnante exploration historique démarrant cet article, j’ai pu me rendre compte de certaines concessions que je devais accepter, et auxquelles je ne suis pas habitué.

J’ai toujours connu une informatique permissive, incitatrice, quitte à faire des erreurs, expérimentatrice. On a avancé vers une informatique balisée, complexifiée, industrialisée, qu’il devient difficile à appréhender, voire simplement à accéder. Cette distante par rapport à l’informatique des origines a clairement tendance à m’inquiéter, dans la mesure où l’on ne trouve que difficilement des outils dimensionnés pour nous, les geeks.

Les entreprises bénéficient d’outils de plus en plus complets et avancés, tandis que les particuliers ne peuvent compter que sur des outils minimalistes, excellant parfois dans leur domaine spécifique, mais dont l’avenir est néanmoins incertain.

Au-delà des questionnements habituels formés autour des logiciels libres de petite envergure — sur leur durée de vie, sur leur modèle économique - ce qui m’inquiète le plus reste l’influence des tendances à majorité d’adhésion. Je commence à percevoir les écosystèmes logiciels comme des écosystèmes vivants, subissant une pression sélective de la part du marché dicté par la majorité des utilisateurs. Et certains représentants de ces écosystèmes ne peuvent survivre, aussi intéressant soient-il, même s’il existe certains utilisateurs qui en ont un besoin manifeste.

Dans le cas qui nous a intéressé aujourd’hui, mon inquiétude reste réduite, parce que ma recherche d’un terminal web s’inscrit dans un plan d’avenir, que je vous détaillerai dans des articles ultérieurs : la transformation de mon poste de travail…