vps-forge : les agents root sur VPS disposent d'un rollback automatique, les auto-bannissements passent de 7 sur 60 à 0

Un agent root sur un VPS fraîchement installé déploie fail2ban, vérifie la connexion par clé, teste un mot de passe et, à la cinquième tentative échouée, bannit l'IP d'où partent les vérifications. C'est-à-dire la vôtre. Ensuite, toutes les commandes tombent en timeout et vous cherchez la console web dans le panneau de l'hébergeur. Dans le benchmark de l'auteur de vps-forge, Claude Opus 5.5, sans consigne particulière, s'est banni lui-même dans 7 runs sur 60. Le modèle n'est pas bête : personne ne lui a simplement dit d'ajouter son adresse à ignoreip avant le premier lancement de fail2ban.

vps-forge est un Agent Skill open source : un ensemble d'instructions et de scripts bash que Claude Code, Codex, Cursor et d'autres agents chargent dès qu'il est question d'un serveur. Installation : `npx skills add mountain-beaver/vps-forge -g`. Il existe un plugin pour Claude Code et une archive zip pour Claude.ai.

Pourquoi « sois prudent » ne marche pas

Un sshd_config cassé a l'air de fonctionner. `sshd -t` ne dit rien, le reload passe, la session en cours reste ouverte, mais les nouvelles connexions sont déjà bloquées : par exemple `AllowUsers deploy` alors que vous êtes admin, ou un AllowGroups dans lequel on a oublié de s'ajouter.

Les agents ont leur propre piège. Ils conservent une seule connexion via ControlMaster, et la vérification `ssh host true` passe par l'ancien canal. Elle ne touche ni le nouveau sshd ni les nouvelles règles du pare-feu : le test est au vert, mais il est impossible de se connecter. La consigne « vérifie la connexion depuis une nouvelle connexion » ne sert à rien si l'agent a déjà perdu l'accès. Il faut un mécanisme qui se déclenche sans lui.

Une pédale d'homme mort pour sshd

Avant chaque modification de SSH, du pare-feu, de sudo ou de PAM, l'agent exécute `vps-forge-deadman arm`. Le script prend un snapshot des configurations et crée un minuteur systemd de 5 minutes. L'agent modifie la configuration, se reconnecte via `ssh -o ControlPath=none` et, si la connexion réussit, exécute disarm. Sinon, il n'a rien à faire : au bout de 5 minutes, le minuteur remet tout dans l'état initial.

Sur le papier, c'est 20 lignes de bash ; au final, il y en a plusieurs centaines. Presque chaque ligne correspond à une panne rencontrée :

• Redémarrage. Un minuteur créé par systemd-run vit en mémoire et disparaît avec le serveur. Désormais, arm active aussi une unité qui, au démarrage, repère l'état « armé mais non désarmé » et déclenche elle-même le rollback.
• nftables. Le rollback arrêtait un service qui était désactivé avant arm, et son ExecStop contient `nft flush ruleset`. Avec la règle visée disparaissaient aussi ufw, les bans fail2ban et les chaînes Docker. Désormais, seules les tables de la configuration annulée sont supprimées.
• Locale russe d'ufw. Le script cherchait la chaîne `Status: active`, alors qu'ufw écrit « Состояние: активен ». Le pare-feu était considéré comme désactivé et se retrouvait coupé lors du rollback. Le correctif : `LC_ALL=C`.
• Ban après rollback. Les configurations étaient restaurées, mais l'IP restait bannie. Désormais, arm mémorise l'adresse du client SSH et le rollback la débannit. Sous sudo, la variable SSH_CLIENT n'existe pas ; l'adresse est alors lue dans l'environnement du processus parent.

Tout cela tourne en CI : un conteneur avec un vrai systemd, un test qui casse sshd, le pare-feu et fail2ban, redémarre le conteneur à l'état armé et vérifie la restauration. Le pare-feu du panneau du fournisseur, lui, ne peut pas être annulé : il se trouve hors du serveur. Seul l'ordre des opérations fonctionne dans ce cas : d'abord ajouter la nouvelle règle, vérifier la connexion, puis supprimer l'ancienne.

Les pièges des images cloud et le benchmark

Le plus vicieux est cloud-init. Sur de nombreux VPS se trouve un fichier `50-cloud-init.conf` avec `PasswordAuthentication yes`. sshd retient la première valeur lue, les fichiers sont lus par ordre alphabétique, si bien que le conseil répandu d'utiliser `99-hardening.conf` ne fait rien. Le fichier du skill s'appelle `00-vps-forge.conf`, et le résultat est vérifié via `sshd -T`. Autres écueils : Debian 12 n'a pas d'auth.log, Docker publie les ports en contournant ufw, l'image Oracle Cloud contient sa propre règle REJECT dans iptables, et Coolify se connecte à son propre hôte en SSH sous root, de sorte que `PermitRootLogin no` casse le déploiement.

Le banc d'essai : de vraies VM sous QEMU (Debian 12 et 13, Ubuntu 22.04, 24.04, 26.04), quatre scénarios, chacun joué trois fois sans le skill et avec lui — soit 120 runs d'Opus 5.5. Un juge vérifie le serveur de l'extérieur avant et après redémarrage. Sans le skill, le score est de 79–92 sur 100 ; avec le skill, de 99–100.

• ssh-audit sans échec : 4/60 sans le skill, 60/60 avec
• Alerte de connexion SSH : 16/30 et 30/30
• Pare-feu activé : 46/60 et 60/60
• Le brute force de mots de passe est banni : 50/60 et 60/60
• Root ne peut pas se connecter : 30/60 et 57/60
• L'agent s'est banni lui-même : 7/60 et 0/60
• Perte d'accès : 0/60 et 0/60

L'auteur énumère honnêtement les points faibles. Un serveur vierge obtient 25–42 points. Environ 70 % de l'écart provient de trois vérifications qui coïncident avec les réglages du skill lui-même : un ssh-audit propre, l'interdiction de root et l'alerte. Le juge et le skill ont été écrits par la même personne, et Lynis, indépendant, bouge à peine : 69 et 71, 72 et 72, 64 et 72, 73 et 72. Trois scénarios sur quatre ont servi à affiner le skill. Un seul modèle a été testé, plus quatre runs manuels de GLM-5.3. Le benchmark n'a pas démontré l'intérêt du rollback : personne n'a perdu l'accès, pas même sans le skill.

Coût et mode d'emploi

Le skill est plus lent et environ trois fois plus cher : 1.87 $ contre 0.62 $ par run. Ce qui reste réellement utile, c'est un fail2ban qui bannit effectivement sur un serveur en production (6 sur 15 sans le skill, 15 sur 15 avec), un pare-feu activé et zéro auto-bannissement.

En pratique : avant la première modification de SSH, vérifiez que l'agent a exécuté `vps-forge-deadman arm`. Si ce n'est pas le cas, le skill ne s'est pas chargé et il n'y a aucun filet de sécurité. Le script fonctionne aussi sans agent, et vous pouvez le tester à la main sur un serveur dont vous n'avez pas besoin : l'armer pour une minute, y mettre `AllowUsers deploy`, constater que la connexion est bloquée, puis attendre le statut ROLLED BACK.

Un snapshot chez le fournisseur et l'accès à la console restent de toute façon nécessaires. RHEL n'est pas encore pris en charge, et le skill ne touche pas aux nœuds Kubernetes. Le code est sous licence MIT, sans télémétrie, et le banc d'essai se trouve dans le répertoire bench/ du dépôt mountain-beaver/vps-forge.