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 Oberflächen tatsächlich ändern

Die Basisinstallation von Cockpit ist klein. Die meisten Bereiche werden von separaten Paketen 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 Mountpoints
• 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

Auf einem Ubuntu-VPS wirken zwei Bereiche 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 entfernten System, nur um die Seite wiederherzustellen. NetworkManager übernimmt dann die Schnittstelle. Ein Fehler dabei kann auch Ihre SSH-Sitzung beenden. Die Firewall-Steuerung von Cockpit ist ein Frontend für firewalld. Ubuntu verwendet ufw. Deshalb stehen Ihnen überhaupt keine Firewall-Steuerungen zur Verfügung. Sie führen weiterhin sudo ufw status in einem Terminal aus.

Webmin deckt deutlich mehr Bereiche ab. Es besteht aus einer Sammlung dienstspezifischer Module und nicht aus einem einzelnen Programm:

• Konfiguration von Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL und Samba über Formulare
• Benutzer, Gruppen und Plattenkontingente
• Cronjobs 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 Clustermodule, die eine Änderung an andere Webmin-Server übertragen

Die meisten Webmin-Formulare bearbeiten die tatsächlichen Dateien unter /etc. Dahinter befindet sich keine verborgene Datenbank. Wenn /etc unter Versionsverwaltung steht, zeigt sudo git -C /etc diff nach dem Speichern eines Formulars, was das Modul dort geschrieben hat. Aktionen, die einen Befehl ausführen oder SQL ausführen, werden nicht angezeigt. Das gilt beispielsweise für die Module von MariaDB und PostgreSQL. Auch Schreibvorgänge in Dateien außerhalb von /etc werden nicht angezeigt. Innerhalb dieser Grenzen ist dies der schnellste Weg, um zu verstehen, was eine Webmin-Seite tatsächlich macht. Die Anleitung zur Webmin-Installation und zur ersten Anmeldung erklärt den Modulbaum ausführlich. Virtualmin und Usermin sind separate Produkte auf Basis derselben Engine. Sie richten sich an Shared Hosting beziehungsweise Endbenutzer. Für ihre externe Erreichbarkeit gelten daher alle Aussagen aus diesem Abschnitt.

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 Lösungen aktualisiert werden

Cockpit wird von Ihrer Distribution paketiert. Unter Ubuntu 24.04 stammt es aus dem Archiv. Das Upstream-Projekt empfiehlt für eine neuere Version 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 cockpit gibt die installierte Version und das Repository aus, aus dem sie stammt. Ohne Paketnamen listet apt policy nur die Priorität jeder Quelle auf. Wenn Backports keine neuere Version enthält, verwendet apt wieder die Archivversion. Das ist in Ordnung. cockpit.socket sollte active (listening) anzeigen. Sicherheitskorrekturen kommen dann über denselben unattended-upgrades-Lauf wie Ihr Kernel. Sie stammen von einem Herausgeber, dem Sie bereits vertrauen.

Webmin ist nicht im Ubuntu-Archiv enthalten. Die offizielle Installation fügt zuerst das eigene Repository und den zugehörigen Signaturschlüssel von Webmin 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 das Skript, bevor Sie es ausführen, weil es als root läuft. Danach lädt jedes apt upgrade auf dem Server auch Pakete aus dem Webmin-Repository. Sie haben damit einen zweiten Herausgeber hinzugefügt, dem das System mit root-Rechten vertraut. Das ist der eigentliche Preis von Webmin. Ein konkretes Beispiel macht das deutlich: CVE-2019-15107 war eine Backdoor 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 Quell-Repository. Die Paketierung durch eine Distribution verhindert solche Vorfälle nicht. 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, beide über TLS (Transport Layer Security) mit einem selbstsignierten Zertifikat. Daher sehen Sie zuerst eine Browserwarnung. Ein selbstsigniertes Zertifikat erstellen und vertrauen erklärt, was diese Warnung aussagt und was nicht. Beide Ports werden ständig gescannt. Beide Bedienoberflächen ermöglichen den Zugriff als root. Daher führt ein erratenes oder wiederverwendetes Passwort zur vollständigen Übernahme des Servers.

Das sichere Muster besteht darin, die Bedienoberfläche an localhost zu binden und sie über einen SSH-Tunnel zu erreichen. Ü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. Ihre Bedienoberfläche bleibt dann öffentlich erreichbar. Wenden Sie die Überschreibung an und prüfen Sie, worauf ein Prozess lauscht:

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

Die Ausgabe muss 127.0.0.1:9090 anzeigen. Eine Adresse *:9090 oder 0.0.0.0:9090 bedeutet, dass die Überschreibung nicht wirksam geworden ist. Ö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

Der lokale Port muss dem entfernten Port entsprechen. Cockpit vergleicht den Origin-Header des Browsers mit der Adresse, unter der die Anwendung seiner Ansicht nach erreichbar ist. Ein Tunnel vom lokalen Port 9999 lädt daher die Anmeldeseite, schlägt anschließend aber bei der Anmeldung fehl. journalctl -u cockpit protokolliert dann 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 die 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 den Referer-Header auch bei Formularübermittlungen und weist Anfragen zurück, die scheinbar von einem anderen Host stammen. Genau das führt dazu, dass ein erster Versuch mit einem Reverse Proxy scheitert. Mit der Zeile referers= in /etc/webmin/config erlauben Sie den Hostnamen des Proxys. Mit webprefix= in derselben Datei legen Sie fest, 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 und ist die zweitbeste Lösung. Die Bedienoberfläche läuft hinter dem Proxy weiterhin als root. Außerdem verwalten Sie nun zwei Zugangspunkte statt eines. Ein Tunnel stellt überhaupt keinen im Internet lauschenden Dienst bereit. 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 arbeitet manuell. Es hinterlässt keine Aufzeichnung darüber, was geändert wurde oder warum. Für einen Server ist das in Ordnung. Bei fünf Servern wiederholen Sie dieselben Schritte. Bei zwanzig Servern müssen Sie raten, auf welchem Server die Änderung fehlt. Cockpit kann über SSH weitere Hosts in eine Sitzung aufnehmen. Dieser Host-Umschalter ist jedoch seit Cockpit 322 veraltet. Sein Standardzustand hängt inzwischen von der Distribution ab. Wenn er deaktiviert ist, benötigen Sie AllowMultiHost=yes in /etc/cockpit/cockpit.conf. Selbst wenn er aktiviert ist, müssen Sie dieselbe Änderung weiterhin fünfmal anklicken.

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 Lösung. Ein erstes Ansible-Playbook wendet dieselbe Firewall-Regel anhand einer Datei auf jeden Host an. Die Änderung können Sie als Diff prüfen. Für Container gilt dasselbe: docker compose up -d per SSH aus einer Datei im git-Repository, wie im Grundlagenleitfaden zu Docker Compose beschrieben, ist jedem Klicken durch ein Panel überlegen. Außerdem verwaltet Cockpit Docker grundsätzlich nicht.

Verwenden Sie ein Panel für Aufgaben, bei denen ein Terminal unpraktisch ist. Dazu gehören das Lesen eines Metrikdiagramms oder das 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 ausschließlich für die Anmeldung per Schlüssel konfiguriert. sudo passwd -S alice gibt im zweiten Feld L aus. Daher hat PAM kein Passwort, das es prüfen kann. Legen Sie mit sudo passwd alice ein Passwort fest. Alternativ können Sie dieses Konto weiterhin für SSH verwenden und sich mit einem anderen Benutzer bei Cockpit anmelden.

Cockpit verweigert root trotz des korrekten Passworts. /etc/cockpit/disallowed-users führt root auf. Melden Sie sich mit einem normalen Benutzer an, der über sudo-Berechtigungen verfügt. Das ist der vorgesehene Weg, weil polkit dann protokolliert, welcher Benutzer 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 aufeinander 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= in /etc/webmin/config ein. Wenn das Panel unter einem Pfad bereitgestellt wird, setzen Sie außerdem webprefix= in dieser Datei.

Sie sind nicht sicher, ob ein Panel erreichbar ist. sudo ss -lntp | grep -E '9090|10000' beantwortet diese Frage direkt auf dem Server. Webmin schreibt jeden Anmeldeversuch in /var/webmin/miniserv.log. Dieses Protokoll sollten Sie nach jeder Änderung an der Bind-Adresse 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.