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 interface permet réellement de modifier

L’installation de base de Cockpit est réduite. La plupart des fonctions sont fournies par des paquets séparés que vous pouvez ne pas installer :

• services et timers systemd : démarrer, arrêter, activer et consulter le fichier d’unité
• le journal, filtré par unité et par priorité, avec journalctl et 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 fonctions semblent défectueuses sur un VPS Ubuntu, mais elles ne le sont pas. La page Networking de Cockpit est une interface pour NetworkManager. Or 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 rétablir. Il prend le contrôle de l’interface réseau, et une erreur vous fait aussi perdre la session SSH. Les fonctions de pare-feu de Cockpit sont une interface pour firewalld. Ubuntu utilise ufw. Vous n’obtenez donc aucun contrôle du pare-feu dans Cockpit. Vous continuez à exécuter sudo ufw status dans un terminal.

Webmin couvre beaucoup plus de fonctions. Il s’appuie sur un ensemble de modules propres à chaque service, et non sur un seul programme :

• configuration d’Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL et Samba au moyen de formulaires
• utilisateurs, groupes et quotas de 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 pour les 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

La plupart des formulaires Webmin modifient directement les fichiers réels sous /etc, sans 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 ce que le module y a écrit. Cela ne montre pas les actions qui exécutent une commande ou du SQL, comme les modules MariaDB et PostgreSQL, ni les écritures dans des fichiers situés en dehors de /etc. Dans ces limites, c’est le moyen le plus rapide de comprendre ce que fait réellement une page Webmin. Le guide d’installation de Webmin et de première connexion présente en détail l’arborescence des modules. Virtualmin et Usermin sont des produits distincts construits sur le même moteur. Ils sont destinés respectivement à l’hébergement mutualisé et aux utilisateurs finaux. Ils présentent donc les mêmes problèmes d’exposition que ceux décrits ici.

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.

Comment chacun est mis à jour

Cockpit est empaqueté par votre distribution. Sur Ubuntu 24.04, il provient de l’archive, et le projet amont recommande le dépôt 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 cockpit affiche la version installée et le dépôt dont elle provient. Exécutée sans nom de paquet, apt policy affiche uniquement la priorité de chaque source. Si backports ne contient aucune version plus récente, apt revient à la version de l’archive, ce qui convient. cockpit.socket doit afficher active (listening). Les correctifs de sécurité arrivent alors avec 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ée sur le serveur récupère également des paquets depuis le dépôt Webmin. Vous avez donc ajouté un second éditeur bénéficiant d’un niveau de confiance 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 porte dérobée présente dans plusieurs paquets 1.9x. Elle permettait l’exécution de commandes sans authentification. Elle a atteint les utilisateurs parce que le serveur de build du projet avait été compromis, et non son dépôt source. L’empaquetage 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 TCP 9090 et Webmin sur 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 approuver un certificat autosigné explique ce que cet avertissement indique et ce qu’il n’indique pas. Les deux ports sont constamment scannés et 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 directive ListenStream= vide, placée seule sur sa ligne, est obligatoire. systemd ajoute les nouvelles valeurs aux paramètres de type liste. Sans cette directive, l’unité conserve la valeur 0.0.0.0:9090 d’origine et ajoute la nouvelle adresse. Le panneau reste alors 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 signifie 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

Le port local n’a pas besoin de correspondre au port distant. Cockpit construit l’origine attendue à partir de l’en-tête Host envoyé par le navigateur. Ainsi, un tunnel ouvert sur le port local 9999 et accessible à https://localhost:9999 passe le même contrôle, car les en-têtes Host et Origin du navigateur indiquent la même adresse. Le contrôle échoue lorsqu’un élément situé entre le navigateur et Cockpit modifie Host, par exemple un reverse proxy qui ne transmet pas l’en-tête d’origine. La page de connexion se charge alors, mais l’authentification échoue, et cockpit-ws journalise received request from bad Origin. Cette ligne se trouve dans le journal des unités cockpit-wsinstance-https@, et non dans cockpit.service. Lisez-la avec sudo journalctl -u 'cockpit-wsinstance-https@*'. Pour accepter une adresse publique différente de celle vue par Cockpit, indiquez-la dans /etc/cockpit/cockpit.conf :

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

Redémarrez avec sudo systemctl restart cockpit pour appliquer cette modification. 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 de reverse proxy. La ligne referers= dans /etc/webmin/config permet d’autoriser le nom d’hôte du proxy. La directive webprefix= du même fichier indique à Webmin qu’il est accessible sous un chemin.

L’autre option consiste à utiliser un reverse proxy avec authentification : nginx en frontal, avec une couche d’authentification unique Authentik pour la connexion. Cette solution fonctionne, mais elle vient 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’accès au lieu d’un. 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 solutions ne convient

Un panneau est propre à chaque serveur et son utilisation est manuelle. Il ne conserve aucune trace de ce qui a changé ni de la raison du changement. Cela convient pour un seul serveur. Avec cinq serveurs, vous répétez les mêmes opérations. Avec vingt, vous devez deviner lequel n’a pas reçu la modification. Cockpit peut ajouter d’autres hôtes à une même session via SSH, mais ce sélecteur d’hôte est obsolète depuis Cockpit 322. Son activation par défaut dépend désormais de la distribution. Lorsqu’il est désactivé, vous devez ajouter AllowMultiHost=yes dans /etc/cockpit/cockpit.conf. Même lorsqu’il est activé, vous devez toujours 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 même emplacement 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 stocké dans git, comme dans le guide sur les bases de Docker Compose, est préférable à l’utilisation d’un panneau. Cockpit ne gère d’ailleurs pas Docker.

Utilisez un panneau pour les tâches que le terminal gère mal, par exemple consulter un graphique de métriques ou repérer l’unité défaillante parmi quarante. Utilisez du code pour toute opération 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 utilise uniquement une clé. 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 affiche root. Connectez-vous avec un utilisateur standard disposant des droits sudo. C’est le fonctionnement prévu, 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 ne s’affichent donc pas. Rien n’est défectueux. La solution consiste à continuer d’utiliser ufw via SSH.

La page de connexion Cockpit se charge derrière un proxy, puis la connexion échoue. Le proxy a modifié l’en-tête Host. Le contrôle Origin échoue donc et sudo journalctl -u 'cockpit-wsinstance-https@*' affiche received request from bad Origin. Transmettez l’en-tête Host d’origine, ou définissez Origins dans /etc/cockpit/cockpit.conf. Un tunnel SSH simple ne provoque pas ce problème, quel que soit le port local choisi.

Les envois de formulaires Webmin échouent après son placement derrière un proxy. Le contrôle Referer les rejette. Ajoutez le nom d’hôte du proxy à referers= dans /etc/webmin/config, puis définissez webprefix= dans ce fichier 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 l’adresse ou du 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.