Cockpit ou Webmin : quel panneau choisir ?

Cockpit ou Webmin : la réponse courte

Cockpit et Webmin sont deux panneaux web qui permettent d’administrer un serveur Linux depuis un navigateur, mais ils répondent à des besoins différents. Cockpit est disponible dans le dépôt de votre distribution et interroge la machine via systemd, journald, polkit et udisks. Il vous présente donc un serveur que vous continuez à administrer avec SSH. Webmin est plus ancien et beaucoup plus complet : il écrit les fichiers de configuration d’Apache, BIND, Postfix, MariaDB et de dizaines d’autres services que Cockpit ne gère jamais. Il exécute pour cela son propre serveur web avec les privilèges de root.

Installez Cockpit si vous voulez une vue en temps réel d’une machine, un lecteur de journaux et un terminal de secours. Installez Webmin si vous avez besoin d’un éditeur à base de formulaires pour un service que vous ne souhaitez pas configurer manuellement. N’exposez ni l’un ni l’autre sur un port public avec une authentification par mot de passe. Si vous administrez déjà plus de deux ou trois serveurs, la réponse honnête est souvent : aucun des deux. La combinaison SSH et Ansible évolue mieux que n’importe quel panneau.

Ce que chaque panneau peut réellement modifier

L’installation de base de Cockpit est légère, et la plupart des fonctionnalités sont fournies par des paquets distincts que vous pouvez ne pas installer :

• services et timers systemd : démarrer, arrêter, activer les unités et lire leur fichier d’unité
• le journal, filtré par unité et par priorité, qui est journalctl avec un sélecteur de date
• comptes locaux, appartenance aux groupes et clés SSH autorisées
• stockage avec cockpit-storaged : partitions, groupes de volumes LVM, systèmes de fichiers et points de montage
• conteneurs avec cockpit-podman, qui gère uniquement Podman
• mises à jour des paquets avec cockpit-packagekit
• graphiques du CPU, de la mémoire, du disque et du réseau avec cockpit-pcp
• un terminal root dans l’onglet du navigateur

Deux fonctionnalités semblent défectueuses sur un VPS Ubuntu, mais ce n’est pas le cas. La page Networking de Cockpit est une interface pour NetworkManager, tandis que les images Ubuntu Server utilisent netplan avec systemd-networkd. La page est donc absente ou vide. N’installez pas NetworkManager sur un serveur distant pour la faire apparaître, car il prend le contrôle de l’interface réseau. Une erreur vous ferait aussi perdre la session SSH. Les commandes de pare-feu de Cockpit sont une interface pour firewalld, tandis qu’Ubuntu utilise ufw. Vous n’avez donc aucun contrôle du pare-feu dans Cockpit. Vous continuez d’exécuter sudo ufw status dans un terminal.

Webmin couvre beaucoup plus de fonctionnalités, car il s’agit d’un ensemble de modules propres à chaque service, et non d’un programme unique :

• configuration d’Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL et Samba au moyen de formulaires
• utilisateurs, groupes et quotas disque
• tâches cron et horloge système
• mises à jour des paquets, ainsi qu’un gestionnaire de fichiers avec envoi et téléchargement
• interfaces de configuration des pare-feu, dont une pour iptables et une pour firewalld
• sauvegardes des fichiers de configuration et modules de cluster qui répercutent une modification sur d’autres serveurs Webmin

Webmin modifie les fichiers réels situés sous /etc. Les formulaires ne s’appuient pas sur une base de données cachée. Si /etc est placé sous gestion de versions, sudo git -C /etc diff après l’enregistrement d’un formulaire montre exactement ce que le module a écrit. C’est le moyen le plus rapide de comprendre ce que fait réellement une page Webmin. Le guide d’installation et de première connexion à Webmin présente en détail l’arborescence des modules. Virtualmin et Usermin sont des produits distincts construits sur le même moteur : le premier est destiné à l’hébergement mutualisé et le second aux utilisateurs finaux. Ils sont donc concernés par tout ce qui est indiqué ici au sujet de l’exposition.

Comment chacun s’authentifie

Cockpit ne possède pas de base de données d’utilisateurs. Sa page de connexion exécute la pile PAM (modules d’authentification enfichables) dans /etc/pam.d/cockpit. Les comptes sont donc vos comptes Unix et les mots de passe sont vos mots de passe Unix. root est refusé par défaut, car /etc/cockpit/disallowed-users le répertorie. Les actions privilégiées passent par polkit. L’interface redemande votre mot de passe avant toute modification. C’est pourquoi l’en-tête de la page peut afficher « Accès limité » tant que vous n’avez pas élevé vos privilèges.

Cette conception a une conséquence sur un serveur durci. Si vous avez suivi la connexion SSH avec clé uniquement et l’authentification par mot de passe désactivée, le compte peut ne posséder aucun mot de passe utilisable. La connexion à Cockpit est alors refusée, tandis que ssh fonctionne toujours. Vérifiez-le sur le serveur :

sudo passwd -S deploy

Une sortie commençant par deploy L signifie que le mot de passe est verrouillé. PAM n’a donc rien à accepter et aucun mot de passe saisi ne peut fonctionner. P signifie qu’un mot de passe utilisable est défini. La page de connexion de Cockpit n’accepte pas les clés SSH. Les clés servent uniquement lorsque Cockpit se connecte ensuite, depuis la machine sur laquelle vous vous êtes connecté, à un autre hôte.

Webmin conserve ses propres utilisateurs dans /etc/webmin/miniserv.users, séparément de /etc/passwd. Il peut également être configuré pour s’authentifier avec des comptes Unix. Un utilisateur Webmin auquel tous les modules sont accordés possède les privilèges de root sur cette machine, quelle que soit la valeur indiquée par son shell de connexion. Webmin fournit sa propre prise en charge de TOTP (mot de passe à usage unique basé sur le temps) et son propre blocage des hôtes après plusieurs échecs de connexion. Ces deux fonctions sont activées dans Webmin Configuration. Cockpit n’obtient un second facteur que si vous en ajoutez un à PAM, par exemple avec libpam-google-authenticator.

Mise à jour de chaque solution

Cockpit est fourni par votre distribution. Sur Ubuntu 24.04, il provient de l’archive. Le projet en amont recommande le pocket backports pour obtenir une version plus récente :

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

apt policy affiche la version installée et le dépôt dont elle provient. Si backports ne contient aucune version plus récente, apt utilise la version de l’archive, ce qui convient. cockpit.socket doit afficher active (listening). Les correctifs de sécurité arrivent ensuite lors de la même exécution de unattended-upgrades que celle qui met à jour votre noyau, depuis un éditeur auquel vous faites déjà confiance.

Webmin ne se trouve pas dans l’archive Ubuntu. L’installation officielle ajoute d’abord le dépôt propre à Webmin et sa clé de signature :

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

Lisez ce script avant de l’exécuter, car il s’exécute en tant que root. Ensuite, chaque apt upgrade exécuté sur le serveur récupère également les paquets depuis le dépôt Webmin. Vous ajoutez donc un deuxième éditeur bénéficiant d’une confiance au niveau root sur la machine. C’est le coût réel de Webmin. Un exemple concret permet de le comprendre : CVE-2019-15107 était une backdoor présente dans plusieurs paquets 1.9x. Elle permettait l’exécution de commandes sans authentification et a atteint les utilisateurs parce que le serveur de build du projet avait été compromis, et non son dépôt source. Le packaging par la distribution ne rend pas ce type d’incident impossible. Il ajoute toutefois une étape de build et de revue que vous n’avez pas à assurer vous-même.

Pourquoi aucun des deux ne doit être exposé sur un port public

Cockpit écoute sur le port TCP 9090 et Webmin sur le port TCP 10000, tous deux en TLS (transport layer security) avec un certificat autosigné. La première chose affichée est donc un avertissement du navigateur. Créer et faire confiance à un certificat autosigné explique ce que cet avertissement indique et ce qu’il n’indique pas. Ces deux ports sont scannés en permanence. Les deux panneaux donnent accès à root. Un mot de passe deviné ou réutilisé suffit donc à compromettre entièrement le serveur.

La méthode sûre consiste à lier le panneau à localhost et à y accéder via un tunnel SSH. Pour Cockpit, surchargez l’unité socket :

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

La ligne ListenStream= vide doit être présente seule. systemd ajoute les valeurs aux paramètres de type liste. Sans cette ligne, l’unité conserve 0.0.0.0:9090 et ajoute la nouvelle adresse. Votre panneau reste donc public. Appliquez la surcharge et vérifiez ce qui écoute :

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

La sortie doit afficher 127.0.0.1:9090. Une adresse *:9090 ou 0.0.0.0:9090 indique que la surcharge n’a pas été prise en compte. Ouvrez maintenant le tunnel depuis votre propre machine et accédez à https://localhost:9090 :

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

Conservez le même port en local et à distance. Cockpit compare l’en-tête Origin du navigateur avec l’adresse sur laquelle il pense être configuré pour servir. Ainsi, un tunnel utilisant le port local 9999 charge la page de connexion, puis échoue lors de l’authentification. journalctl -u cockpit enregistre alors l’origine rejetée. Si vous avez besoin d’un autre port local, indiquez-le dans /etc/cockpit/cockpit.conf :

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

Redémarrez avec sudo systemctl restart cockpit.socket pour appliquer ce changement. Pour Webmin, le paramètre équivalent se trouve dans /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 vérifie également l’en-tête Referer lors de l’envoi des formulaires et refuse les requêtes qui semblent provenir d’un autre hôte. C’est ce qui fait échouer une première tentative avec un reverse proxy. La ligne referers= du même fichier permet d’autoriser le nom d’hôte du proxy. La ligne webprefix= indique à Webmin qu’il est accessible sous un chemin.

L’autre possibilité consiste à utiliser un reverse proxy authentifié : nginx en frontal, avec une couche d’authentification unique Authentik pour la connexion. Cette solution fonctionne, mais elle arrive en deuxième choix. Le panneau s’exécute toujours avec les privilèges de root derrière le proxy. Vous devez aussi maintenir deux points d’entrée au lieu d’un seul. Un tunnel n’ajoute aucun service en écoute sur Internet et réutilise la clé SSH que vous protégez déjà.

Quel panneau choisir sur une machine qui exécute déjà des services en production

Cockpit, pour deux raisons importantes lorsque d’autres personnes dépendent de la machine. Il est activé par socket : cockpit-ws ne s’exécute que lorsqu’une session est ouverte, sans daemon root permanent en attente sur un port. Et il ne gère rien d’autre : supprimez le paquet et tous les services continuent de fonctionner exactement comme avant, car Cockpit ne stocke aucune configuration qui lui est propre. Le miniserv.pl de Webmin reste résident, que quelqu’un soit connecté ou non. Vérifiez la mémoire qu’il consomme avec systemctl status webmin, qui affiche la mémoire résidente du processus en cours d’exécution.

Si vous avez besoin des modules DNS ou de messagerie de Webmin, installez-les sur un serveur dédié. Une machine Webmin qui exécute une seule fonction et qui est liée à 127.0.0.1 présente un risque limité. Webmin installé sur le même hôte que votre application accessible aux clients est en revanche un risque. Effectuez les opérations de base avant d’installer l’un ou l’autre panneau : les dix premières minutes sur un nouveau VPS couvrent la création de l’utilisateur non-root et la configuration du pare-feu, que les deux panneaux supposent déjà en place.

Quand aucune des deux options ne convient

Un panneau s’utilise serveur par serveur et manuellement. Il ne conserve aucune trace des modifications ni de leur raison. Cela convient pour une seule machine. Avec cinq machines, vous répétez les mêmes actions. Avec vingt, vous devez deviner quel serveur n’a pas reçu la modification. Cockpit peut ajouter d’autres hôtes à une même session via SSH, mais les versions récentes désactivent cette fonction par défaut et exigent AllowMultiHost=yes dans /etc/cockpit/cockpit.conf. Vous devez malgré tout effectuer cinq fois la même modification dans l’interface.

L’alternative consiste à utiliser SSH directement, avec votre configuration dans un dépôt git. Gérer plusieurs serveurs Linux depuis un emplacement central présente la structure de cette configuration. Un premier playbook Ansible applique la même règle de pare-feu à tous les hôtes depuis un seul fichier, que vous pouvez examiner sous forme de diff. La gestion des conteneurs suit le même principe : docker compose up -d via SSH depuis un fichier versionné dans git, comme dans le guide sur les bases de Docker Compose, est préférable à l’utilisation d’un panneau. De toute façon, Cockpit ne gère pas Docker.

Utilisez un panneau pour les tâches qu’un terminal rend difficiles, par exemple lire un graphique de métriques ou repérer l’unité défaillante parmi quarante. Utilisez du code pour toute tâche que vous effectuerez plus de deux fois.

Modes d’échec et messages affichés

Cockpit refuse un mot de passe accepté par SSH. Le compte est configuré pour l’authentification par clé uniquement. sudo passwd -S alice affiche L dans le deuxième champ. PAM n’a donc aucun mot de passe à vérifier. Définissez-en un avec sudo passwd alice, ou conservez ce compte pour SSH et connectez-vous à Cockpit avec un autre utilisateur.

Cockpit refuse root même avec le bon mot de passe. /etc/cockpit/disallowed-users répertorie root. Connectez-vous avec un utilisateur normal disposant des droits sudo. C’est la méthode prévue, car polkit enregistre alors l’identité de la personne qui a effectué l’élévation de privilèges.

Cockpit n’affiche aucune page Networking ou Firewall. Ces pages nécessitent NetworkManager et firewalld. Un VPS Ubuntu utilise netplan avec systemd-networkd et ufw. Les pages n’apparaissent donc pas. Rien n’est défectueux. Continuez à utiliser ufw via SSH.

La page de connexion Cockpit se charge via le tunnel, puis la connexion échoue. Votre port local diffère du port distant. Le contrôle Origin échoue et journalctl -u cockpit l’indique. Utilisez les mêmes ports, ou définissez Origins dans /etc/cockpit/cockpit.conf.

Les envois de formulaires Webmin échouent après l’installation du service derrière un proxy. Le contrôle Referer les rejette. Ajoutez le nom d’hôte du proxy à referers= dans /etc/webmin/miniserv.conf, et définissez webprefix= lorsque le panneau est servi sous un chemin.

Vous ne savez pas si un panneau est exposé. sudo ss -lntp | grep -E '9090|10000' répond à cette question depuis le serveur lui-même. Webmin écrit chaque tentative de connexion dans /var/webmin/miniserv.log. Consultez ce fichier une fois après toute modification de son adresse ou de son port d’écoute.

FAQ

Cockpit ou Webmin est-il préférable pour un seul VPS Ubuntu ?

Pour la plupart des utilisateurs, Cockpit est préférable, car il provient du dépôt officiel d’Ubuntu, est mis à jour avec le reste du système et ne fonctionne que lorsqu’une session de navigateur est ouverte. Choisissez Webmin si vous avez besoin d’un éditeur à base de formulaires pour un service que Cockpit ne gère pas, comme BIND ou Postfix. En contrepartie, son serveur web s’exécute en permanence avec les privilèges de root et ses mises à jour proviennent du dépôt de Webmin.

Puis-je exécuter Cockpit et Webmin sur le même serveur ?

Oui. Ils utilisent des ports différents, 9090 et 10000, et n’entrent pas en conflit, car chacun modifie directement le système au lieu d’en prendre le contrôle. Cela reste toutefois un mauvais compromis. Chaque panneau ajoute une connexion distincte capable d’obtenir les privilèges de root sur la même machine. Vous doublez donc la surface d’exposition pour économiser quelques clics. Si vous installez les deux, liez-les à 127.0.0.1 et accédez-y via un tunnel SSH.

Est-il sûr d’ouvrir le port 9090 ou 10000 sur Internet ?

Pas avec une connexion par mot de passe. Les deux panneaux permettent d’obtenir les privilèges de root, et les deux ports sont repérés par les scans courants dans les heures qui suivent leur ouverture. Liez le panneau à 127.0.0.1, puis exécutez ssh -N -L 9090:127.0.0.1:9090 user@host et ouvrez https://localhost:9090 dans votre navigateur. Vérifiez avec sudo ss -lntp | grep 9090, qui doit afficher 127.0.0.1:9090 et non 0.0.0.0:9090. Un reverse proxy authentifié constitue une deuxième option acceptable.

Pourquoi ma connexion à Cockpit échoue-t-elle alors que SSH fonctionne avec une clé ?

Cockpit s’authentifie via PAM avec un mot de passe Unix, et sa page de connexion n’accepte pas les clés SSH. Sur un serveur durci, le compte n’a souvent aucun mot de passe utilisable. Exécutez sudo passwd -S youruser : un L dans le deuxième champ signifie que le mot de passe est verrouillé. PAM n’a donc rien à accepter et chaque tentative est rejetée. Définissez un mot de passe avec sudo passwd youruser ou utilisez un autre compte pour le panneau.

Cockpit gère-t-il les conteneurs Docker ?

Non. La page de gestion des conteneurs de Cockpit provient de cockpit-podman et gère Podman. L’ancien module Docker a été supprimé il y a plusieurs années et ne reviendra pas. Si vos services s’exécutent avec Docker, gérez-les avec un fichier compose placé sous contrôle de version et utilisez SSH. Laissez Cockpit gérer le système qui les héberge, notamment le journal et les disques.