Résolution du problème de connexion à la console Web Cockpit sur SUSE Linux Enterprise Server

Si la console web Cockpit ne se connecte pas à un serveur SUSE Linux Enterprise Server (SLES), commencez https://SERVER_IP:9090par vérifier que le serveur cockpit.socketest à l'écoute et que le pare-feu autorise le service Cockpit dans la zone utilisée par l'interface réseau du serveur. Sur une installation standard, ces vérifications permettent de résoudre les problèmes les plus courants : URL ou port incorrects, socket inactif, paquets Cockpit manquants ou connexion entrante bloquée.

Ce guide s'applique aux systèmes SLES utilisant systemd et disposant de Cockpit dans leurs dépôts de produits configurés. Le guide Cockpit SLES 16 actuel de SUSE décrit ci-dessous les commandes d'installation et d'activation du socket. La disponibilité et le nom des paquets peuvent varier selon le Service Pack, le module et le niveau de support SLES. Par conséquent, sur un système SLES 15 plus ancien, vérifiez que Cockpit est bien proposé par ses dépôts SUSE activés avant de considérer une erreur d'installation comme un problème de service.

Commencez par le symptôme

Utilisez le message d'erreur du navigateur pour identifier la cause du problème. Un délai d'attente dépassé ou un message « site inaccessible » indique généralement un problème de routage, de règles de pare-feu ou de serveur inactif. Une connexion refusée signifie souvent qu'aucun service n'accepte les connexions à l'adresse et au port sélectionnés. L'affichage de la page de connexion Cockpit indique que le service web est accessible ; une erreur d'authentification ultérieure est liée à un autre problème de compte ou de stratégie de sécurité. Un avertissement de certificat signifie que la négociation HTTPS a atteint le serveur, mais que le navigateur ne fait pas confiance au certificat ou à son nom.

Par exemple, supposons qu'un administrateur ne puisse pas accéder à un serveur dont l'adresse est 192.0.2.25. Effectuez un test https://192.0.2.25:9090depuis une machine autorisée à l'administrer. Cockpit utilise normalement HTTPS sur le port 9090. Saisir uniquement l'adresse IP peut ouvrir un autre service, et utiliser http://peut entraîner une redirection ou un avertissement du navigateur au lieu de l'écran de connexion attendu.

1. Vérifiez l'URL et l'accessibilité

Vérifiez l'adresse actuelle du serveur à partir de la console SLES ou d'un inventaire de confiance, et indiquez explicitement le port :

https://192.0.2.25:9090

Depuis le client, vérifiez si le port TCP 9090 est accessible. Sur un poste d'administration Linux avec netcat installé, exécutez :

nc -vz 192.0.2.25 9090

Une connexion TCP réussie prouve uniquement que le port est accessible ; elle ne garantit pas le bon fonctionnement de la connexion. Un délai d'attente dépassé suggère de vérifier la zone de pare-feu active du serveur, le pare-feu du réseau en amont, le routage et l'accès VPN. Un refus suggère de vérifier le processus d'écoute sur l'hôte SLES. Si netcat n'est pas disponible, effectuez un test depuis un navigateur ou utilisez un autre outil de connectivité TCP approuvé plutôt que d'installer un utilitaire non approuvé sur un hôte de production.

2. Vérifiez que le cockpit est installé et que sa prise est active.

Connectez-vous via SSH ou une console locale et examinez le socket. Cockpit utilise généralement l'activation des sockets par systemd : systemd écoute les connexions entrantes pour le compte de Cockpit et démarre le service web à la demande. De ce fait, l'élément clé à examiner est généralement le socket lui-même cockpit.socket, et non un processus fonctionnant en continu cockpit.service.

sudo systemctl status cockpit.socket
sudo ss -ltnp | grep ':9090'

Recherchez un socket actif/à l'écoute et un écouteur lié au port 9090. Si l'unité est absente, Cockpit n'est peut-être pas installé. Sur une version SLES dont les dépôts activés fournissent le modèle Cockpit, SUSE documente son installation avec :

sudo zypper refresh
sudo zypper in -t pattern cockpit

Si Zypper indique que le modèle est introuvable, vérifiez auprès de votre administrateur SUSE le produit, le Service Pack, les modules activés, l'état des dépôts et les droits d'assistance. N'ajoutez pas de dépôt tiers non pertinent uniquement pour que la commande réussisse. Après avoir vérifié que Cockpit est installé, activez et démarrez son socket :

sudo systemctl enable --now cockpit.socket
sudo systemctl status cockpit.socket

Cette --nowoption permet de démarrer immédiatement le socket et de l'activer pour les démarrages ultérieurs. Si systemd signale une unité défaillante, examinez l'erreur exacte avant de la redémarrer à plusieurs reprises :

sudo journalctl -u cockpit.socket -b --no-pager
sudo journalctl -u cockpit.service -b --no-pager

3. Autoriser le cockpit à traverser la zone de pare-feu active

Un écouteur actif peut rester inaccessible si le pare-feu hôte interrompt la connexion. Dans les versions actuelles de SLES, firewalld est utilisé pour la gestion du pare-feu. Commencez par identifier la zone active et l'interface qui lui est associée :

sudo firewall-cmd --get-active-zones

Ajoutez ensuite le service Cockpit nommé à la zone contenant l'interface de gestion. Remplacez publicpar la zone réelle indiquée sur votre hôte :

sudo firewall-cmd --zone=public --add-service=cockpit --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --query-service=cockpit

La commande finale devrait afficher un résultat yes. Si l'interface réseau se trouve dans une zone différente, l'ouverture du service publicne corrigera pas les règles de cette interface. La documentation de Cockpit de SUSE utilise le cockpitservice firewalld ; il est préférable d'ouvrir ce service plutôt que d'autoriser tout le trafic ou de désactiver le pare-feu. Vérifiez également les groupes de sécurité cloud, les pare-feu de périmètre, les politiques VPN et les listes de contrôle d'accès réseau si la règle hôte est correcte mais que le client expire toujours.

Si votre image SLES utilise une configuration de gestion de pare-feu différente, suivez la politique de ce système au lieu d'appliquer les commandes firewalld sans discernement. Ne supprimez pas les règles de pare-feu et ne désactivez pas le pare-feu sur un serveur de production administré à distance : cela pourrait exposer des services et interrompre votre processus de gestion en cours.

4. Distinguer un échec de connexion d'un problème de certificat ou d'authentification

Une fois la page de connexion chargée, le chemin réseau vers Cockpit est fonctionnel. Cockpit s'attend normalement à ce que les connexions du navigateur utilisent HTTPS et présente un certificat TLS. Un avertissement concernant un certificat auto-signé ou une incohérence de nom ne signifie pas que la connexion est interrompue. Pour un hôte de laboratoire, vérifiez l'empreinte numérique via un canal de confiance avant d'accepter l'avertissement. Pour les systèmes administrés, installez un certificat dont le nom du sujet correspond au nom d'hôte utilisé par les administrateurs et dont la chaîne de certificats est approuvée par leurs navigateurs.

Si la page de connexion s'affiche mais que les identifiants sont refusés, vérifiez le nom d'utilisateur, le mot de passe, l'état du compte et la politique d'authentification du serveur. Cockpit s'authentifie généralement auprès des comptes système ; il ne s'agit pas d'une base de données utilisateurs distincte. Ne saisissez pas de mots de passe dans les commandes ni dans les journaux lors du dépannage. Si la page se charge mais que l'interface reste blanche ou que la connexion est interrompue après la connexion, consultez la console de développement du navigateur et les journaux Cockpit récents. Un proxy inverse peut également être à l'origine des échecs s'il ne prend pas en charge les connexions WebSocket ou s'il transmet des informations de protocole ou d'hôte incorrectes.

5. Examinez les journaux et les paramètres du proxy une fois les vérifications de base effectuées.

Capturez une courte fenêtre de journalisation lors d'une nouvelle tentative de connexion :

sudo journalctl -u cockpit.socket -u cockpit.service --since "10 minutes ago" --no-pager

Recherchez les erreurs de liaison, d'autorisation ou de certificat, ainsi que les messages correspondant à l'heure du test. Si le serveur écoute localement mais qu'un client distant ne peut pas s'y connecter, examinez le chemin réseau et la zone firewalld avant de modifier la configuration de Cockpit. Si l'accès direct fonctionne mais que l'accès via un proxy échoue, effectuez temporairement une comparaison via une route directe autorisée, puis vérifiez la prise en charge des mises à niveau WebSocket et les en-têtes transférés du proxy. Évitez de modifier l'origine ou les paramètres TLS de Cockpit dans un premier temps ; des paramètres de confiance de proxy incorrects peuvent compromettre la sécurité.

Vérifiez la réparation

Après avoir effectué une modification à la fois, vérifiez les résultats suivants :

• systemctl status cockpit.socketindique que la prise est active et à l'écoute.
• L'hôte SLES possède un écouteur sur le port attendu, normalement TCP 9090.
• La règle de pare-feu est présente dans la zone attribuée à l'interface de gestion.
• Le client peut accéder au serveur à l'adresse indiquée https://SERVER_IP:9090et voit la page de connexion Cockpit.
• Après l'authentification, la page reste connectée et le journal récent ne contient aucune erreur de démarrage ou de connexion correspondante.

Si la connexion socket est active et que les vérifications locales réussissent, mais que les tests TCP distants expirent toujours, le problème se situe probablement en dehors de Cockpit, par exemple au niveau d'un pare-feu, d'une route réseau, d'un enregistrement DNS ou d'une règle VPN. Si le service échoue sur un système SLES par ailleurs pris en charge, enregistrez l'état de l'unité et les journaux système, puis consultez la documentation SUSE ou le canal de support pour connaître la configuration exacte du Service Pack, plutôt que d'appliquer des correctifs destinés à une autre distribution.

Références officielles

• SUSE : Administration de SUSE Linux Enterprise Server à l’aide de Cockpit
• Projet Cockpit : Activation des sockets de démarrage et de systemd
• Projet Cockpit : Port et adresse TCP
• Projet Cockpit : HTTPS et certificats
• Projet Cockpit : FAQ de dépannage
• SUSE : Configuration du pare-feu SLES 15 SP5 et zones firewalld