Administrer un parc de serveurs Linux sans perdre le fil

L'ordre compte. On regarde d'abord ce qui écoute sur le réseau, parce que c'est la surface exposée immédiate ; ensuite ce qui démarre au boot, parce que c'est ce qui reviendra après un redémarrage ; enfin ce qui consomme, parce qu'un disque plein produit des pannes qu'aucun journal applicatif n'annonce. Un serveur récupéré d'un prestataire précédent contient presque toujours une clé publique oubliée dans un fichier authorized_keys, ou une tâche cron qui pousse des données vers un endroit que personne ne surveille plus.

Le constat ne vaut que s'il est écrit quelque part. Un inventaire tapé dans un terminal disparaît avec l'onglet. Le minimum utile tient en quelques lignes par machine : rôle, propriétaire, ce qui tourne, ce qu'on a le droit de redémarrer et qui prévenir. C'est ce document, pas la mémoire de l'opérateur, qui tient debout à trois heures du matin.

Le durcissement tient en peu de directives. Une fois vos clés déposées et vérifiées : PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin prohibit-password ou no, AllowUsers ou AllowGroups pour restreindre explicitement les comptes, MaxAuthTries bas, LoginGraceTime court, redirection d'agent désactivée par défaut. Sur les distributions récentes, écrivez ces réglages dans un fichier dédié de /etc/ssh/sshd_config.d/ plutôt que dans le fichier livré par le paquet : la prochaine mise à jour ne les écrasera pas.

Déplacer le port 22 réduit le volume de tentatives enregistrées, pas le risque réel : un scan ciblé retrouve le service en quelques secondes. Le gain est ailleurs, dans des journaux redevenus lisibles. Ce qui sécurise vraiment un VPS, c'est l'authentification par clé, le bannissement des adresses fautives avec fail2ban, un pare-feu qui n'ouvre que le nécessaire, et les mises à jour de sécurité appliquées sans intervention humaine. La documentation OpenSSH et les guides d'hygiène de l'ANSSI restent les deux références à garder ouvertes pendant l'opération.

Ce qui décide de la surface exposée est simple : qui initie la connexion. Un port en écoute sur une adresse publique est scanné en continu, quel que soit son numéro, et doit être défendu en permanence. Une connexion établie depuis la machine vers un point de rendez-vous n'est atteignable par personne depuis l'extérieur : il n'y a rien à trouver. C'est le même raisonnement qui fait préférer un tunnel sortant à une redirection de port dans un réseau d'entreprise dont on ne contrôle pas le pare-feu périmétrique.

Le bastion garde un avantage : il centralise les accès et les journaux, donc l'audit. Ses défauts sont connus, un point unique de défaillance et une cible de choix. Le tunnel sortant, lui, déplace la question de la confiance vers le point de rendez-vous : que voit-il passer, et que conserve-t-il ? C'est la question à poser à tout outil d'accès distant, y compris à un terminal web SSH : détient-il vos identifiants, sous quelle forme, et qui peut les déchiffrer ?

Le bon moment pour l'écrire est la première exécution : c'est là qu'on sait encore pourquoi telle option est présente et quelle erreur on a rencontrée. Le bon moment pour le corriger est la deuxième, quand apparaît l'écart entre ce qui est écrit et ce qu'on tape réellement. Un runbook qui n'a pas été rejoué depuis six mois doit être tenu pour faux jusqu'à preuve du contraire.

L'idempotence change tout : une procédure qu'on peut relancer sans casser l'existant se relit sereinement en pleine nuit. En pratique, cela veut dire tester avant de créer, écrire des fichiers de configuration complets plutôt qu'ajouter des lignes à la suite, et recharger un service plutôt que le redémarrer quand c'est possible. Il faut aussi dire ce que le runbook ne couvre pas : le cas où la vérification finale échoue mérite une ligne, même si cette ligne se contente de dire qui appeler.

Pour gérer plusieurs serveurs sans dérive, trois habitudes couvrent l'essentiel. Une convention de nommage qui dit le rôle et l'environnement, parce que l'erreur la plus coûteuse reste la bonne commande sur la mauvaise machine. Un inventaire à jour qui sert de source unique, plutôt que trois fichiers contradictoires. Un historique par machine, qui permet de répondre à « qu'est-ce qui a changé depuis la semaine dernière ? » sans reconstituer le passé de mémoire.

L'outillage d'exploitation se juge alors sur trois points : peut-on appliquer la même opération à un groupe de machines, retrouve-t-on ce qui a été fait sur une machine donnée, et voit-on son état courant au même endroit ? C'est le trou que Servor cherche à combler. Les 27 runbooks officiels livrés (nginx, Caddy, Apache, PostgreSQL, MySQL, Redis, Docker, Podman, WireGuard, Tailscale, durcissement SSH, fail2ban, UFW, mises à jour automatiques, entre autres) transforment les opérations courantes en procédures rejouables, et chaque exécution rejoint un historique unifié avec sa sortie, son code de retour et sa durée.

Les briques système existent : journalisation de sudo, auditd pour les appels sensibles, journald exporté vers un collecteur distant pour qu'une compromission locale n'efface pas les preuves. Elles répondent bien à un audit de conformité, moins bien à la question quotidienne d'une équipe, qui est de savoir ce qui a été fait hier soir sur cette machine, par qui, et si ça a fonctionné. C'est un besoin d'exploitation avant d'être un besoin de sécurité.

Servor enregistre chaque commande au même endroit quelle que soit son origine, saisie manuelle, runbook, terminal ou copilote IA, avec sa sortie, son code de retour et sa durée. S'y ajoute un journal d'audit chaîné par empreintes, protégé en écriture seule au niveau de la base : une entrée ne peut être ni modifiée ni supprimée. Pour une agence qui intervient sur les serveurs de plusieurs clients, c'est la différence entre affirmer ce qui a été fait et le montrer.

L'accès passe par un agent installé sur la machine, un binaire compilé unique fourni pour sept cibles (Linux x64 et arm64, en glibc et musl, macOS x64 et arm64, Windows x64). Il n'ouvre aucun port : c'est lui qui établit une connexion sortante, ce qui le fait fonctionner derrière un NAT, un pare-feu d'entreprise ou un réseau VPN-only. Il s'exécute sous l'utilisateur système configuré et ne reçoit jamais d'identifiant. Le terminal web est ré-attachable, donc fermer l'onglet ne tue pas le shell, et une commande lancée depuis le formulaire va au bout même si le navigateur se déconnecte. Le même agent pousse ses métriques toutes les 15 à 300 secondes et exécute les vérifications lui-même, ce qui les rend indépendantes d'une session ouverte : neuf types disponibles, de HTTP au certificat SSL en passant par l'espace disque et le script personnalisé, avec une hystérésis configurable pour ne pas basculer sur un faux positif.

Reste le traitement des identifiants, qui est le point sensible d'une console d'administration. La phrase secrète, la clé dérivée par Argon2id et la clé privée X25519 ne quittent pas le navigateur ; les secrets sont chiffrés en AES-256-GCM, et chaque commande est signée côté client avec une clé Ed25519 dérivée du coffre, puis vérifiée sur la machine cible. Conséquence directe : le serveur ne peut pas lire vos identifiants, et une compromission du plan de contrôle ne permet pas de forger une exécution. La contrepartie est assumée et il faut la connaître avant de s'engager, puisque perdre à la fois la phrase secrète et la phrase de récupération de 24 mots rend les données définitivement irrécupérables.