Cockpit oder Webmin: Was passt besser zum Server?

Cockpit vs Webmin: die kurze Antwort

Cockpit und Webmin sind beides Weboberflächen zur Verwaltung eines Linux-Servers im Browser, beantworten jedoch unterschiedliche Anforderungen. Cockpit wird aus dem eigenen Repository Ihrer Distribution installiert und greift über systemd, journald, polkit und udisks auf den Rechner zu. Dadurch zeigt es Ihnen einen Server, den Sie weiterhin über SSH verwalten. Webmin ist älter und deutlich umfassender: Es schreibt Konfigurationsdateien für Apache, BIND, Postfix, MariaDB und Dutzende weitere Dienste, die Cockpit nicht verändert. Dafür betreibt Webmin einen eigenen Webserver mit root-Rechten.

Installieren Sie Cockpit, wenn Sie eine Live-Ansicht eines einzelnen Servers, einen Log-Reader und ein Notfallterminal benötigen. Installieren Sie Webmin, wenn Sie einen formularbasierten Editor für einen Dienst benötigen, den Sie nicht manuell konfigurieren möchten. Betreiben Sie keine der beiden Lösungen mit einem öffentlichen Port und Passwortanmeldung. Wenn Sie bereits mehr als zwei oder drei Server betreiben, lautet die ehrliche Antwort häufig: keines von beiden. Die Kombination aus SSH und Ansible lässt sich besser skalieren als jede Weboberfläche.

Was die einzelnen Bereiche tatsächlich ändern können

Die Basisinstallation von Cockpit ist klein. Die meisten Bereiche werden über separate Pakete bereitgestellt, die Sie weglassen können:

• systemd-Dienste und Timer: Units starten, stoppen und aktivieren sowie die Unit-Datei anzeigen
• das Journal, gefiltert nach Unit und Priorität, mit journalctl und einer Datumsauswahl
• lokale Konten, Gruppenmitgliedschaften und autorisierte SSH-Schlüssel
• Speicherverwaltung mit cockpit-storaged: Partitionen, LVM-Volume-Gruppen, Dateisysteme und Einhängepunkte
• Container mit cockpit-podman, das ausschließlich Podman verwaltet
• Paketaktualisierungen mit cockpit-packagekit
• Diagramme für CPU, Arbeitsspeicher, Datenträger und Netzwerk mit cockpit-pcp
• ein Root-Terminal im Browser-Tab

Zwei Bereiche wirken auf einem Ubuntu-VPS fehlerhaft. Das sind sie nicht. Die Networking-Seite von Cockpit ist ein Frontend für NetworkManager. Ubuntu-Server-Images verwenden jedoch netplan mit systemd-networkd. Deshalb fehlt die Seite oder bleibt leer. Installieren Sie NetworkManager nicht auf einem Remote-System, nur um die Seite wiederherzustellen. NetworkManager übernimmt dann die Schnittstelle, und ein Fehler beendet auch Ihre SSH-Sitzung. Die Firewall-Steuerung von Cockpit ist ein Frontend für firewalld. Ubuntu verwendet jedoch ufw. Deshalb stehen Ihnen überhaupt keine Firewall-Steuerungsfunktionen zur Verfügung. Sie führen sudo ufw status weiterhin in einem Terminal aus.

Webmin deckt deutlich mehr Bereiche ab. Es besteht aus einer Sammlung von Modulen für einzelne Dienste und nicht aus einem einzigen Programm:

• Konfiguration von Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL und Samba über Formulare
• Benutzer, Gruppen und Datenträgerkontingente
• cron-Aufträge und die Systemuhr
• Paketaktualisierungen sowie ein Dateimanager mit Upload und Download
• Firewall-Frontends, darunter eines für iptables und eines für firewalld
• Sicherungen von Konfigurationsdateien sowie Cluster-Module, die eine Änderung an andere Webmin-Server übertragen

Webmin bearbeitet die tatsächlichen Dateien unter /etc. Hinter den Formularen gibt es keine verborgene Datenbank. Wenn /etc unter Versionsverwaltung steht, zeigt sudo git -C /etc diff nach dem Speichern eines Formulars genau, was das Modul geschrieben hat. Das ist der schnellste Weg, um zu verstehen, was eine beliebige Webmin-Seite tatsächlich ändert. Die Anleitung zur Webmin-Installation und zur ersten Anmeldung geht den Modulbaum ausführlich durch. Virtualmin und Usermin sind separate Produkte auf Basis derselben Engine: Virtualmin für Shared Hosting und Usermin für Endbenutzer. Für beide gilt alles, was hier über die Erreichbarkeit im Netzwerk gesagt wurde.

Authentifizierung der einzelnen Optionen

Cockpit verfügt über keine eigene Benutzerdatenbank. Die Anmeldeseite verwendet den PAM-Stack (Pluggable Authentication Modules) in /etc/pam.d/cockpit. Daher entsprechen die Konten den Unix-Konten und die Passwörter den Unix-Passwörtern. root wird standardmäßig abgewiesen, weil /etc/cockpit/disallowed-users dieses Konto aufführt. Privilegierte Aktionen laufen über polkit. Bevor Änderungen vorgenommen werden, fordert die Oberfläche das Passwort erneut an. Deshalb kann in der Kopfzeile zunächst „Eingeschränkter Zugriff“ stehen, bis Sie die erforderlichen Rechte anfordern.

Dieses Design hat auf einem gehärteten System eine typische Konsequenz. Wenn Sie die SSH-Anmeldung nur mit Schlüsseln und deaktivierter Passwortauthentifizierung eingerichtet haben, besitzt das Konto möglicherweise überhaupt kein verwendbares Passwort. Dann wird die Cockpit-Anmeldung abgewiesen, während ssh weiterhin funktioniert. Prüfen Sie dies auf dem Server:

sudo passwd -S deploy

Eine Ausgabe, die mit deploy L beginnt, bedeutet, dass das Passwort gesperrt ist. PAM kann dann kein Passwort akzeptieren, und kein eingegebenes Passwort funktioniert. P bedeutet, dass ein verwendbares Passwort gesetzt ist. Die eigene Anmeldeseite von Cockpit akzeptiert keine SSH-Schlüssel. Schlüssel werden nur verwendet, wenn Cockpit von dem Rechner, an dem Sie sich angemeldet haben, eine Verbindung zu einem anderen Host herstellt.

Webmin verwaltet seine eigenen Benutzer in /etc/webmin/miniserv.users, getrennt von /etc/passwd. Es kann außerdem so konfiguriert werden, dass es Unix-Konten zur Authentifizierung verwendet. Einem Webmin-Benutzer, dem alle Module zugewiesen sind, stehen auf diesem Rechner root-Rechte zur Verfügung, unabhängig davon, was die Login-Shell des Benutzers angibt. Webmin bietet eine eigene TOTP-Unterstützung (zeitbasierte Einmalpasswörter) und eine eigene Sperrung von Hosts nach wiederholten fehlgeschlagenen Anmeldungen. Beide Funktionen werden unter Webmin Configuration aktiviert. Cockpit erhält einen zweiten Faktor nur, wenn Sie ihn zu PAM hinzufügen, beispielsweise mit libpam-google-authenticator.

Wie die einzelnen Komponenten aktualisiert werden

Cockpit wird von Ihrer Distribution paketiert. Unter Ubuntu 24.04 stammt es aus dem Archiv. Das Upstream-Projekt empfiehlt für einen neueren Build das Backports-Pocket:

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

apt policy gibt die installierte Version und das Repository aus, aus dem sie stammt. Wenn Backports keinen neueren Build enthält, verwendet apt weiterhin die Archivversion. Das ist in Ordnung. cockpit.socket sollte active (listening) ausgeben. Sicherheitskorrekturen kommen dann über denselben unattended-upgrades-Lauf wie für Ihren Kernel. Sie stammen von einem Herausgeber, dem Sie bereits vertrauen.

Webmin befindet sich nicht im Ubuntu-Archiv. Die offizielle Installation fügt zuerst das eigene Repository von Webmin und den zugehörigen Signaturschlüssel hinzu:

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

Lesen Sie dieses Skript, bevor Sie es ausführen, da es als root läuft. Von da an bezieht jeder apt upgrade auf dem Server ebenfalls Pakete aus dem Webmin-Repository. Damit haben Sie einen zweiten Herausgeber hinzugefügt, dem auf dem System mit Root-Rechten vertraut wird. Das ist der eigentliche Preis von Webmin. Ein konkretes Beispiel macht das deutlich: CVE-2019-15107 war eine Hintertür in mehreren 1.9x-Paketen, die eine nicht authentifizierte Befehlsausführung ermöglichte. Sie erreichte Benutzer, weil der Build-Host des Projekts kompromittiert wurde, nicht dessen Quellcode-Repository. Paketierung durch die Distribution macht dies nicht unmöglich. Sie fügt jedoch einen Build- und Prüfschritt hinzu, den Sie nicht selbst pflegen müssen.

Warum keines von beiden an einem öffentlichen Port betrieben werden sollte

Cockpit lauscht auf TCP 9090 und Webmin auf TCP 10000, jeweils über TLS (Transport Layer Security) mit einem selbst signierten Zertifikat. Deshalb sehen Sie zunächst eine Browserwarnung. Ein selbst signiertes Zertifikat erstellen und vertrauen erklärt, was diese Warnung aussagt und was nicht. Beide Ports werden ständig gescannt. Beide Panels führen zu root. Ein erratenes oder wiederverwendetes Passwort bedeutet daher, dass der Server vollständig kompromittiert ist.

Das sichere Vorgehen besteht darin, das Panel an localhost zu binden und über einen SSH-Tunnel darauf zuzugreifen. Überschreiben Sie für Cockpit die Socket-Unit:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

Die leere ListenStream= in einer eigenen Zeile ist erforderlich. systemd hängt Einträge an Listeneinstellungen an. Ohne diese Zeile behält die Unit die ursprüngliche 0.0.0.0:9090 und fügt die neue Adresse hinzu. Ihr Panel bleibt dann öffentlich erreichbar. Wenden Sie die Überschreibung an und prüfen Sie, worauf ein Dienst lauscht:

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

Die Ausgabe muss 127.0.0.1:9090 zeigen. Eine Adresse *:9090 oder 0.0.0.0:9090 bedeutet, dass die Überschreibung nicht wirksam wurde. Öffnen Sie nun den Tunnel von Ihrem eigenen Rechner aus und rufen Sie https://localhost:9090 im Browser auf:

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

Verwenden Sie für den lokalen Port denselben Wert wie für den entfernten Port. Cockpit vergleicht den Origin-Header des Browsers mit der Adresse, unter der es den Dienst bereitzustellen glaubt. Ein Tunnel über den lokalen Port 9999 lädt daher die Anmeldeseite, schlägt aber anschließend bei der Anmeldung fehl. journalctl -u cockpit protokolliert die abgelehnte Origin. Wenn Sie einen anderen lokalen Port benötigen, geben Sie ihn in /etc/cockpit/cockpit.conf an:

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

Starten Sie den Dienst mit sudo systemctl restart cockpit.socket neu, damit diese Einstellung übernommen wird. Bei Webmin befindet sich die entsprechende Einstellung in /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 prüft bei Formularübermittlungen ebenfalls den Referer-Header und lehnt Anfragen ab, die scheinbar von einem anderen Host stammen. Genau das führt dazu, dass ein erster Versuch mit einem Reverse Proxy scheitert. Die Zeile referers= in derselben Datei legt fest, welcher Hostname des Proxys zulässig ist. Mit webprefix= geben Sie an, dass Webmin unter einem Pfad erreichbar ist.

Eine weitere Möglichkeit ist ein authentifizierter Reverse Proxy: nginx davor und eine Authentik-Single-Sign-on-Schicht für die Anmeldung. Das funktioniert, ist aber die zweitbeste Lösung. Das Panel läuft hinter dem Proxy weiterhin als root. Außerdem verwalten Sie nun zwei Zugangspunkte statt einem. Ein Tunnel fügt überhaupt keinen im Internet lauschenden Dienst hinzu. Er verwendet den SSH-Schlüssel weiter, den Sie bereits schützen.

Welches Panel auf einem Server, auf dem bereits Produktionsdienste laufen

Cockpit, aus zwei Gründen, die wichtig sind, wenn andere Personen auf den Server angewiesen sind. Cockpit wird über einen Socket aktiviert. Daher läuft cockpit-ws nur, solange eine Sitzung geöffnet ist, und es wartet kein permanenter Root-Daemon an einem Port. Cockpit besitzt keine eigenen Ressourcen: Entfernen Sie das Paket, und jeder Dienst läuft exakt wie zuvor weiter, weil Cockpit keine eigene Konfiguration speichert. miniserv.pl von Webmin bleibt resident, unabhängig davon, ob jemand angemeldet ist. Prüfen Sie mit systemctl status webmin, welchen Speicherbedarf Ihre Instanz hat. Der Befehl gibt den residenten Speicher des laufenden Prozesses aus.

Wenn Sie die DNS- oder Mail-Module von Webmin benötigen, weisen Sie ihnen einen eigenen Server zu. Ein Webmin-Server, der genau eine Aufgabe erfüllt und an 127.0.0.1 gebunden ist, stellt ein begrenztes Risiko dar. Webmin auf demselben Host wie Ihre kundenorientierte Anwendung ist das nicht. Erledigen Sie die grundlegenden Arbeiten, bevor eines der beiden Panels installiert wird: die ersten zehn Minuten auf einem neuen VPS behandelt den Nicht-Root-Benutzer und die Firewall, die beide Panels voraussetzen.

Wenn beides nicht zutrifft

Ein Panel ist serverbezogen und manuell. Es dokumentiert nicht, was geändert wurde oder warum. Für einen einzelnen Server ist das in Ordnung. Bei fünf Servern wiederholen Sie die Arbeit. Bei zwanzig Servern müssen Sie raten, auf welchem Server die Änderung fehlt. Cockpit kann über SSH weitere Hosts in eine Sitzung einbinden. Neuere Versionen deaktivieren diese Funktion jedoch standardmäßig und erwarten AllowMultiHost=yes in /etc/cockpit/cockpit.conf. Außerdem klicken Sie dieselbe Änderung weiterhin fünfmal durch.

Die Alternative ist einfaches SSH mit Ihrer Konfiguration in einem git-Repository. Mehrere Linux-Server von einer Stelle aus verwalten beschreibt den Aufbau einer solchen Konfiguration. Ein erstes Ansible-Playbook wendet dieselbe Firewall-Regel aus einer Datei, die Sie als Diff prüfen können, auf jeden Host an. Für Container gilt dasselbe: docker compose up -d über SSH aus einer Datei in git, wie im Grundlagenleitfaden zu Docker Compose beschrieben, ist jedem Panel-Klick überlegen. Außerdem verwaltet Cockpit Docker grundsätzlich nicht.

Verwenden Sie ein Panel für Aufgaben, bei denen ein Terminal unpraktisch ist, etwa zum Lesen eines Metrikdiagramms oder zum Erkennen, welche von vierzig Units fehlgeschlagen sind. Verwenden Sie Code für alles, was Sie mehr als zweimal ausführen werden.

Fehlerbilder und die angezeigten Meldungen

Cockpit weist ein Passwort zurück, das SSH akzeptiert. Das Konto ist nur für die Anmeldung per Schlüssel eingerichtet. sudo passwd -S alice gibt im zweiten Feld L aus. Daher hat PAM kein Passwort, das geprüft werden kann. Legen Sie mit sudo passwd alice ein Passwort fest. Alternativ verwenden Sie dieses Konto weiterhin für SSH und melden sich bei Cockpit mit einem anderen Benutzer an.

Cockpit verweigert root trotz des korrekten Passworts. /etc/cockpit/disallowed-users führt root auf. Melden Sie sich als normaler Benutzer mit sudo-Berechtigungen an. Das ist der vorgesehene Weg, weil polkit dann protokolliert, welche Person die Berechtigungen erhöht hat.

Cockpit zeigt keine Seiten für Networking oder Firewall an. Diese Seiten benötigen NetworkManager und firewalld. Ein Ubuntu-VPS verwendet netplan mit systemd-networkd und ufw. Daher werden die Seiten nicht angezeigt. Es liegt kein Fehler vor. Verwenden Sie weiterhin ufw über SSH.

Die Cockpit-Anmeldeseite wird über den Tunnel geladen, aber die Anmeldung schlägt fehl. Ihr lokaler Port unterscheidet sich vom Remote-Port. Daher schlägt die Prüfung mit Origin fehl, und journalctl -u cockpit zeigt den Unterschied an. Stimmen Sie die Ports ab oder setzen Sie Origins in /etc/cockpit/cockpit.conf.

Webmin-Formularübermittlungen schlagen fehl, nachdem Sie Webmin hinter einen Proxy gestellt haben. Die Prüfung mit Referer weist sie zurück. Fügen Sie den Proxy-Hostnamen in referers= unter /etc/webmin/miniserv.conf hinzu. Setzen Sie webprefix=, wenn das Panel unter einem Pfad bereitgestellt wird.

Sie sind nicht sicher, ob ein Panel öffentlich erreichbar ist. sudo ss -lntp | grep -E '9090|10000' prüft das direkt auf dem Server. Webmin schreibt außerdem jeden Anmeldeversuch in /var/webmin/miniserv.log. Diese Datei sollten Sie nach jeder Änderung an der Listening-Konfiguration einmal prüfen.

FAQ

Ist Cockpit oder Webmin für einen einzelnen Ubuntu-VPS besser?

Für die meisten ist Cockpit die bessere Wahl, weil es aus dem eigenen Ubuntu-Repository stammt, zusammen mit dem restlichen System mit Sicherheitsupdates versorgt wird und nur läuft, solange eine Browsersitzung geöffnet ist. Wählen Sie Webmin, wenn Sie einen formularbasierten Editor für einen Dienst benötigen, den Cockpit nicht verwaltet, etwa BIND oder Postfix. Akzeptieren Sie dafür, dass der Webserver von Webmin dauerhaft als root läuft und die Updates aus dem eigenen Webmin-Repository kommen.

Kann ich Cockpit und Webmin auf demselben Server betreiben?

Ja. Sie verwenden unterschiedliche Ports, 9090 und 10000, und kommen sich nicht in die Quere, weil jedes Panel das System direkt bearbeitet, statt es exklusiv zu verwalten. Trotzdem ist das ein schlechter Kompromiss. Jedes Panel stellt auf demselben Rechner einen separaten root-fähigen Login bereit. Damit verdoppeln Sie die Angriffsfläche, um einige wenige Klicks zu sparen. Wenn Sie beide installieren, binden Sie beide an 127.0.0.1 und greifen Sie über einen SSH-Tunnel darauf zu.

Ist es sicher, Port 9090 oder 10000 im Internet zu öffnen?

Nicht mit einer Anmeldung per Passwort. Beide Panels ermöglichen den Zugriff auf root, und beide Ports werden innerhalb weniger Stunden nach ihrer Öffnung durch routinemäßige Scans gefunden. Binden Sie das Panel an 127.0.0.1, führen Sie anschließend ssh -N -L 9090:127.0.0.1:9090 user@host aus und rufen Sie https://localhost:9090 im Browser auf. Prüfen Sie dies mit sudo ss -lntp | grep 9090. Dabei muss 127.0.0.1:9090 statt 0.0.0.0:9090 angezeigt werden. Ein authentifizierter Reverse Proxy ist eine akzeptable zweite Option.

Warum schlägt meine Cockpit-Anmeldung fehl, obwohl SSH mit einem Schlüssel funktioniert?

Cockpit authentifiziert über PAM mit einem Unix-Passwort. Die Anmeldeseite akzeptiert keine SSH-Schlüssel. Auf einem gehärteten Server hat das Konto häufig kein verwendbares Passwort. Führen Sie sudo passwd -S youruser aus. Ein L im zweiten Feld bedeutet, dass das Passwort gesperrt ist. PAM kann dann keine gültige Eingabe akzeptieren, und jeder Versuch wird abgewiesen. Setzen Sie mit sudo passwd youruser ein Passwort oder verwenden Sie für das Panel ein anderes Konto.

Verwaltet Cockpit Docker-Container?

Nein. Die Container-Seite von Cockpit stammt aus cockpit-podman und verwaltet Podman. Das alte Docker-Modul wurde vor Jahren entfernt und wird nicht zurückkehren. Wenn Ihre Dienste unter Docker laufen, verwalten Sie sie über SSH mit einer Compose-Datei in der Versionsverwaltung. Lassen Sie Cockpit die Systemumgebung verwalten, etwa das Journal und die Datenträger.