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 es 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
• un 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, mientras que las imágenes de servidor de Ubuntu usan netplan con systemd-networkd. Por eso, la página falta o aparece vacía. No instale NetworkManager en un equipo remoto para recuperarla, porque toma el control de la interfaz y un error también le hace perder la sesión SSH. Los controles de firewall de Cockpit son una interfaz para firewalld, mientras que Ubuntu usa ufw. Por eso, no obtiene ningún control del firewall. Debe seguir ejecutando sudo ufw status en un terminal.

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

• configuración de Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL y Samba mediante formularios
• usuarios, grupos y cuotas de disco
• tareas de cron y el reloj del sistema
• actualizaciones de paquetes, además de un gestor de archivos con carga 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 envían un cambio a otros servidores Webmin

La mayoría de los formularios de Webmin editan los archivos reales de /etc y no utilizan una base de datos oculta. Por tanto, si /etc está bajo control de versiones, sudo git -C /etc diff después de guardar un formulario muestra lo que el módulo escribió allí. No muestra las acciones que ejecutan un comando o SQL, como hacen los módulos de MariaDB y PostgreSQL, ni las escrituras en archivos fuera de /etc. Dentro de esos límites, es la forma más rápida de saber qué hace realmente una página de Webmin. La guía de instalación y primer inicio de sesión de Webmin explica detalladamente el árbol de módulos. Virtualmin y Usermin son productos independientes basados en el mismo motor: uno está destinado al alojamiento compartido y el otro a los usuarios finales. Ambos 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 distribuye mediante los paquetes de tu 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 cockpit muestra la versión instalada y el repositorio del que procede. Si se ejecuta sin nombre de paquete, apt policy muestra sólo la prioridad de cada origen. Si backports no contiene una compilación más reciente, apt usa 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ías.

Webmin no está incluido en el archivo de paquetes de Ubuntu. La instalación oficial añade primero el repositorio propio de Webmin y su clave de firma:

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

Lee ese script antes de ejecutarlo, porque se ejecuta como root. A partir de ese momento, cada apt upgrade ejecutado en el servidor también obtiene paquetes del repositorio de Webmin. Por tanto, has añadido un segundo editor con confianza de nivel root en el sistema. Ese es el coste real de Webmin, y conviene explicarlo con un ejemplo concreto: 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 no tienes 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 permiten acceder como root, por lo que una contraseña adivinada o reutilizada implica el compromiso completo del servidor.

El patrón seguro consiste en asociar el panel a localhost y acceder a él mediante un túnel SSH. Para Cockpit, sustituya la unidad de 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 los ajustes de 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 sigue siendo público. Aplique la sustitución 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 sustitución no se aplicó. Ahora abra el túnel desde su propio equipo y navegue a https://localhost:9090:

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

El puerto local no tiene que coincidir con el remoto. Cockpit construye el origen esperado a partir de la cabecera Host que envía el navegador, por lo que un túnel desde el puerto local 9999 abierto en https://localhost:9999 supera la misma comprobación, porque las cabeceras Host y Origin del navegador indican la misma dirección. La comprobación falla cuando algo entre el navegador y Cockpit cambia Host, por ejemplo, un proxy inverso que no reenvía la cabecera original. La página de inicio de sesión se carga, pero el inicio de sesión falla, y cockpit-ws registra received request from bad Origin. Esa línea está en el journal de las unidades cockpit-wsinstance-https@, no en cockpit.service, así que debe leerla con sudo journalctl -u 'cockpit-wsinstance-https@*'. Para aceptar una dirección pública distinta de la que ve Cockpit, indíquela en /etc/cockpit/cockpit.conf:

[WebService]
Origins = https://panel.example.com

Reinicie con sudo systemctl restart cockpit para aplicar ese ajuste. En Webmin, el ajuste 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 peticiones que parecen proceder de otro host, que es lo que rompe un primer intento con un proxy inverso. La línea referers= de /etc/webmin/config es donde se permite el nombre de host del proxy, y webprefix= en ese mismo archivo indica que Webmin está disponible bajo una ruta.

La otra opción es un proxy inverso 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 encaja

Un panel es específico de cada servidor y requiere intervención manual. Además, no deja constancia de qué cambió ni por qué. Esto es suficiente para un equipo. Con cinco equipos, repite el trabajo. Con veinte, tiene que adivinar qué servidor no recibió el cambio. Cockpit puede añadir otros hosts a una sesión mediante SSH, pero ese selector de hosts está obsoleto desde Cockpit 322. Además, su valor predeterminado depende de la distribución. Si está desactivado, debe habilitar AllowMultiHost=yes en /etc/cockpit/cockpit.conf. Incluso habilitado, sigue obligándole a aplicar el mismo cambio cinco veces mediante clics.

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. Un primer playbook de Ansible aplica la misma regla de firewall a todos los hosts desde un único archivo que puede revisar como diff. El trabajo con contenedores sigue el mismo enfoque: ejecutar docker compose up -d mediante SSH desde un archivo almacenado en git, como se explica en la guía básica de Docker Compose, es mejor que usar cualquier panel. Además, Cockpit no administra Docker.

Use un panel para las tareas que resultan difíciles 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 permite autenticación mediante clave. 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 de privilegios.

Cockpit no muestra las páginas Networking ni Firewall. Esas páginas requieren 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 problema, y la solución es seguir usando ufw mediante SSH.

La página de inicio de sesión de Cockpit se carga detrás de un proxy, pero el inicio de sesión falla. El proxy modificó la cabecera Host, por lo que falla la comprobación Origin y sudo journalctl -u 'cockpit-wsinstance-https@*' muestra received request from bad Origin. Reenvíe el Host original, o establezca Origins en /etc/cockpit/cockpit.conf. Un túnel SSH directo no causa este problema, independientemente del puerto local que elija.

Los envíos de formularios de Webmin fallan después de colocarlo detrás de un proxy. La comprobación Referer los rechaza. Añada el nombre de host del proxy a referers= en /etc/webmin/config, y establezca webprefix= en ese archivo cuando el panel se sirva 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.