Gérer plusieurs VPS et serveurs Linux depuis un navigateur avec Cockpit

Pourquoi Cockpit pour administrer plusieurs serveurs Linux

Dès que l'on gère trois ou quatre machines, un VPS Linux pour le serveur de jeu, un autre pour le site et la base de données, un serveur dédié pour les machines virtuelles, la même question revient : comment administrer tous ces serveurs sans ouvrir un terminal SSH sur chacun, taper les mêmes commandes systemctl, apt upgrade et df -h, et garder en tête quel service tourne où. Un fil récent de la communauté r/VPS sur Reddit pose exactement cette question, et les réponses se partagent entre scripts maison, automatisation et interfaces web d'administration.

Cockpit est la réponse la plus directe. C'est la console d'administration web open source développée par Red Hat et livrée en standard dans RHEL, Fedora Server, AlmaLinux et Rocky Linux, disponible aussi dans les dépôts de Debian et d'Ubuntu. Une fois installé sur un serveur, il expose sur le port 9090 une interface web qui affiche l'état du système en temps réel (processeur, mémoire, disque, réseau), les services systemd, les journaux, les mises à jour de paquets, le stockage, les interfaces réseau, les comptes utilisateurs et un terminal complet. Surtout, Cockpit sait se connecter en SSH à d'autres hôtes et les afficher dans la même session : un seul VPS principal devient le tableau de bord de tout votre parc. L'interface est traduite en français, et Cockpit s'appuie sur les outils déjà présents (systemd, NetworkManager, udisks, PackageKit) sans démon supplémentaire : rien ne tourne en permanence, le service web est activé à la demande par cockpit.socket.

Au moment d'écrire ce guide, la dernière version publiée par le projet est Cockpit 371 (4 novembre 2026), le rythme de sortie étant d'une version toutes les deux à trois semaines. Ce guide s'adresse aux administrateurs de VPS et de serveurs dédiés, notamment ceux qui hébergent des serveurs de jeu FiveM, Minecraft ou Rust sur plusieurs machines. Il couvre l'installation sur un VPS principal, l'ajout d'hôtes distants, le pilotage quotidien (services, mises à jour, stockage, réseau), la gestion des machines virtuelles et des conteneurs, puis la sécurisation de l'accès.

Prérequis

• Un VPS principal sous Ubuntu 24.04 LTS ou Debian 13, qui servira de point d'entrée ; le même guide fonctionne sur Debian 12 et Ubuntu 22.04 ;
• Un ou plusieurs serveurs Linux distants (VPS ou dédiés) joignables en SSH depuis le VPS principal ;
• Un compte utilisateur non root avec sudo sur chaque machine : Cockpit authentifie avec les comptes système via PAM, il n'a pas de base d'utilisateurs à lui ;
• Une authentification par clé SSH entre le VPS principal et les hôtes distants, recommandée. Si ce n'est pas encore fait : configurer une clé SSH sur VPS Linux ;
• Le port 9090/TCP ouvert sur le pare-feu du VPS principal uniquement. Les hôtes distants n'ont besoin que du port SSH.

Installer Cockpit sur le VPS principal

Cockpit est présent dans les dépôts standard de Debian et d'Ubuntu, mais dans une version figée à la sortie de la distribution. Le projet recommande d'installer la version des backports, bien plus récente, et d'y rester pour les mises à jour. L'écart est important :

Sur Ubuntu, les backports sont activés par défaut dans les sources apt. Sur Debian, déclarez-les d'abord. Ces commandes utilisent la variable VERSION_CODENAME du fichier /etc/os-release pour viser automatiquement la bonne suite :

# Debian uniquement : activer les backports
. /etc/os-release
echo "deb http://deb.debian.org/debian ${VERSION_CODENAME}-backports main" | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update

# Debian et Ubuntu : installer Cockpit depuis les backports
. /etc/os-release
sudo apt install -t ${VERSION_CODENAME}-backports cockpit
sudo systemctl enable --now cockpit.socket
sudo ufw allow 9090/tcp

Le paquet cockpit est un métapaquet : il dépend de cockpit-ws (le service web), cockpit-bridge (le composant côté système qui exécute les actions) et cockpit-system (les pages d'administration : vue d'ensemble, journaux, services, comptes, terminal). Il recommande cockpit-networkmanager, cockpit-storaged et cockpit-packagekit, qui apportent les pages Réseau, Stockage et Mises à jour logicielles. Vérifiez qu'ils sont bien installés, sinon ajoutez-les explicitement. Conservez toujours -t ${VERSION_CODENAME}-backports lors des mises à jour de Cockpit, sinon apt restera sur la version standard.

La page Réseau repose sur NetworkManager. Sur un VPS Ubuntu Server configuré avec netplan et systemd-networkd, ou sur un Debian en ifupdown, elle ne peut pas gérer les interfaces ; le projet documente cette limite comme volontaire, et elle n'a aucune conséquence sur le reste de la console. Si le port 9090 est déjà pris ou si vous préférez un port moins prévisible, Cockpit ne se configure pas dans son fichier de configuration mais par un drop-in systemd :

sudo mkdir -p /etc/systemd/system/cockpit.socket.d
printf '[Socket]\nListenStream=\nListenStream=9443\n' | sudo tee /etc/systemd/system/cockpit.socket.d/listen.conf
sudo systemctl daemon-reload
sudo systemctl restart cockpit.socket

La ligne ListenStream= vide réinitialise le port 9090 par défaut avant de déclarer le nouveau. Pensez à adapter la règle UFW, comme expliqué dans ouvrir des ports avec UFW.

Première connexion à l'interface web

Ouvrez https://adresse-ip-du-vps:9090 dans un navigateur. Cockpit génère à la première exécution un certificat TLS auto-signé (0-self-signed.cert dans /etc/cockpit/ws-certs.d/), le navigateur affiche donc un avertissement qu'il faut accepter pour l'instant ; la section sécurité explique comment le remplacer par un certificat Let's Encrypt. Connectez-vous avec votre compte utilisateur Linux et son mot de passe. Cockpit redirige automatiquement le HTTP vers le HTTPS, sauf pour les connexions depuis localhost.

Après connexion, la console s'ouvre en accès limité : vous voyez l'état du serveur mais ne pouvez pas modifier les services ni installer de mises à jour. Cliquez sur « Accès limité » dans la barre supérieure et saisissez votre mot de passe : Cockpit obtient les privilèges via sudo pour la durée de la session, exactement comme un sudo -i dans un terminal. Un clic sur « Accès administratif » rend les privilèges. Cette distinction vaut aussi pour les hôtes distants : le compte utilisé pour s'y connecter doit être sudoer sur cette machine.

La page Vue d'ensemble affiche la charge processeur, la mémoire, l'activité disque et réseau en temps réel, l'état des services en échec, les mises à jour en attente et le temps de fonctionnement. Le lien « Voir les métriques et l'historique » ouvre des graphiques minute par minute ; l'historique sur plusieurs jours s'appuie sur PCP (Performance Co-Pilot), que la page propose d'installer. Pour un serveur de jeu, c'est le complément visuel des outils en ligne de commande décrits dans surveiller les ressources avec htop et btop.

Ajouter des hôtes distants : un seul tableau de bord pour tous vos serveurs

C'est la fonction qui répond à la question de départ. Cockpit ne demande pas d'installer le service web sur chaque serveur ni d'ouvrir le port 9090 partout : depuis la session ouverte sur le VPS principal, il établit une connexion SSH vers l'hôte distant et y lance un processus cockpit-bridge à la place d'un shell interactif. Toutes les pages (services, journaux, stockage, terminal) s'affichent alors pour cette machine, et un sélecteur d'hôtes en haut à gauche permet de passer de l'une à l'autre en un clic. Le principe est celui d'un hôte bastion : un point d'entrée, protégé, qui rebondit en SSH vers le reste du parc.

Étape 1 : préparer chaque hôte distant

Installez le pont et les pages d'administration sur chaque serveur à piloter. Le paquet cockpit-system entraîne cockpit-bridge ; ajoutez les composants dont vous voulez les pages, car le menu d'un hôte distant ne montre que les fonctions installées sur cet hôte :

. /etc/os-release
sudo apt install -t ${VERSION_CODENAME}-backports cockpit-system cockpit-bridge cockpit-packagekit cockpit-storaged cockpit-networkmanager

Pas de cockpit-ws, pas de cockpit.socket, aucun port supplémentaire à ouvrir : le port SSH suffit. Si la configuration SSH de l'hôte distant est déjà durcie comme dans sécuriser SSH sur VPS Linux, avec PasswordAuthentication no, l'étape suivante devient obligatoire.

Étape 2 : la clé SSH du VPS principal

À l'ouverture de session, Cockpit démarre un agent SSH pour l'utilisateur connecté et y charge ses clés avec ssh-add. Il suffit donc que le compte Linux avec lequel vous vous connectez à Cockpit sur le VPS principal possède une clé autorisée sur les hôtes distants. Si la clé a une phrase de passe, Cockpit répond avec le mot de passe saisi au login : utilisez la même phrase, ou une clé sans phrase de passe réservée à cet usage.

# Sur le VPS principal, avec le compte utilisé pour se connecter à Cockpit
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "cockpit-admin"
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@203.0.113.11
ssh admin@203.0.113.11 hostname   # doit répondre sans mot de passe

Le test en ligne de commande enregistre au passage l'empreinte de l'hôte dans ~/.ssh/known_hosts. Cockpit sait aussi afficher l'empreinte et la faire valider depuis l'interface lors du premier ajout, puis l'écrit dans le même fichier. Cockpit propose également, depuis l'interface, de créer une clé et de l'autoriser sur l'hôte distant sans quitter le navigateur.

Étape 3 : activer les hôtes multiples sur le VPS principal

Depuis Cockpit 322, le projet considère la navigation entre hôtes multiples comme dépréciée, et le sélecteur d'hôtes est désactivé par défaut sauf sur RHEL 9, Debian 12 et Ubuntu 22.04 et 24.04 LTS. La raison est documentée sans détour : le JavaScript de chaque hôte connecté s'exécute dans le même contexte du navigateur, avec les mêmes privilèges que la session principale, sans isolation entre hôtes. Un serveur distant compromis pourrait donc injecter du code dans votre session Cockpit. Le projet demande de ne connecter que des hôtes de confiance, ce qui est le cas de vos propres VPS et serveurs dédiés. Activez la fonction dans /etc/cockpit/cockpit.conf, fichier au format INI à créer s'il n'existe pas :

sudo mkdir -p /etc/cockpit
printf '[WebService]\nAllowMultiHost=yes\n' | sudo tee /etc/cockpit/cockpit.conf
sudo systemctl restart cockpit

Déclarez-la même sur Ubuntu 24.04 où elle est active par défaut : le réglage survivra à une migration vers une distribution plus récente. Une fois activée, Cockpit avertit une fois par session avant la connexion à un second hôte ; l'option WarnBeforeConnecting=false dans une section [Session] supprime cet avertissement.

Étape 4 : ajouter l'hôte dans l'interface

Dans la barre latérale, ouvrez le sélecteur d'hôtes (le nom du VPS principal) puis « Ajouter un nouvel hôte ». Renseignez l'adresse IP ou le nom DNS, le nom d'utilisateur distant et une couleur qui identifiera cette machine dans la barre. Validez l'empreinte SSH si elle est inconnue, puis Cockpit se connecte : le serveur de jeu apparaît avec sa propre vue d'ensemble, ses services et ses journaux. Répétez pour chaque VPS. Pour un parc de serveurs de jeu, attribuez une couleur par rôle (bleu pour les serveurs FiveM, vert pour les bases de données) afin de toujours savoir sur quelle machine vous êtes avant de cliquer sur « Redémarrer ».

Il existe une variante sans sélecteur, utile quand le VPS principal ne sert que de rebond : la page de connexion de Cockpit propose un champ « Se connecter à » qui ouvre directement une session SSH vers l'hôte saisi, avec ses identifiants. L'option LoginTo de cockpit.conf contrôle l'affichage de ce champ et RequireHost=true rend la saisie d'un hôte obligatoire, ce qui transforme le VPS principal en simple passerelle sans jamais exposer sa propre administration.

Piloter services, mises à jour, stockage et réseau

Le sélecteur d'hôtes en place, le quotidien d'un administrateur de serveurs de jeu se fait depuis cinq pages.

Services. La page liste toutes les unités systemd avec leur état, et permet de démarrer, arrêter, redémarrer, activer ou désactiver au boot, et d'afficher les journaux de l'unité. Si votre serveur FiveM, Minecraft ou Rust tourne sous une unité systemd comme décrit dans créer un service systemd pour un serveur de jeu, un redémarrage après une mise à jour de ressources se fait en deux clics, hôte par hôte, sans retrouver le bon systemctl restart dans l'historique du terminal.

Journaux. La page lit journalctl avec filtres par priorité, par service et par période, et une recherche libre. Une erreur de démarrage de FXServer, une tentative de connexion SSH refusée ou un OOM killer se retrouvent sans connaître la syntaxe de journalctl, que nous détaillons dans analyser les logs d'un serveur de jeu avec journalctl.

Mises à jour logicielles. Avec cockpit-packagekit, la page affiche les mises à jour disponibles, distingue celles de sécurité, et les applique ; Cockpit 371 permet désormais de choisir les paquets à mettre à jour individuellement. Sur AlmaLinux et Rocky Linux, elle configure aussi les mises à jour automatiques en s'appuyant sur dnf-automatic ; sous Debian et Ubuntu, gardez unattended-upgrades en ligne de commande, comme décrit dans automatiser les mises à jour de sécurité. En passant d'un hôte à l'autre, vous voyez d'un coup d'oeil quel serveur a pris du retard sur les correctifs de sécurité.

Stockage. Avec cockpit-storaged, la page montre les disques, partitions, systèmes de fichiers, volumes LVM, points de montage et l'espace utilisé, et sait créer ou agrandir un volume, formater, monter. Sur un VPS, c'est surtout un indicateur précoce de disque plein, première cause de crash silencieux d'un serveur de jeu ou d'une base de données. Sur un serveur dédié avec plusieurs disques, c'est une alternative graphique à la procédure d'extension d'un volume LVM.

Réseau. Avec cockpit-networkmanager, la page affiche les interfaces, leurs adresses, le débit en temps réel, et permet de créer des ponts, des VLAN ou des agrégats sur les systèmes qui utilisent NetworkManager (AlmaLinux, Rocky Linux, Fedora, ou Ubuntu avec le renderer NetworkManager dans netplan). Elle inclut aussi, sur les distributions à firewalld (AlmaLinux, Rocky Linux, Fedora), la gestion des zones et services du pare-feu. Sur Ubuntu et Debian avec UFW ou nftables, le pare-feu reste à gérer en ligne de commande, par exemple depuis le terminal intégré.

Terminal. La page Terminal ouvre un shell complet dans le navigateur, sur l'hôte sélectionné. Cockpit ne remplace donc pas SSH : il l'embarque. Pour une opération qui n'a pas de page dédiée, une commande txAdmin, un script de sauvegarde ou un tail -f sur un log applicatif, le terminal est là, sans client SSH ni gestion de clés sur le poste de travail.

Machines virtuelles et conteneurs : cockpit-machines et cockpit-podman

Deux extensions du projet étendent la console à la virtualisation. cockpit-machines est l'interface Cockpit pour les machines virtuelles libvirt : elle énumère les VM KVM via libvirt-dbus, les démarre, les arrête, affiche leur console graphique ou série, et crée de nouvelles machines à partir d'une image ISO ou d'un dépôt d'installation grâce à virt-install. Sur un serveur dédié qui héberge plusieurs serveurs de jeu dans des VM séparées, c'est une alternative légère à un hyperviseur complet, à comparer avec le dimensionnement décrit dans dimensionner Proxmox VE sur un serveur dédié. Le paquet est en version 332 dans Debian 13 et 310 dans Ubuntu 24.04 (avec un backport disponible) :

. /etc/os-release
sudo apt install -t ${VERSION_CODENAME}-backports cockpit-machines
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt $USER

Le paquet installe ses dépendances : libvirt-daemon-system, libvirt-dbus, libvirt-clients et virt-install. Sur un VPS, la page apparaît mais la création de VM dépend de la virtualisation imbriquée, rarement activée ; réservez cockpit-machines aux serveurs dédiés.

cockpit-podman, en version 108 dans Debian 13, ajoute une page Podman containers : images, conteneurs, pods, journaux et console de chaque conteneur, en mode root comme en mode rootless. Si vos services tournent en conteneurs Podman, c'est l'équivalent intégré des interfaces comparées dans Portainer, Dockge ou Cosmos, sans conteneur supplémentaire ni socket à exposer. Les deux extensions suivent la règle des hôtes distants : elles doivent être installées sur l'hôte où tournent les VM ou les conteneurs, pas seulement sur le VPS principal.

Sécuriser l'accès à la console web

Cockpit est une porte d'entrée administrative sur tout votre parc. Quatre mesures la protègent.

Restreindre le port 9090

Le port 9090 ne devrait jamais être ouvert à tout Internet. Le plus propre est de n'y accéder que par un réseau privé : avec Tailscale ou WireGuard, le VPS principal n'expose Cockpit que sur son adresse VPN, et la règle UFW se limite à ce réseau :

sudo ufw delete allow 9090/tcp
sudo ufw allow from 100.64.0.0/10 to any port 9090 proto tcp   # plage Tailscale
sudo ufw status numbered

À défaut de VPN, limitez la règle à l'adresse IP fixe de votre connexion. Par ailleurs, Cockpit limite à 10 le nombre de tentatives de connexion simultanées non authentifiées (MaxStartups) et journalise les échecs via PAM dans le journal système, ce que Fail2ban peut surveiller.

Un vrai certificat TLS

Cockpit lit ses certificats dans /etc/cockpit/ws-certs.d/ : un fichier .crt ou .cert contenant le certificat et sa chaîne intermédiaire, et un fichier .key de même nom, non chiffré. Il prend le dernier fichier par ordre alphabétique. Avec un certificat obtenu comme dans Certbot et Let's Encrypt sur VPS Linux pour un nom comme admin.exemple.fr, copiez-le et vérifiez :

sudo cp /etc/letsencrypt/live/admin.exemple.fr/fullchain.pem /etc/cockpit/ws-certs.d/10-letsencrypt.crt
sudo cp /etc/letsencrypt/live/admin.exemple.fr/privkey.pem /etc/cockpit/ws-certs.d/10-letsencrypt.key
sudo chmod 600 /etc/cockpit/ws-certs.d/10-letsencrypt.key
sudo /usr/lib/cockpit/cockpit-certificate-ensure --check
sudo systemctl restart cockpit

Placez ces mêmes commandes dans un script sous /etc/letsencrypt/renewal-hooks/deploy/ pour que chaque renouvellement remette le certificat à jour. Le fichier 10-letsencrypt.crt passe après 0-self-signed.cert dans l'ordre alphabétique, il est donc bien celui retenu.

Expiration de session et bannière

Par défaut, une session Cockpit n'expire jamais. Sur une console qui donne accès à tous vos serveurs, imposez une déconnexion après inactivité, et affichez un avertissement légal sur la page de connexion :

[WebService]
AllowMultiHost=yes

[Session]
IdleTimeout=15
Banner=/etc/issue.cockpit

IdleTimeout s'exprime en minutes et ne s'applique qu'aux connexions interactives par mot de passe. Redémarrez cockpit après modification.

Mises à jour et comptes

Cockpit 368 (23 septembre 2026) a corrigé trois vulnérabilités dans cockpit-ws (CVE-2026-91147, CVE-2026-91148 et CVE-2026-91149), portées aussi sur la branche 310.10 des distributions à support long. C'est l'argument pour les backports : la version standard de la distribution ne suit pas ce rythme. Enfin, puisque Cockpit utilise les comptes Linux, la sécurité de la console est celle de vos comptes : clé SSH plutôt que mot de passe pour les hôtes distants, un compte nominatif par administrateur, root jamais utilisé directement, et une surveillance des échecs de connexion comme décrit dans analyser les échecs de connexion SSH.

Cockpit, SSH, Ansible ou Cockpit Client : quelle approche pour quel parc

Cockpit ne remplace ni l'automatisation ni la supervision. Il occupe une place précise : l'administration interactive, visuelle, de quelques dizaines de machines au plus.

Les approches se combinent. Un parc de serveurs de jeu bien tenu utilise Ansible pour la configuration initiale de chaque VPS (comptes, clé SSH, pare-feu, installation de cockpit-system), Cockpit pour les interventions du quotidien et le diagnostic, et Grafana et Prometheus ou Uptime Kuma pour être alerté avant que les joueurs ne le signalent. Ce que Cockpit ne fait pas : appliquer une même action sur dix hôtes d'un coup. Chaque page s'affiche pour un hôte à la fois ; pour redémarrer un service sur tous les serveurs, c'est un playbook Ansible, pas Cockpit.

Conclusion

Avec Cockpit installé depuis les backports sur un VPS principal, cockpit-system sur chaque hôte distant, une clé SSH et l'option AllowMultiHost, vous administrez tous vos VPS et serveurs dédiés depuis un seul onglet de navigateur : services systemd, mises à jour de sécurité, stockage, réseau, journaux, machines virtuelles et conteneurs, avec un terminal intégré pour le reste. Les hôtes distants n'exposent que leur port SSH, le VPS principal n'expose le port 9090 que sur un réseau privé, et un certificat Let's Encrypt remplace l'auto-signé. Gardez en tête l'avertissement du projet sur les hôtes multiples : ne connectez que des machines que vous contrôlez, et mettez Cockpit à jour aussi sérieusement que le reste du système. Pour héberger ce VPS principal et les serveurs de jeu qu'il pilote, nos VPS Linux KVM sont livrés sous Ubuntu 24.04 LTS, Debian, AlmaLinux ou Rocky Linux, toutes compatibles avec ce guide.