Cockpit o Webmin: diferencias para administrar servidores

Cockpit frente a Webmin: respuesta breve

Cockpit y Webmin son paneles web para administrar un servidor Linux desde un navegador, pero responden a necesidades distintas. Cockpit se distribuye en el repositorio de la propia distribución y consulta el equipo mediante systemd, journald, polkit y udisks. Por eso muestra un servidor que sigue administrándose mediante SSH. Webmin es más antiguo y mucho más amplio: escribe archivos de configuración para Apache, BIND, Postfix, MariaDB y muchas otras aplicaciones que Cockpit nunca modifica. Para hacerlo, ejecuta su propio servidor web como root.

Instale Cockpit si necesita una vista en tiempo real de un equipo, un visor de registros y un terminal de emergencia. Instale Webmin si necesita un editor basado en formularios para un servicio que no quiere configurar manualmente. No exponga ninguno de los dos en un puerto público con inicio de sesión mediante contraseña. Si ya administra más de dos o tres servidores, la respuesta más realista suele ser ninguno: la combinación de SSH y Ansible escala mejor que cualquier panel.

Qué puede cambiar realmente cada panel

La instalación base de Cockpit es pequeña y la mayoría de las áreas son paquetes independientes que puede omitir:

• servicios y temporizadores de systemd: iniciar, detener, habilitar y leer el archivo de unidad
• el journal, filtrado por unidad y prioridad, que está journalctl con un selector de fecha
• cuentas locales, pertenencia a grupos y claves SSH autorizadas
• almacenamiento con cockpit-storaged: particiones, grupos de volúmenes LVM, sistemas de archivos y puntos de montaje
• contenedores con cockpit-podman, que sólo administra Podman
• actualizaciones de paquetes con cockpit-packagekit
• gráficos de CPU, memoria, disco y red con cockpit-pcp
• una terminal de root en la pestaña del navegador

Dos áreas parecen no funcionar en un VPS con Ubuntu, pero no es así. La página Networking de Cockpit es una interfaz para NetworkManager, y las imágenes de servidor de Ubuntu usan netplan con systemd-networkd, por lo que la página no aparece o está vacía. No instale NetworkManager en un equipo remoto para recuperarla, porque tomará el control de la interfaz y un error también le hará perder la sesión SSH. Los controles de firewall de Cockpit son una interfaz para firewalld, y Ubuntu usa ufw, por lo que no tendrá ningún control de firewall. Seguirá ejecutando sudo ufw status en una terminal.

Webmin cubre muchas más funciones, porque es una colección de módulos independientes para cada servicio, no un único programa:

• configuración de Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL y Samba mediante formularios
• usuarios, grupos y cuotas de disco
• trabajos de cron y el reloj del sistema
• actualizaciones de paquetes, además de un gestor de archivos con subida y descarga
• interfaces para firewalls, incluida una para iptables y otra para firewalld
• copias de seguridad de archivos de configuración y módulos de clúster que aplican un cambio en otros servidores Webmin

Webmin edita los archivos reales de /etc. No hay una base de datos oculta detrás de los formularios, así que si /etc está bajo control de versiones, sudo git -C /etc diff después de guardar un formulario muestra exactamente lo que escribió el módulo. Es la forma más rápida de saber qué hace realmente cualquier página de Webmin. Guía de instalación y primer inicio de sesión de Webmin explica en detalle el árbol de módulos. Virtualmin y Usermin son productos independientes basados en el mismo motor, destinados al alojamiento compartido y a los usuarios finales, respectivamente, y heredan todo lo indicado aquí sobre la exposición.

Cómo se autentica cada uno

Cockpit no tiene una base de datos de usuarios. Su página de inicio de sesión ejecuta la pila PAM (módulos de autenticación conectables) en /etc/pam.d/cockpit, por lo que las cuentas son sus cuentas de Unix y las contraseñas son sus contraseñas de Unix. Root se rechaza de forma predeterminada porque /etc/cockpit/disallowed-users lo incluye. Las acciones con privilegios pasan por polkit y la interfaz vuelve a solicitar la contraseña antes de cambiar cualquier cosa. Por eso el encabezado de la página puede mostrar «Acceso limitado» hasta que se eleven los privilegios.

Este diseño tiene una consecuencia habitual en un sistema reforzado. Si siguió inicio de sesión SSH sólo con claves y autenticación mediante contraseña deshabilitada, la cuenta puede no tener ninguna contraseña utilizable. En ese caso, el inicio de sesión en Cockpit se rechaza, mientras ssh sigue funcionando. Compruébelo en el servidor:

sudo passwd -S deploy

Una salida que comienza por deploy L indica que la contraseña está bloqueada. PAM no tiene ninguna contraseña que aceptar y ninguna contraseña que escriba puede funcionar. P indica que hay una contraseña utilizable configurada. La propia página de inicio de sesión de Cockpit no acepta claves SSH. Las claves sólo se usan cuando Cockpit se conecta desde el equipo en el que inició sesión a otro host.

Webmin mantiene sus propios usuarios en /etc/webmin/miniserv.users, separados de /etc/passwd, y también se puede configurar para autenticarse con cuentas de Unix. Un usuario de Webmin al que se hayan concedido todos los módulos tiene privilegios de root en ese equipo, independientemente de lo que indique su shell de inicio de sesión. Webmin incluye compatibilidad propia con TOTP (contraseña de un solo uso basada en el tiempo) y bloqueo propio de hosts después de varios inicios de sesión fallidos. Ambas funciones se activan en Webmin Configuration. Cockpit sólo obtiene un segundo factor si se añade uno a PAM, por ejemplo mediante libpam-google-authenticator.

Cómo se actualiza cada uno

Cockpit se incluye en los repositorios de la distribución. En Ubuntu 24.04 procede del archivo de paquetes, y el proyecto upstream recomienda el repositorio backports para obtener una compilación más reciente:

. /etc/os-release
sudo apt update
sudo apt install -t ${VERSION_CODENAME}-backports cockpit
sudo systemctl status cockpit.socket
apt policy cockpit

apt policy muestra la versión instalada y el repositorio del que procede. Si backports no contiene una compilación más reciente, apt vuelve a la versión del archivo de paquetes, lo cual es correcto. cockpit.socket debería mostrar active (listening). Las correcciones de seguridad llegan entonces mediante la misma ejecución de unattended-upgrades que actualiza el kernel, desde un editor en el que ya confía.

Webmin no se encuentra en el archivo de paquetes de Ubuntu. La instalación oficial añade primero el repositorio y la clave de firma propios de Webmin:

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh
sudo apt-get install webmin --install-recommends

Lea ese script antes de ejecutarlo, porque se ejecuta como root. A partir de ese momento, cada apt upgrade en el servidor también obtiene paquetes del repositorio de Webmin. Por tanto, ha añadido un segundo editor con confianza de nivel root en el sistema. Ese es el coste real de Webmin y merece un ejemplo claro: CVE-2019-15107 era una puerta trasera presente en varios paquetes 1.9x que permitía ejecutar comandos sin autenticación. Llegó a los usuarios porque el host de compilación del proyecto fue comprometido, no porque lo fuera su repositorio de código fuente. El empaquetado de la distribución no hace que esto sea imposible. Sí añade un paso de compilación y revisión que usted no tiene que mantener personalmente.

Por qué ninguno debe estar en un puerto público

Cockpit escucha en TCP 9090 y Webmin en TCP 10000, ambos mediante TLS (seguridad de la capa de transporte) con un certificado autofirmado, por lo que lo primero que verá es una advertencia del navegador. Crear y confiar en un certificado autofirmado explica qué indica esa advertencia y qué no indica. Ambos puertos se escanean constantemente y ambos paneles proporcionan acceso a root, por lo que una contraseña adivinada o reutilizada permite comprometer por completo el servidor.

El patrón seguro consiste en vincular el panel a localhost y acceder a él mediante un túnel SSH. En Cockpit, sobrescriba la unidad socket:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

La línea vacía ListenStream= es obligatoria. systemd añade contenido a las opciones de tipo lista, por lo que, sin ella, la unidad conserva el 0.0.0.0:9090 original y añade la nueva dirección. El panel seguiría siendo público. Aplique la sobrescritura y compruebe qué está escuchando:

sudo systemctl daemon-reload
sudo systemctl restart cockpit.socket
sudo ss -lntp | grep 9090

La salida debe mostrar 127.0.0.1:9090. Una dirección *:9090 o 0.0.0.0:9090 significa que la sobrescritura no se aplicó. Ahora abra el túnel desde su propio equipo y acceda a https://localhost:9090:

ssh -N -L 9090:127.0.0.1:9090 deploy@203.0.113.10

Mantenga el puerto local igual que el puerto remoto. Cockpit compara la cabecera Origin del navegador con la dirección en la que cree que está funcionando. Por eso, un túnel desde el puerto local 9999 carga la página de inicio de sesión y después falla al iniciar sesión. journalctl -u cockpit registra el origen rechazado. Si necesita otro puerto local, indíquelo en /etc/cockpit/cockpit.conf:

[WebService]
Origins = https://localhost:9999 https://127.0.0.1:9999

Reinicie con sudo systemctl restart cockpit.socket para aplicar ese cambio. En Webmin, la configuración equivalente se encuentra en /etc/webmin/miniserv.conf:

bind=127.0.0.1

sudo systemctl restart webmin
sudo ss -lntp | grep 10000
ssh -N -L 10000:127.0.0.1:10000 deploy@203.0.113.10

Webmin también comprueba la cabecera Referer en los envíos de formularios y rechaza las solicitudes que parecen proceder de otro host. Esto es lo que hace que falle un primer intento de usar un reverse proxy. La línea referers= del mismo archivo permite el nombre de host del proxy y webprefix= indica a Webmin que funciona bajo una ruta.

La otra opción es un reverse proxy autenticado: nginx delante y una capa de inicio de sesión único de Authentik para gestionar el inicio de sesión. Funciona, pero es la segunda mejor opción. El panel sigue ejecutándose como root detrás del proxy y ahora debe mantener dos puntos de entrada en lugar de uno. Un túnel no añade ningún servicio que escuche en Internet y reutiliza la clave SSH que ya protege.

Qué panel elegir en un servidor que ya ejecuta servicios en producción

Cockpit, por dos motivos importantes cuando otras personas dependen de la máquina. Se activa mediante sockets, por lo que cockpit-ws sólo se ejecuta mientras hay una sesión abierta y no queda un daemon root permanente esperando en un puerto. Además, no administra ningún servicio: elimine el paquete y todos los servicios seguirán funcionando exactamente igual que antes, porque Cockpit no almacena ninguna configuración propia. miniserv.pl de Webmin permanece residente tanto si hay usuarios conectados como si no. Compruebe el consumo del suyo con systemctl status webmin, que muestra la memoria residente del proceso en ejecución.

Si necesita los módulos DNS o de correo de Webmin, asígneles un servidor propio. Un servidor con Webmin que realiza una sola función y está vinculado a 127.0.0.1 limita el riesgo. Webmin compartiendo un host con su aplicación orientada a clientes no lo limita. Realice primero la configuración básica antes de instalar cualquiera de los dos paneles: los primeros diez minutos en un VPS nuevo explica cómo crear el usuario que no es root y configurar el firewall que ambos paneles dan por existentes.

Cuando ninguna de las dos opciones es adecuada

Un panel es específico para cada servidor y requiere intervención manual. No deja constancia de qué cambió ni por qué. Esto funciona para un solo equipo. Con cinco equipos, repite la misma tarea. Con veinte, tiene que adivinar qué servidor no recibió el cambio. Cockpit puede añadir otros hosts a una sesión mediante SSH, pero las versiones recientes desactivan esta función de forma predeterminada y requieren AllowMultiHost=yes en /etc/cockpit/cockpit.conf. Además, seguirá teniendo que hacer clic cinco veces para aplicar el mismo cambio.

La alternativa es usar SSH directamente y guardar la configuración en un repositorio de git. Administrar varios servidores Linux desde un solo lugar explica la estructura de esta configuración, y el primer playbook de Ansible aplica la misma regla de firewall a todos los hosts desde un archivo que puede revisar como un diff. El trabajo con contenedores sigue el mismo principio: docker compose up -d mediante SSH desde un archivo almacenado en git, como se muestra en la guía básica de Docker Compose, es mejor que hacer clic en cualquier panel. Además, Cockpit no administra Docker.

Use un panel para las tareas que resultan poco prácticas en un terminal, como leer un gráfico de métricas o identificar cuál de cuarenta unidades falló. Use código para cualquier tarea que vaya a realizar más de dos veces.

Modos de fallo y cadenas que verá

Cockpit rechaza una contraseña que SSH acepta. La cuenta sólo usa claves. sudo passwd -S alice muestra L en el segundo campo, por lo que PAM no tiene ninguna contraseña que comprobar. Establezca una con sudo passwd alice o mantenga esa cuenta para SSH e inicie sesión en Cockpit con otro usuario.

Cockpit rechaza root incluso con la contraseña correcta. /etc/cockpit/disallowed-users muestra root. Inicie sesión con un usuario normal que tenga permisos de sudo. Esta es la ruta prevista, porque polkit registra qué usuario realizó la elevación.

Cockpit no muestra las páginas Networking o Firewall. Esas páginas necesitan NetworkManager y firewalld. Un VPS de Ubuntu usa netplan con systemd-networkd y ufw, por lo que las páginas no aparecen. No hay ningún fallo; la solución es seguir usando ufw mediante SSH.

La página de inicio de sesión de Cockpit se carga mediante el túnel, pero el inicio de sesión falla. El puerto local es distinto del puerto remoto, por lo que la comprobación de Origin falla y journalctl -u cockpit lo muestra. Haga coincidir los puertos o establezca Origins en /etc/cockpit/cockpit.conf.

Los envíos de formularios de Webmin fallan después de colocarlo detrás de un proxy. La comprobación de Referer los rechaza. Añada el nombre de host del proxy a referers= en /etc/webmin/miniserv.conf y establezca webprefix= cuando el panel se publique bajo una ruta.

No está seguro de si un panel está expuesto. sudo ss -lntp | grep -E '9090|10000' responde a esa pregunta desde el propio servidor, y Webmin escribe cada intento de inicio de sesión en /var/webmin/miniserv.log. Conviene revisar ese archivo una vez después de cualquier cambio en la forma en que el panel escucha.

FAQ

¿Es mejor Cockpit o Webmin para un único VPS con Ubuntu?

Para la mayoría de los usuarios, Cockpit, porque procede del repositorio oficial de Ubuntu, recibe parches junto con el resto del sistema y sólo se ejecuta mientras hay una sesión del navegador abierta. Elija Webmin cuando necesite un editor basado en formularios para un servicio que Cockpit no gestione, como BIND o Postfix, y acepte a cambio que su servidor web se ejecuta siempre como root y que sus actualizaciones proceden del repositorio propio de Webmin.

¿Puedo ejecutar Cockpit y Webmin en el mismo servidor?

Sí. Usan puertos distintos, 9090 y 10000, y no entran en conflicto porque cada uno modifica directamente el sistema en lugar de administrarlo en exclusiva. Aun así, no es una buena compensación. Cada panel es otro acceso con capacidad para root en la misma máquina, por lo que duplica la superficie de exposición para ahorrar unos pocos clics. Si instala ambos, vincule ambos a 127.0.0.1 y acceda a ellos mediante un túnel SSH.

¿Es seguro abrir el puerto 9090 o 10000 a Internet?

No si se usa un inicio de sesión con contraseña. Ambos paneles permiten acceder a root, y los dos puertos aparecen en escaneos rutinarios pocas horas después de abrirlos. Vincule el panel a 127.0.0.1, ejecute después ssh -N -L 9090:127.0.0.1:9090 user@host y acceda a https://localhost:9090. Confírmelo con sudo ss -lntp | grep 9090, que debe mostrar 127.0.0.1:9090 en lugar de 0.0.0.0:9090. Un reverse proxy autenticado es una segunda opción aceptable.

¿Por qué falla mi inicio de sesión en Cockpit si SSH funciona con una clave?

Cockpit autentica mediante PAM con una contraseña de Unix, y su página de inicio de sesión no acepta claves SSH. En un servidor reforzado, la cuenta a menudo no tiene una contraseña utilizable. Ejecute sudo passwd -S youruser: un L en el segundo campo indica que la contraseña está bloqueada, por lo que PAM no tiene nada que aceptar y todos los intentos se rechazan. Establezca una contraseña con sudo passwd youruser o use otra cuenta para el panel.

¿Cockpit administra contenedores Docker?

No. La página de contenedores de Cockpit procede de cockpit-podman y administra Podman. El antiguo módulo de Docker se eliminó hace años y no volverá. Si sus servicios se ejecutan con Docker, adminístrelos mediante un archivo compose bajo control de versiones a través de SSH, y deje que Cockpit gestione el sistema que los rodea, como el journal y los discos.