# Añadir servidores

> Da de alta servidores en InfraWard, elige el modo de acceso, entiende qué cambia el script y da de baja un servidor sin dejar rastro.

InfraWard no usa agentes. Llega a cada servidor por SSH con una cuenta dedicada de solo lectura que crea el script de alta. Solo das de alta las máquinas de primer nivel: un nodo Proxmox, un host Docker o Podman, un servidor Plesk o un Linux normal. Lo que contienen (CT, VMs, contenedores, imágenes, sitios) se descubre solo.

Dar de alta un servidor requiere el permiso `assets.write` (roles Admin y Editor).

## Antes de empezar

Comprueba que el servidor cumple los [requisitos de los servidores gestionados](/es/docs/requirements.md#servidores-gestionados): OpenSSH con `sshd_config.d`, `sudo` (o deja que lo instale el script), `python3` y el reloj sincronizado. El worker de InfraWard tiene que llegar al servidor por su puerto SSH.

## 1. Genera el comando

Ve a **Inventario → Añadir servidor**.

[Captura: Formulario Añadir servidor: dirección y puerto SSH, modo de acceso, opciones y organización]

1. **Servidor**: la IP o el hostname con el que el worker llegará al servidor, el puerto SSH (22 por defecto) y un nombre opcional.

2. **Acceso**: cómo entra InfraWard.

   | Modo | Cómo funciona | Cuándo usarlo |
   |---|---|---|
   | **Certificados de vida corta (CA SSH de OpenBao)** | No se instala ninguna clave. sshd confía en la CA de InfraWard solo para el usuario `inventory`. Cada trabajo obtiene un certificado válido durante 5 minutos. | Por defecto y recomendado. Requiere OpenBao. |
   | **Clave estática** | InfraWard genera un par de claves ed25519, guarda la privada en el proveedor de secretos e instala la pública en `authorized_keys` con `restrict`. | Sin OpenBao, o cuando no puedes tocar la configuración de sshd. Permite además el alta manual. |

3. Opciones:

   - **Instalar sudo si falta (`--install-sudo`)**: el script instala `sudo` con el gestor de paquetes del sistema. Necesario en Proxmox VE. Con esta opción, el comando se ejecuta como root, sin `sudo`.
   - **Permitir acceso interactivo de administración**: solo para administradores y en modo con certificados. Crea la cuenta `infraward-admin`, que usa la [terminal web](/es/docs/terminal.md). Puedes retirarla después desde la ficha del servidor.

4. **Organización y política** (opcional): etiquetas, proyectos, una plantilla de política y exclusiones del escaneo. Se aplican antes de la primera recolección y del primer escaneo, lo que sirve para dejar un servidor fuera del escaneo desde el principio.

5. Pulsa **Generar comando de alta**.

## 2. Ejecuta el comando en el servidor

La página muestra el comando, cuándo caduca y dos pestañas.

[Captura: Comando de alta de docker-01 con las pestañas Por URL y Script embebido]

**Por URL (por defecto)**

El servidor descarga el script de InfraWard y avisa cuando termina:

```bash
curl --proto =https --proto-redir =https -fsSL --max-time 120 https://infraward.example.com/api/enroll/<token> | sudo bash
```

En un servidor sin `sudo` (por ejemplo, Proxmox VE), ejecútalo como root con la opción:

```bash
curl --proto =https --proto-redir =https -fsSL --max-time 120 https://infraward.example.com/api/enroll/<token> | bash -s -- --install-sudo
```

El token es de un solo uso y caduca a los 20 minutos por defecto (`ENROLLMENT_TOKEN_TTL`, entre 15 y 30 minutos). Solo se guarda su hash. Si caduca, pulsa **Generar comando nuevo**.

Con una URL `https`, `--proto =https --proto-redir =https` impide que `curl` siga una redirección a HTTP sin cifrar, donde cualquiera en el camino podría cambiar un script que se ejecuta como root. `--max-time 120` evita que se quede colgado. Al avisar a InfraWard, el script también usa solo HTTPS si la URL de la API es `https`.

**Script embebido (VPN/NAT)**

Para servidores que no llegan a InfraWard. El script entero va en el comando, comprimido y en base64, y no lleva token:

```bash
echo '<script en base64>' | base64 -d | gunzip | sudo bash
```

El script imprime las huellas SHA256 de las host keys del servidor. Pégalas en InfraWard para terminar el alta. El worker sigue necesitando llegar al servidor por SSH.

**Alta manual** (solo con clave estática): en lugar de ejecutar el script, añade la clave pública que muestra InfraWard al `authorized_keys` de una cuenta existente (nunca `root`) y pulsa **Ya lo he añadido**. Sin el script no hay ayudante restringido, así que la recolección se limita a lo que pueda leer esa cuenta.

## 3. Sigue el progreso

La página avanza sola: **Comando generado → Esperando clave → Conectando → Escaneando → Listo**.

[Captura: Progreso del alta: verificación SSH, recolección y descubrimiento completados, escaneo de imágenes en curso]

1. El worker se conecta con `StrictHostKeyChecking=yes` contra las huellas que envió el script. Si no coinciden, rechaza la conexión y no recoge nada.
2. Recolección con Ansible: sistema, paquetes, servicios, puertos en escucha y red.
3. Descubrimiento: CT y VMs de Proxmox; contenedores, imágenes, redes y volúmenes de Docker y Podman; suscripciones de Plesk.
4. Escaneos: un SBOM del servidor y de cada imagen de contenedor, evaluados con Trivy.

En nuestras pruebas, un host Docker con cuatro contenedores tardó unos dos minutos, casi todo en escanear las imágenes. Las imágenes grandes tardan más.

Si un paso falla, la pestaña **Recolecciones** del servidor muestra el log de esa ejecución con el error. Consulta [Logs de las ejecuciones](/es/docs/inventory.md#logs-de-las-ejecuciones).

## Qué cambia el script en el servidor

El script es idempotente: si lo vuelves a ejecutar, actualiza la configuración sin duplicar nada. Solo toca los ficheros de esta tabla.

| Ruta | Modo | Para qué |
|---|---|---|
| Usuario `inventory` | los dos | Cuenta dedicada con shell pero sin contraseña. |
| `/usr/local/libexec/infraward/infraward-query` | los dos | Ayudante de root con una lista cerrada de consultas de solo lectura. Valida cada argumento y ejecuta los comandos sin shell. |
| `/etc/sudoers.d/infraward-inventory` | los dos | Una regla: `inventory` puede ejecutar el ayudante con `sudo -n`. Nunca `ALL`. Se valida con `visudo`. |
| `/etc/infraward/sudoers-version` | los dos | Versión de la regla, para que InfraWard avise cuando haya que actualizarla. |
| `~inventory/.ssh/authorized_keys` | clave estática | Una línea por asset, marcada con `inventory@infraward:<id-del-asset>`, con `restrict`. Se escribe como `inventory`, nunca como root. El script se detiene si `~/.ssh` o `authorized_keys` son un enlace simbólico o pertenecen a otro usuario. |
| `/etc/ssh/sshd_config.d/00-infraward.conf` | certificados | Bloque `Match User inventory`: CA de confianza, fichero de principales, sin TTY y sin reenvíos. Se valida con `sshd -t` y se deshace si falla. |
| `/etc/ssh/infraward/trusted_user_ca_keys` y `/etc/ssh/infraward/principals/inventory` | certificados | Clave pública de la CA de InfraWard y el único principal aceptado. |
| Usuario `infraward-admin`, `/etc/ssh/sshd_config.d/01-infraward-admin.conf`, `/etc/sudoers.d/infraward-admin` | acceso de administración | Cuenta de la terminal web. Solo acepta certificados de la CA con el principal `infraward-operators`; ni claves ni contraseña. |
| `/etc/infraward/podman-users` | ambos, opcional | Usuarios de Podman rootless que InfraWard puede consultar. Solo se escribe con `--podman-users`; lo normal es que lo escriba después **Habilitar** (consulta [Podman](#podman)). |

El `sshd_config` principal no se modifica nunca. Si `sshd_config` limita los usuarios con `AllowUsers` o `AllowGroups` y deja fuera a `inventory`, el script avisa y no cambia nada.

> **Nodos Proxmox, hosts Docker y Podman como root**
>
> En estos hosts el ayudante restringido limita menos de lo que parece. Para recoger los CT, InfraWard usa `pct exec`, que es root dentro del CT, y un CT privilegiado no aísla del host. En los hosts Docker, el ayudante solo permite consultas de lectura y `docker save` de una imagen, pero `docker inspect` muestra la configuración de los contenedores, variables de entorno incluidas. No añadas nunca `inventory` al grupo `docker`. Podman como root (`podman` con root) equivale a lo mismo; los usuarios rootless de `/etc/infraward/podman-users` solo exponen sus propios contenedores.

## Comprueba el resultado en el servidor

```bash
sudo -l -U inventory
sudo sshd -T -C user=inventory,host=localhost,addr=127.0.0.1 | grep -Ei 'trustedusercakeys|authorizedprincipalsfile'
```

## Notas por plataforma

- **Proxmox VE**: da de alta el nodo con `--install-sudo`. Los CT se descubren y se recogen desde el nodo con `pct exec`; instala `python3` en cada CT que quieras recoger. Las VMs se descubren desde el nodo; para recoger su contenido, da de alta cada VM como servidor.
- **Docker**: se descubren contenedores, imágenes, redes y volúmenes. Las imágenes se exportan con `docker save` y se escanean en el worker, así que nunca se ejecutan.
- **Podman**: consulta [más abajo](#podman).
- **Plesk**: se descubren suscripciones, dominios, bases de datos y certificados. Las consultas de Plesk nunca leen contraseñas ni claves privadas.

## Podman

Los hosts con Podman reciben el rol `podman-host`. InfraWard usa el comando nativo `podman`, así que no hace falta `podman-docker` ni un socket de root, y un mismo host puede tener Docker y Podman a la vez.

- **Podman como root**: los contenedores, imágenes, volúmenes y redes se inventarían igual que los de Docker. Los pods y los contenedores de quadlet o de systemd se ven en cada contenedor (el contenedor *infra* del pod no se inventaría). Las imágenes se exportan con `podman save` y se escanean en el worker, y la terminal web se abre en estos contenedores.
- **Podman rootless**: cada recolección detecta, en modo lectura, los usuarios que usan Podman (contenedores en marcha, un socket de usuario activo o almacén de contenedores en su home). Aparecen en la tarjeta **Usuarios de Podman** del servidor con uno de tres estados: **Inventariado**, **Sin socket** o **Sin habilitar**. Los detectados sin habilitar y los habilitados sin socket activo generan además un aviso en el servidor.

Detectar un usuario no habilita nada. Para inventariar sus contenedores, pulsa **Habilitar** en esa tarjeta. InfraWard ofrece dos formas de ejecutar el mismo script, que activa linger y el `podman.socket` del usuario y lo añade a `/etc/infraward/podman-users`, el consentimiento del lado del servidor:

| Opción | Cuándo |
|---|---|
| Copiar el comando y ejecutarlo con cualquier cuenta con `sudo` | Siempre. |
| **Ejecutar con infraward-admin** | El servidor tiene el acceso de administración y puedes abrir una terminal en él. Abre una [terminal de solo lectura](/es/docs/terminal.md#acciones-de-solo-lectura) que muestra el comando y su salida. |

Después vuelve a recolectar el servidor. Los contenedores de esos usuarios aparecen con su propietario (`alice/web`). InfraWard consulta el socket de cada usuario ejecutando el cliente de Podman como ese usuario, nunca como root.

Para fijar la lista a mano en el alta, añade `--podman-users` al comando, por ejemplo `curl … | sudo bash -s -- --podman-users=alice,bob`. `--podman-users=` la vacía; sin la opción, la lista no se toca.

Podman necesita la versión 8 del sudoers (InfraWard 0.6.0). En un host con Podman dado de alta con una versión anterior, el servidor muestra **sudoers desactualizado** y no se inventaría nada de Podman: regenera el comando y vuelve a ejecutarlo.

## Mantenimiento

En la ficha del servidor, InfraWard avisa cuando la regla de sudoers o las claves de la CA instaladas en el servidor están desactualizadas. Usa **Regenerar el comando** y ejecuta el comando nuevo: actualiza el servidor sin darlo de baja.

Un servidor dado de alta con clave estática puede pasar a certificados con **Pasar a certificados (CA)**. Ejecuta el comando que genera; el script quita la clave estática solo cuando sshd ya acepta certificados, e InfraWard borra la clave privada del proveedor de secretos en cuanto el worker conecta con un certificado.

## Dar de baja un servidor

| Acción | Efecto |
|---|---|
| **Retirar**, en el acceso de administración | Elimina `infraward-admin` y sus ficheros de sshd y sudoers. El servidor sigue en el inventario. |
| **Dar de baja** | Reversible. El asset pasa a retirado, se cancelan las altas pendientes y se borra la clave estática del proveedor de secretos. InfraWard muestra un comando de limpieza. |
| **Purgar** | Definitivo. Borra el asset, su historial y sus hallazgos. Solo admin, con reautenticación. |

Ejecuta en el servidor el comando de limpieza que muestra InfraWard. Quita la línea del asset de `authorized_keys`, la confianza en la CA y la cuenta de administración (en modo con certificados) y, si ningún otro asset de InfraWard los usa, la regla de sudoers, el ayudante y el usuario `inventory`. sshd solo se recarga si `sshd -t` es correcto.

---

Página HTML: https://infraward.net/es/docs/enrollment/