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

Un agent avec root sur un VPS tout neuf installe fail2ban, vérifie la connexion par clé, essaie un mot de passe et, au cinquième échec, bannit l'IP d'où viennent les tests. Autrement dit, 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 aucune consigne, s'est banni lui-même dans 7 exécutions sur 60. Le modèle est intelligent ; simplement, personne ne lui a 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 de 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 « soyez 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 active, mais la nouvelle connexion est déjà fermée : par exemple `AllowUsers deploy` là où vous êtes admin, ou un AllowGroups dans lequel on a oublié de vous ajouter.

Les agents ont leur propre piège. Ils maintiennent 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 impossible de se connecter. La consigne « vérifie la connexion depuis une nouvelle connexion » n'y change 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 instantané des configurations et crée un minuteur systemd de 5 minutes. L'agent modifie la configuration, se reconnecte avec `ssh -o ControlPath=none` et, si la connexion réussit, fait un disarm. Sinon, il n'a rien à faire : au bout de 5 minutes, le minuteur remet tout comme avant.

Sur le papier, c'était 20 lignes de bash ; il en est sorti plusieurs centaines. Presque chaque ligne correspond à une panne :

• Redémarrage. Le 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, détecte l'état « armé mais non désarmé » et effectue elle-même le rollback.
• nftables. Le rollback arrêtait un service qui était désactivé avant arm, et son ExecStop contenait `nft flush ruleset`. Avec la règle voulue, ufw, les bans de fail2ban et les chaînes Docker disparaissaient. Désormais, seules les tables de la configuration restauré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 revenaient, 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 donc prise 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 ne peut pas être restauré, car il est hors du serveur. Là, seul l'ordre compte : ajouter d'abord la nouvelle règle, vérifier la connexion, puis retirer l'ancienne.

Les pièges des images cloud et le benchmark

Le plus sournois, c'est cloud-init. Sur de nombreux VPS se trouve un `50-cloud-init.conf` avec `PasswordAuthentication yes`. sshd retient la première valeur lue, et les fichiers sont lus par ordre alphabétique : le conseil courant du `99-hardening.conf` ne sert donc à rien. Le fichier du skill s'appelle `00-vps-forge.conf`, et le résultat est vérifié via `sshd -T`. Autres points : Debian 12 n'a pas d'auth.log, Docker publie des ports en contournant ufw, l'image d'Oracle Cloud embarque sa propre règle REJECT dans iptables, et Coolify se connecte à son propre hôte en SSH sous root, si bien 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 trois fois sans le skill et avec — 120 exécutions d'Opus 5.5. Un juge vérifie le serveur depuis l'extérieur, avant et après redémarrage. Sans le skill : 79–92 points sur 100 ; avec : 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
• Bruteforce de mots de passe 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 reconnaît honnêtement les points faibles. Un serveur vierge obtient 25–42 points. Environ 70 % de l'écart viennent 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 à la mise au point du skill. Il n'y a qu'un seul modèle, plus quatre exécutions manuelles de GLM-5.3. Le benchmark n'a pas prouvé le rollback : personne n'a perdu l'accès, y compris sans le skill.

Prix et mode d'emploi

Le skill est plus lent et environ trois fois plus cher : $1.87 contre $0.62 par exécution. Ce qui reste de vraiment utile, c'est un fail2ban qui bannit réellement sur un serveur en service (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` ; sinon, le skill n'a pas été chargé et il n'y a aucun filet de sécurité. Le script fonctionne aussi sans agent ; on peut le tester à la main sur un serveur sans importance : l'armer pour une minute, écrire `AllowUsers deploy`, constater que la connexion est fermée et attendre le statut ROLLED BACK. Un instantané chez l'hébergeur et l'accès à la console restent indispensables. 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.