Wiederherstellung des Cockpit-Zugriffs auf SUSE Linux Enterprise Server

Auf SUSE Linux Enterprise Server 16.0 bestätigt die aktuelle Cockpit-Einrichtungsanleitung vom 8. Oktober 2026 das cockpitMuster, die cockpit.socketsystemd-Unit und den Standard-HTTPS-Port 9090. Um eine Konsolenverbindung zu reparieren, die nicht hergestellt werden kann, überprüfen Sie zuerst DNS und Erreichbarkeit, dann Socket, Firewall, Zertifikat und Benutzerkonto. Diese Installationsbefehle gelten speziell für SLES 16. Bei älteren SLES-Versionen überprüfen Sie bitte die Paket- und Firewall-Anweisungen für diese Version, bevor Sie die Regeln installieren oder ändern.

Verwenden Sie durchgehend dieses rein hypothetische Beispiel: Maya, eine Systemadministratorin, öffnet die Seite https://cockpit-srv.example.net:9090von ihrem Arbeitsplatzrechner aus, und der Browser meldet einen Timeout. Der Beispielhost und alle angezeigten Adressen oder Statusmeldungen dienen lediglich der Veranschaulichung und stellen keinen Bericht über einen realen Servertest dar.

1. Trennen Sie einen Namens- oder Netzwerkfehler von einem Cockpit-Fehler.

Beginnen Sie an Mayas Workstation. Bestätigen Sie die Namensauflösung und testen Sie anschließend den HTTPS-Endpunkt mit einem kurzen Timeout:

getent ahosts cockpit-srv.example.net
curl -vI --connect-timeout 5 https://cockpit-srv.example.net:9090/
Beispielhafte Terminalabfrage für cockpit-srv.example.net, die die reservierte Beispieladresse 192.0.2.25 zurückgibt.
Das Beispiel-DNS-Ergebnis verwendet eine reservierte Dokumentationsadresse; überprüfen Sie den tatsächlichen Hostnamen und die Adresse in Ihrer eigenen Umgebung.

Schlägt die Namensauflösung fehl oder liefert sie eine veraltete Adresse, korrigieren Sie den DNS-Eintrag oder den Resolver des Clients, bevor Sie Cockpit verwenden. Meldet curl „Verbindung abgelehnt“, hat der Host zwar geantwortet, die Verbindung wurde jedoch an diesem Port nicht akzeptiert, oder eine Firewall hat sie aktiv blockiert. Ein Timeout deutet in der Regel auf verworfenen Datenverkehr, ein Routing-Problem oder eine vorgelagerte Firewall hin. Erreicht curl TLS und meldet eine Zertifikatswarnung, hat der Netzwerkverkehr Cockpit erreicht; untersuchen Sie das Zertifikat, anstatt weitere Ports zu öffnen.

Stellen Sie sicher, dass Maya den vorgesehenen Hostnamen und das vorgesehene Management-Netzwerk verwendet. TCP 9090 ist der Standardport, kann aber angepasst werden. Wenn der direkte Zugriff eingeschränkt ist, verwenden Sie einen autorisierten Cockpit-Primärserver, um den Sekundärhost per SSH zu erreichen, anstatt den Port allgemein freizugeben.

2. Überprüfen Sie das Paket und den Socket auf dem Server.

Verwenden Sie SSH oder eine lokale Konsole, um zu überprüfen, ob das Cockpit-Paket installiert ist, den systemd-Socket und ob etwas auf Port 9090 lauscht:

sudo zypper se -i cockpit
sudo systemctl status cockpit.socket
sudo ss -ltnp 'sport = :9090'
Beispielhafte Ausgabe von systemctl status, die zeigt, dass cockpit.socket aktiv ist und auf Port 9090 lauscht.
Ein aktives Zuhören cockpit.socketwird auch dann erwartet, wenn der On-Demand-Cockpit-Dienst zwischen Browsersitzungen inaktiv ist.

Cockpit nutzt die Socket-Aktivierung über systemd: cockpit.socketEs akzeptiert die Browserverbindung und startet den Webdienst bei Bedarf. Daher cockpit.servicedeutet ein Leerlauf nicht automatisch auf einen Fehler hin. Falls Cockpit installiert ist, der Socket aber inaktiv ist, starten und aktivieren Sie ihn.

sudo systemctl enable --now cockpit.socket

Falls das Paket unter SLES 16 fehlt, dokumentiert SUSE die Installation mit [Pfad einfügen] sudo zypper in -t pattern cockpit. Gehen Sie nicht davon aus, dass dieses Muster in den für SLES 15 oder eine andere Version konfigurierten Repositories verfügbar ist. Überprüfen Sie Socket- und Servicemeldungen mit [Befehl einfügen].

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

Wenn der Socket lokal lauscht, Maya aber trotzdem eine Zeitüberschreitung meldet, überprüfen Sie Firewall und Routing. Falls er nicht lauscht, beheben Sie den Paket- oder Socket-Fehler im Journal.

3. Erlauben Sie den Zugriff über die richtige Firewall-Zone.

Auf SLES 16 mit aktiviertem firewalld muss zunächst die aktive Zone identifiziert und deren zulässige Dienste überprüft werden:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=ZONE --list-services
Beispielhafte firewalld-Befehle, die die aktive Zone und die in der öffentlichen Zone zugelassenen Dienste anzeigen.
Prüfen Sie die tatsächlich aktive Zone und ihre Dienste, bevor Sie die Host-Firewall ändern; die angezeigte öffentliche Zone ist nur ein Beispiel.

Ersetzen Sie dies ZONEdurch die Zone, die der Verwaltungsschnittstelle zugeordnet ist. Falls Cockpit fehlt und diese Zone für vertrauenswürdigen Administrationszugriff vorgesehen ist, fügen Sie den Cockpit-Dienst hinzu und laden Sie die Regeln neu.

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

Die Regel betrifft alle in dieser Zone zugelassenen Quellen. Beschränken Sie daher die Verwaltungszone auf das Administratornetzwerk. Überprüfen Sie außerdem Cloud-Sicherheitsgruppen, Netzwerk-ACLs, VPN-Richtlinien und vorgelagerte Firewalls auf TCP-Port 9090.

Die SUSE-Anleitung für SLES 16 Cockpit beschreibt auch das Aktualisieren cockpit-selinux-policiesund Neustarten cockpit.socketals Teil der Firewall-Konfiguration. Falls Sie SLES 16 verwenden und die Paket-/Socket- oder SELinux-Richtlinie nach Durchführung der Firewall-Schritte inkonsistent erscheint, verwenden Sie die Befehle aus der entsprechenden SUSE-Anleitung.

sudo zypper in -f cockpit-selinux-policies
sudo systemctl restart cockpit.socket

Wenden Sie diesen Paketierungsschritt nicht auf eine andere SLES-Version an, ohne vorher die zugehörige Paketdokumentation zu prüfen. Wenn der direkte Portzugriff absichtlich eingeschränkt ist, verwenden Sie einen zugelassenen Cockpit-Primärhost und stellen Sie eine Verbindung zum Zielsystem als Sekundärserver über SSH her, anstatt die Firewall des Zielsystems zu erweitern.

4. TLS-Warnungen und Anmeldeverweigerungen beheben

Cockpit über HTTPS öffnen: https://cockpit-srv.example.net:9090Unter SLES 16 generiert Cockpit ein selbstsigniertes Zertifikat, falls keines installiert ist. Eine Browserwarnung über einen unbekannten Aussteller oder einen Namenskonflikt deutet auf ein Problem mit der TLS-Vertrauensstellung oder der Identität hin, nicht auf einen Fehler der TCP-Verbindung. Deaktivieren Sie die Browser-Zertifikatprüfung nicht als dauerhafte Lösung.

Beispielhafte Terminalausgabe, die den Befehl `cockpit-certificate-ensure check` von SUSE an der Shell-Eingabeaufforderung zeigt.
Der gezeigte Befehl prüft, welches Zertifikat Cockpit verwenden wird; diese Abbildung stellt kein Prüfergebnis dar.

Überprüfen Sie das von Cockpit ausgewählte Zertifikat mit dem in der SUSE-Dokumentation beschriebenen Befehl:

sudo /usr/libexec/cockpit-certificate-ensure --check

SLES 16 lädt Zertifikate von /etc/cockpit/ws-certs.d[Pfad einfügen]. Ein passender privater Schlüssel verwendet denselben Basisdateinamen mit einem .keySuffix. Installieren Sie auf verwalteten Servern ein Zertifikat, dessen alternativer Antragstellername mit dem von Maya eingegebenen Hostnamen übereinstimmt, fügen Sie die zugehörige Zwischenzertifikatskette hinzu und legen Sie fest, dass die ausstellende Zertifizierungsstelle (CA) von der Workstation als vertrauenswürdig eingestuft wird. Falls curl den Dienst erreicht, aber ein selbstsigniertes Zertifikat meldet, korrigieren Sie die Vertrauensstellung oder stellen Sie ein geeignetes Zertifikat bereit, anstatt die Firewall zu ändern.

Cockpit verwendet die normalen Anmeldedaten des Serverkontos; ein separates Cockpit-Passwort ist nicht erforderlich. Bei Neuinstallationen von SLES rootist die passwortbasierte Anmeldung standardmäßig deaktiviert. Falls Maya die Anmeldeseite erreicht, sich aber nicht als Root anmelden kann, verwenden Sie ein autorisiertes Benutzerkonto, anstatt die Root-Passwortanmeldung nur zur Fehlerbehebung in Cockpit zu aktivieren. Administrative Aktionen können dann über die entsprechenden Berechtigungen des Kontos ausgeführt werden.

Überprüfen Sie den vollständigen Pfad

Laden Sie die HTTPS-URL von Mayas Workstation neu. Überprüfen Sie, ob der DNS-Server den gewünschten Server zurückgibt, Port 9090 (TCP) erreichbar ist, das Zertifikat übereinstimmt und als vertrauenswürdig eingestuft ist und sich ein autorisiertes Konto anmelden kann. Falls das lokale Lauschen funktioniert, die Remote-Anfrage jedoch ein Timeout verursacht, geben Sie dem Netzwerkteam beide Adressen, den Port und die Testzeit an.

Die aktuellste SUSE-Referenz für Installation, Firewall, Zertifikate und Authentifizierungsdetails ist das SLES 16.0 Cockpit-Administrationshandbuch vom 8. Oktober 2026. Allgemeine Informationen zum Verhalten von HTTPS und Zertifikaten in den verschiedenen Cockpit-Versionen finden Sie im Cockpit SSL/TLS-Leitfaden . Die Verfügbarkeit der Pakete und die Firewall-Integration sind versionsspezifisch.

Einen Kommentar hinterlassen

Aktivieren Sie SLES Live Patching und überprüfen Sie eine Kernel-Korrektur.

Aktivieren Sie SLES Live Patching und überprüfen Sie eine Kernel-Korrektur.

Richten Sie den richtigen Live-Patching-Pfad für SLES 16.0 oder 15 SP7 ein, wenden Sie geeignete Kernel-Fixes an und überprüfen Sie, was aktiv ist, ohne es mit einem Kernel-Update zu verwechseln, das einen Neustart erfordert.

Sicherstellung der Verfügbarkeit der Dienste während eines Upgrades von SLES 15 SP5 auf SP6

Sicherstellung der Verfügbarkeit der Dienste während eines Upgrades von SLES 15 SP5 auf SP6

SLES 15 SP5 kann online auf SP6 migriert werden, jedoch muss jeder Knoten neu gestartet werden. Verwenden Sie ein getestetes Rolling Upgrade oder eine Blue-Green-Umstellung, um die Erreichbarkeit der Workloads aufrechtzuerhalten.

Erstellen eines benutzerdefinierten AppArmor-Profils unter SUSE Linux

Erstellen eines benutzerdefinierten AppArmor-Profils unter SUSE Linux

Erstellen, verfeinern und überprüfen Sie ein AppArmor-Profil mit minimalen Berechtigungen unter SLES 15 SP7, mit einem deutlichen Hinweis auf den SELinux-Standard von SLES 16.

SLES 15 STIG sicher mit OpenSCAP auftragen

SLES 15 STIG sicher mit OpenSCAP auftragen

Verwenden Sie das von SUSE unterstützte STIG-Profil, um SLES 15 zu scannen, Korrekturmaßnahmen zu testen, verbleibende Ergebnisse zu überprüfen und Bewertungsnachweise zu sichern.

Wiederherstellung des Cockpit-Zugriffs auf SUSE Linux Enterprise Server

Wiederherstellung des Cockpit-Zugriffs auf SUSE Linux Enterprise Server

Verfolgen Sie eine fehlgeschlagene Cockpit-Verbindung über DNS, Port 9090, den systemd-Socket, firewalld, TLS und die Anmeldeeinstellungen anhand der aktuellen SUSE-Anleitung.

Zuverlässiges Ethernet-Failover mit SLES 15 Bonding konfigurieren

Zuverlässiges Ethernet-Failover mit SLES 15 Bonding konfigurieren

Erstellen Sie eine redundante Ethernet-Verbindung auf SLES 15 mit YaST und Wicked, konfigurieren Sie Active-Backup-Bonding und überprüfen Sie beide Ports sowie das Failover.

Erstellen Sie ein wiederverwendbares AutoYaST-Profil für SLES 15-Installationen

Erstellen Sie ein wiederverwendbares AutoYaST-Profil für SLES 15-Installationen

Ein bestehendes SLES 15-System wird in ein geprüftes AutoYaST-Profil umgewandelt, validiert und kann zur Bereitstellung eines Testservers mit weniger manuellen Schritten verwendet werden.

SLES 15 KVM-Setup: Ausgewählte VMs beim Systemstart starten

SLES 15 KVM-Setup: Ausgewählte VMs beim Systemstart starten

Installieren Sie die SLES 15 KVM- und libvirt-Tools, aktivieren Sie den richtigen Host-Dienst und konfigurieren Sie die ausgewählten virtuellen Maschinen so, dass sie nach einem Neustart automatisch starten.

Diagnose eines SUSE-Servers, der beim Herunterfahren mit systemd hängen bleibt

Diagnose eines SUSE-Servers, der beim Herunterfahren mit systemd hängen bleibt

Verwenden Sie systemd jobs und das vorherige Boot-Journal, um eine langsame Dienst-, Mount- oder Speicherabhängigkeit zu lokalisieren und diese dann zu beheben, ohne die Ursache zu verschleiern.

Öffnen Sie nur den Webverkehr, den Ihr SLES 15-Server benötigt.

Öffnen Sie nur den Webverkehr, den Ihr SLES 15-Server benötigt.

Verwenden Sie firewall-cmd, um die aktive Zone zu untersuchen, HTTP sicher zuzulassen, den SSH-Zugriff aufrechtzuerhalten und zu überprüfen, ob die Regel einen Neustart unter SLES 15 übersteht.