vps-forge: los agentes con root en un VPS ganan reversión automática y los autobaneos caen de 7 de 60 a 0

Un agente con root en un VPS recién creado instala fail2ban, comprueba el acceso por clave, prueba una contraseña y, al quinto intento fallido, banea la IP desde la que llegan las comprobaciones. Es decir, la suya y la de usted. A partir de ahí, todos los comandos caducan por timeout y usted se pone a buscar la consola web en el panel del proveedor. En el benchmark del autor de vps-forge, Claude Opus 5.5 sin instrucciones adicionales se baneó a sí mismo en 7 de 60 ejecuciones. El modelo es listo; simplemente nadie le dijo que añadiera su dirección a ignoreip antes del primer arranque de fail2ban.

vps-forge es un Agent Skill abierto: un conjunto de instrucciones y scripts de bash que Claude Code, Codex, Cursor y otros agentes cargan cuando se trata de trabajar con un servidor. Se instala con `npx skills add mountain-beaver/vps-forge -g`. Hay un plugin para Claude Code y un archivo zip para Claude.ai.

Por qué «ten cuidado» no funciona

Un sshd_config roto parece funcionar. `sshd -t` no dice nada, el reload se completa y la sesión actual sigue viva, pero el nuevo acceso ya está cerrado: por ejemplo, un `AllowUsers deploy` cuando usted entra como admin, o un AllowGroups al que se olvidó añadirse.

Los agentes tienen su propia trampa. Mantienen una sola conexión mediante ControlMaster, y la comprobación `ssh host true` viaja por el canal antiguo. No afecta al nuevo sshd ni a las nuevas reglas del cortafuegos: la comprobación sale en verde y, sin embargo, no se puede entrar. La instrucción «comprueba el acceso desde una conexión nueva» no sirve de nada si el agente ya ha perdido el acceso. Hace falta un mecanismo que actúe sin él.

El pedal de hombre muerto para sshd

Antes de cada cambio en SSH, el cortafuegos, sudo o PAM, el agente ejecuta `vps-forge-deadman arm`. El script toma una instantánea de las configuraciones y crea un temporizador de systemd de 5 minutos. El agente modifica la configuración, vuelve a entrar con `ssh -o ControlPath=none` y, si el acceso funciona, ejecuta disarm. Si no, no hay que hacer nada: pasados 5 minutos, el temporizador devuelve todo a su estado anterior.

Sobre el papel eran 20 líneas de bash; el resultado final son varios cientos. Casi detrás de cada línea hay un fallo real:

• Reinicio. El temporizador de systemd-run vive en memoria y desaparece junto con el servidor. Ahora arm activa además una unidad que, al arrancar, detecta el estado «armado pero no desarmado» y revierte por sí misma.
• nftables. La reversión detenía un servicio que estaba deshabilitado antes de arm, y su ExecStop contiene `nft flush ruleset`. Junto con la regla necesaria desaparecían ufw, los baneos de fail2ban y las cadenas de Docker. Ahora solo se eliminan las tablas de la configuración que se revierte.
• Localización rusa de ufw. El script buscaba la cadena `Status: active`, pero ufw escribe «Состояние: активен». El cortafuegos se consideraba apagado y se deshabilitaba al revertir. Se soluciona con `LC_ALL=C`.
• Baneo tras la reversión. Las configuraciones volvían, pero la IP seguía baneada. Ahora arm guarda la dirección del cliente SSH y la reversión la desbanea. Bajo sudo no existe la variable SSH_CLIENT, así que la dirección se toma del entorno del proceso padre.

Todo esto se ejecuta en CI: un contenedor con un systemd real, una prueba que rompe sshd, el cortafuegos y fail2ban, reinicia el contenedor en estado armado y comprueba la recuperación. El cortafuegos del panel del proveedor no se puede revertir, porque está fuera del servidor. Ahí solo funciona el orden: primero añadir la nueva regla, comprobar el acceso y después quitar la antigua.

Trampas de las imágenes en la nube y el benchmark

La más traicionera es cloud-init. En muchos VPS hay un `50-cloud-init.conf` con `PasswordAuthentication yes`. sshd toma el primer valor que lee, y los archivos se leen en orden alfabético, así que el popular consejo del `99-hardening.conf` no hace nada. El archivo del skill se llama `00-vps-forge.conf` y el resultado se verifica con `sshd -T`. Hay más: Debian 12 no tiene auth.log, Docker publica puertos esquivando ufw, la imagen de Oracle Cloud trae su propia regla REJECT en iptables, y Coolify se conecta por SSH a su propio host como root, de modo que `PermitRootLogin no` rompe el despliegue.

El banco de pruebas: máquinas virtuales reales en QEMU (Debian 12 y 13, Ubuntu 22.04, 24.04, 26.04), cuatro escenarios, cada uno tres veces sin el skill y con él: 120 ejecuciones de Opus 5.5. El juez comprueba el servidor desde fuera antes y después de reiniciar. Sin el skill, 79–92 puntos sobre 100; con él, 99–100.

• ssh-audit sin fallos: 4/60 sin el skill, 60/60 con él
• Alerta de inicio de sesión por SSH: 16/30 y 30/30
• Cortafuegos activado: 46/60 y 60/60
• La fuerza bruta de contraseñas se banea: 50/60 y 60/60
• Root no puede entrar: 30/60 y 57/60
• El agente se baneó a sí mismo: 7/60 y 0/60
• Pérdida de acceso: 0/60 y 0/60

El autor señala con franqueza los puntos débiles. Un servidor sin tocar obtiene 25–42 puntos. Alrededor del 70% de la diferencia procede de tres comprobaciones que coinciden con los propios ajustes del skill: ssh-audit limpio, prohibición de root y alerta. El juez y el skill los escribió la misma persona, y el Lynis independiente apenas se mueve: 69 y 71, 72 y 72, 64 y 72, 73 y 72. Tres de los cuatro escenarios se usaron para afinar el skill. Solo se probó un modelo, más cuatro ejecuciones manuales de GLM-5.3. El benchmark no demostró la reversión: nadie perdió el acceso, tampoco sin el skill.

Coste y cómo aplicarlo

El skill es más lento y cuesta aproximadamente el triple: $1.87 frente a $0.62 por ejecución. El beneficio real que queda es un fail2ban que banea de verdad en un servidor en funcionamiento (6 de 15 sin el skill, 15 de 15 con él), un cortafuegos activado y cero autobaneos.

En la práctica, funciona así. Antes del primer cambio en SSH, compruebe que el agente ha ejecutado `vps-forge-deadman arm`: si no lo ha hecho, el skill no se cargó y no hay red de seguridad. El script funciona también sin agente y puede probarse a mano en un servidor prescindible: armarlo durante un minuto, poner `AllowUsers deploy`, comprobar que el acceso se ha cerrado y esperar al estado ROLLED BACK. La instantánea del proveedor y el acceso a la consola siguen siendo necesarios. RHEL todavía no está soportado y el skill no toca los nodos de Kubernetes. El código está bajo licencia MIT, sin telemetría, y el banco de pruebas se encuentra en el directorio bench/ del repositorio mountain-beaver/vps-forge.