Webmin auf Ubuntu 24.04 installieren und absichern

Was Sie aufbauen

Webmin ist eine webbasierte Verwaltungsoberfläche, die einen vollständigen Linux-Server über den Browser verwaltbar macht. Dazu gehören Benutzer, Pakete, Cron-Jobs, die Firewall, Apache, BIND, Datenträger und zahlreiche weitere Module. Die Oberfläche ist über HTTPS auf Port 10000 erreichbar. Die Installation selbst besteht aus drei Befehlen und dauert etwa eine Minute. Der größte Teil dieses Leitfadens behandelt deshalb den zweiten Abschnitt: Webmin meldet sich als root an und kann alles ausführen, was auch root ausführen kann. Ein uneingeschränkt erreichbares oder nicht authentifiziertes Webmin ist kein „Risiko, das verwaltet werden muss“, sondern eine vollständige Kompromittierung des Servers mit einer Anmeldeseite davor. Installieren Sie Webmin daher in zehn Minuten. Verwenden Sie die restliche Stunde darauf, sicherzustellen, dass nur Sie darauf zugreifen können.

Voraussetzungen und eine wichtige Warnung

Sie benötigen einen frischen Ubuntu-24.04-KVM-VPS mit root oder einem Benutzer mit sudo-Berechtigungen. Webmin basiert auf Perl und ist ressourcenschonend. 1 GB RAM ist ausreichend, und im Leerlauf benötigt Webmin deutlich weniger als ein Viertel eines Gigabytes. Webmin lauscht über seinen eigenen mitgelieferten Webserver (miniserv.pl) auf TCP-Port 10000. Apache oder nginx werden nicht verwendet. Daher müssen Sie vorab nichts weiter installieren.

Legen Sie vor dem Start zwei Dinge fest. Erstens: Mit welchem Konto melden Sie sich an? Webmin authentifiziert Unix-Konten über PAM. Sie melden sich daher als root oder als Benutzer in der Gruppe sudo mit dem Unix-Passwort dieses Kontos an. Cloud-Images verwenden beim Standardbenutzer normalerweise ausschließlich SSH-Schlüssel, und es ist kein Passwort gesetzt. Webmin kann sich nicht mit einem passwortlosen Konto anmelden. Setzen Sie zuerst mit sudo passwd youruser ein Passwort. Andernfalls schlägt die Anmeldung unabhängig von Ihrer Eingabe fehl.

Zweitens, und das ist die Warnung: Öffnen Sie Port 10000 nicht einfach für das Internet und lassen Sie ihn danach unbeaufsichtigt. Entscheiden Sie jetzt, ob Sie Webmin über einen SSH-Tunnel erreichen (empfohlen, kein Port wird öffentlich freigegeben) oder den Zugriff auf Ihre eigene IP-Adresse beschränken. Diese Entscheidung bestimmt alle folgenden Schritte. Lesen Sie daher beide Optionen, bevor Sie die Firewall ändern.

Webmin aus dem offiziellen Repository installieren

Webmin veröffentlicht ein signiertes apt-Repository. Das Einrichtungsskript fügt das Repository und dessen GPG-Signaturschlüssel hinzu. Zukünftige apt upgrade-Ausführungen installieren Webmin dadurch wie jedes andere Paket. Sie erhalten authentifizierte Updates statt eines heruntergeladenen .deb, das sich nicht selbst aktualisiert.

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh

Das Skript zeigt die geplanten Aktionen an und fragt Setup Webmin stable repository? (y/N) ab. Antworten Sie mit y. Installieren Sie nach Abschluss das Paket. Das Flag --install-recommends installiert die üblichen Abhängigkeiten für Perl- und SSL-Module. Dadurch schlagen einzelne Module später nicht wegen fehlender Bibliotheken fehl.

sudo apt-get install --install-recommends webmin

Webmin hat dieses Skript bereits umbenannt. Ältere Anleitungen verweisen auf setup-repos.sh. Wenn die ungekürzte URL daher mit einem 404-Fehler antwortet, rufen Sie den aktuellen Einzeiler direkt von webmin.com/download ab, statt einen bestimmten Namen fest zu verwenden. Eine erfolgreiche Installation endet mit einer Zeile wie Webmin install complete. You can now login to https://your-host:10000/ as root. Der Dienst ist aktiviert und läuft. Die Konfiguration befindet sich unter /etc/webmin. Anfragen werden in /var/webmin/miniserv.log protokolliert. Fehlgeschlagene Anmeldungen werden in syslog protokolliert, unter Ubuntu 24.04 im systemd-Journal.

Prüfen Sie, ob der Dienst tatsächlich läuft und auf Verbindungen wartet, bevor Sie einen Browser öffnen:

sudo systemctl status webmin --no-pager
sudo ss -tlnp | grep 10000

Erwartet werden ein active (running)-Status und eine Zeile, die zeigt, dass miniserv.pl an 0.0.0.0:10000 gebunden ist. Diese Adresse ändert sich zu 127.0.0.1:10000, sobald Sie den Tunnelweg weiter unten verwenden. Wenn ss für 10000 keine Ausgabe liefert, wurde Webmin nicht gestartet. Lesen Sie journalctl -u webmin -n 50, bevor Sie fortfahren.

Erste Anmeldung und die Zertifikatwarnung

Rufen Sie https://YOUR_SERVER_IP:10000 in Ihrem Browser auf. Bei einer frischen Installation geschehen zwei Dinge.

Wenn ufw aktiv ist, wird die Seite überhaupt nicht geladen. Das Ubuntu-Server-Image liefert ufw standardmäßig inaktiv aus, viele Anbieter aktivieren es jedoch vorab. Dieses Problem wird weiter unten im Abschnitt zu Fehlerbildern behandelt. Ist der Port geöffnet, zeigt der Browser eine ganzseitige Sperrmeldung an: „Ihre Verbindung ist nicht privat“ mit dem Code NET::ERR_CERT_AUTHORITY_INVALID in Chrome oder SEC_ERROR_UNKNOWN_ISSUER / „Warnung: Mögliches Sicherheitsrisiko erkannt“ in Firefox. Das ist zu erwarten und bedeutet keinen Einbruch. Webmin hat bei der Installation ein selbstsigniertes Zertifikat (/etc/webmin/miniserv.pem) erzeugt. Da keine Zertifizierungsstelle dieses Zertifikat bestätigt, vertraut der Browser ihm nicht automatisch. Die Verbindung ist weiterhin verschlüsselt. Das Zertifikat ist lediglich nicht von einer Zertifizierungsstelle bestätigt. Klicken Sie vorerst auf Advanced und anschließend auf Proceed. Weiter unten ersetzen wir dieses Zertifikat ordnungsgemäß.

Melden Sie sich mit root oder mit Ihrem sudo-Benutzer und dessen Unix-Passwort an. Danach wird das Dashboard System Information angezeigt. Ein häufiger Fehler ist, http:// statt https:// einzugeben. miniserv beantwortet diesen Port mit einfachem HTTP und dem exakten Text „Dieser Webserver läuft im SSL-Modus. Versuchen Sie die URL https://...“. Ändern Sie dazu einfach http in https in der Adressleiste.

Die Sicherheitsentscheidung: Wie greifen Sie auf Webmin zu?

Jetzt kommt der entscheidende Punkt. Ein Panel mit root-gleichwertigen Rechten sollte nicht offen im Internet erreichbar sein und Anmeldeversuche von jedem Scanner weltweit beantworten. Dafür gibt es zwei vertretbare Optionen, in dieser Reihenfolge. Jede selbst gehostete Administrationsoberfläche führt zu derselben Frage. Deshalb hängt die Sicherheit von Vaultwarden von seinem Admin-Endpunkt und seiner Backup-Datei ab, nicht von seiner Verschlüsselung.

Der SSH-Tunnel aus Option B ist die bessere Wahl, weil er überhaupt nichts öffentlich erreichbar macht. Die IP-Allowlist aus Option A ist vertretbar, wenn Ihre Adresse statisch ist. Keine der beiden Optionen zu verwenden, ist genau der Fehler, den dieser gesamte Leitfaden verhindern soll. Wenn Sie Webmin lieber über ein privates Netzwerk erreichen möchten, setzen Sie den Server hinter ein selbst gehostetes WireGuard-VPN und binden Sie Webmin an die Tunneladresse statt an die öffentliche Adresse.

Option A: Webmin auf Ihre IP-Adresse beschränken

Öffnen Sie im Panel Webmin, dann Webmin Configuration, dann IP Access Control. Wählen Sie „Only allow from listed addresses“ und tragen Sie Ihre öffentliche IP-Adresse ein. Diese ermitteln Sie auf Ihrem Laptop mit curl ifconfig.me. Speichern Sie die Einstellung. Webmin schreibt sie in die Zeile allow= in /etc/webmin/miniserv.conf und startet sich selbst neu.

Die Falle: Wenn Ihre Heim-IP-Adresse dynamisch ist und sich ändert oder Sie die Adresse falsch eingeben, sperren Sie sich aus. Der Browser zeigt dann „Access denied for <your IP>“ an. Es wird kein Anmeldeformular angezeigt, und es gibt keinen Webzugang, über den Sie die Sperre aufheben können. Beheben Sie das über die Serverkonsole per SSH oder über das VNC Ihres Providers:

sudo nano /etc/webmin/miniserv.conf
# find the line that begins  allow=
# correct your IP, or delete the whole line to allow all again
sudo systemctl restart webmin

Wenn Sie die Zeile allow= löschen, wird der vollständig offene Zugriff wiederhergestellt. Tun Sie das daher nur zur Wiederherstellung und setzen Sie anschließend sofort einen korrekten Wert.

Option B: An localhost binden und über SSH tunneln (empfohlen)

Besser als jede Allowlist ist es, überhaupt nicht auf der öffentlichen Schnittstelle zu lauschen. Konfigurieren Sie miniserv so, dass es nur an die Loopback-Schnittstelle gebunden wird. Greifen Sie anschließend über einen verschlüsselten SSH-Tunnel darauf zu, dem Sie bereits vertrauen.

Bearbeiten Sie /etc/webmin/miniserv.conf und fügen Sie eine Zeile hinzu oder ändern Sie eine vorhandene:

bind=127.0.0.1

Starten Sie den Dienst mit sudo systemctl restart webmin neu. Webmin ist jetzt aus dem Internet nicht mehr erreichbar. Ein Portscan auf Port 10000 findet nichts. Die zuvor ausgeführte Prüfung mit ss zeigt nun, dass der Dienst an 127.0.0.1:10000 gebunden ist. Öffnen Sie auf Ihrem Laptop einen Tunnel:

ssh -L 10000:localhost:10000 youruser@YOUR_SERVER_IP

Lassen Sie diese Sitzung geöffnet und rufen Sie https://localhost:10000 auf. Der Netzwerkverkehr läuft innerhalb von SSH. Ihre SSH-Schlüssel authentifizieren die Verbindung bereits, und der Datenverkehr ist verschlüsselt. Sie können das selbstsignierte Zertifikat hier daher bedenkenlos akzeptieren. Die eigentliche Absicherung übernimmt die SSH-Schicht. Wenn Sie die SSH-Sitzung schließen, ist Webmin nicht mehr erreichbar. Es gibt nichts auf eine Allowlist zu setzen, nichts ist öffentlich erreichbar, und es muss kein zusätzlicher Dienst abgesichert werden.

Wenn Sie bind=127.0.0.1 setzen und den Tunnel vergessen, wird der Fernzugriff einfach unterbrochen. Das ist das erwartete Verhalten und kein Fehler. Stellen Sie den Zugriff wie bei Option A wieder her: Entfernen Sie in der Konsole die Zeile bind oder setzen Sie bind=0.0.0.0. Starten Sie den Dienst anschließend neu. Dieses Tunneling-Muster verwenden Sie auch, wenn Sie eine entfernte Entwicklungsumgebung mit Claude Code in tmux erreichen möchten: eine SSH-Sitzung, alles bleibt privat, und auf der öffentlichen Schnittstelle lauscht kein zusätzlicher Dienst.

Ersetzen Sie das selbstsignierte Zertifikat durch ein echtes Zertifikat

Wenn Sie Webmin unter Option A tatsächlich veröffentlichen, können Sie die Browserwarnung mit einem echten Let's-Encrypt-Zertifikat beseitigen. Sie benötigen einen Namen für das Zertifikat und eine Möglichkeit, wie Let's Encrypt während der Validierung Port 80 erreichen kann. Dabei handelt es sich normalerweise um einen DNS-Namen, zum Beispiel panel.example.com, mit einem A-Record, der auf den Server zeigt. Seit Webmin 2.650 (veröffentlicht am 25. Juni 2026) kann auch die öffentliche IP-Adresse des Servers verwendet werden, sofern Certbot 5.3 oder höher installiert ist. Let's Encrypt stellt IP-Zertifikate nur über sein Kurzzeitprofil aus. Diese sind etwa sechs Tage gültig. Legen Sie deshalb das automatische Erneuerungsintervall von Webmin in Tagen fest. Webmin akzeptiert für ein IP-Zertifikat kein längeres Intervall.

Webmin bietet diese Funktion integriert an: Webmin, dann Webmin Configuration, dann SSL Encryption, dann die Registerkarte Let's Encrypt. Geben Sie den Hostnamen oder die IP-Adresse ein, wählen Sie eine Validierungsmethode aus und stellen Sie die Anfrage. Webmin bezieht das Zertifikat, aktualisiert die Zeilen certfile= und keyfile= in miniserv.conf und erneuert das Zertifikat automatisch vor dem Ablauf. Laden Sie die Seite neu. Das Schlosssymbol zeigt dann keine Warnung mehr an.

Der wichtige Punkt ist: Der Webmin-eigene Server läuft auf Port 10000 und nicht auf Port 80. Daher muss ein Dienst die http-01-Challenge auf Port 80 beantworten. Dafür gibt es drei Möglichkeiten. Wenn Apache oder nginx den Namen bereits auf Port 80 bedient, geben Sie das Dokumentverzeichnis dieser Website als Ziel für die Validierung an. Für eine IP-Adresse ist dafür Certbot 5.4 oder höher erforderlich. Wenn auf Port 80 kein Dienst läuft, wählen Sie den integrierten Webserver von Certbot, den Webmin ab Version 2.110 als standalone-Modus unterstützt: Certbot startet vorübergehend einen eigenen Webserver auf Port 80. Daher muss Certbot installiert sein und Port 80 muss frei sowie in Ihrer Firewall geöffnet sein. Oder verwenden Sie die DNS-Validierung. Sie funktioniert für Hostnamen, nicht jedoch für IP-Adressen. Das certbot-Paket von Ubuntu 24.04 ist in Version 2.9 verfügbar. Diese Version eignet sich für die standalone-Validierung eines Hostnamens, ist für IP-Zertifikate jedoch zu alt. Installieren Sie für IP-Zertifikate ein aktuelles Certbot, zum Beispiel das snap-Paket. Im Oktober 2026 lag dessen Version bei 5.8. Ohne eine dieser Möglichkeiten schlägt die Anfrage mit einem Validierungsfehler fehl. Die Vorgehensweise, DNS-Einträge, die Challenge auf Port 80 und die Erneuerung entsprechen der Ausstellung eines Zertifikats für eine beliebige Website. Wenn Sie die Hintergründe benötigen, beschreibt der Leitfaden Let's-Encrypt-TLS-Zertifikate mit Certbot und nginx den Validierungsablauf und die DNS-Konfiguration ausführlich. Wenn Sie den Weg über den SSH-Tunnel gewählt haben, können Sie diesen Abschnitt vollständig überspringen: Das selbstsignierte Zertifikat ist hinter SSH ausreichend. Ein für panel.example.com ausgestelltes echtes Zertifikat würde beim Aufruf von https://localhost:10000 ohnehin nur eine Warnung wegen einer nicht übereinstimmenden Namen erzeugen.

Zwei-Faktor-Authentifizierung aktivieren

Ein Passwort allein schützt ein Root-Panel nur unzureichend. Fügen Sie deshalb einen zweiten Faktor hinzu. Öffnen Sie Webmin, dann Webmin Configuration, dann Two-Factor Authentication. Wählen Sie den Anbieter Google Authenticator. Dabei handelt es sich um standardmäßiges TOTP, das mit Authy, 1Password oder einer beliebigen Authenticator-App funktioniert. Speichern Sie anschließend. Webmin installiert das benötigte kleine Perl-Modul (Authen::OATH plus einen QR-Generator) und aktiviert die Funktion. Dieser Schritt schützt noch kein Konto.

Anschließend registriert jedes Konto sein eigenes Gerät. Öffnen Sie bei aktivierter 2FA Webmin, dann Webmin Users, wählen Sie das Konto aus und wählen Sie Enable Two-Factor For User. Webmin zeigt dann einen QR-Code an. Scannen Sie ihn mit der App und geben Sie zur Bestätigung einen generierten Code ein. Danach fordert die Anmeldung nach dem Passwort das sechsstellige Token an. Führen Sie die Registrierung durch, bevor Sie sich abmelden. Wenn 2FA erforderlich ist, Ihr Konto aber noch keinen Code gescannt hat, können Sie die Anforderung weiterhin über die Konsole zurücksetzen. Die vorherige Registrierung ist jedoch deutlich weniger aufwendig.

Fail2ban einrichten, um Brute-Force-Anmeldungen zu sperren

Auch ein eingeschränkter Anmeldeendpunkt sollte wiederholte Fehlversuche sanktionieren. Webmin meldet fehlgeschlagene Anmeldungen in der Form webmin[12345]: Invalid login as root from 10.0.0.9 an syslog. Für einen Benutzernamen, der nicht einmal ein Unix-Konto ist, wird Non-existent login as ... protokolliert. Unter Ubuntu 24.04 landen diese Zeilen im systemd-Journal, da ein Standard-Image kein /var/log/auth.log enthält. Fail2ban liefert einen Standard-webmin-auth-Filter, der genau diese beiden Zeilen erkennt. Die folgende Jail-Konfiguration setzt backend = systemd selbst. Daher sind weder ein eigener regulärer Ausdruck noch ein eigener Logpfad erforderlich.

Erstellen Sie /etc/fail2ban/jail.d/webmin.local:

[webmin-auth]
enabled  = true
port     = 10000
filter   = webmin-auth
backend  = systemd
maxretry = 4
bantime  = 1h

Laden Sie die Konfiguration mit sudo systemctl restart fail2ban neu. Prüfen Sie anschließend, ob die Jail aktiv ist:

sudo fail2ban-client status webmin-auth

Die Jail sollte zunächst mit einem Ban-Zähler von 0 aufgeführt werden. Beim Journal-Backend gibt es keine Zeile mit File list:. Um die Konfiguration vollständig zu testen, führen Sie von einem anderen Netzwerk aus absichtlich mehrmals eine fehlgeschlagene Anmeldung durch. Führen Sie danach den Statusbefehl erneut aus und beobachten Sie, wie Currently banned ansteigt. Wenn der Wert nicht ansteigt, prüfen Sie, dass Sie nicht von einer Adresse aus der Fail2ban-ignoreip testen. Führen Sie außerdem journalctl SYSLOG_IDENTIFIER=webmin auf dem Server aus. Damit prüfen Sie, ob die Invalid login-Zeilen tatsächlich geschrieben werden. Falls Fail2ban auf diesem System noch nicht installiert ist, beschreibt der Fail2ban-on-Ubuntu-24.04-for-SSH-Leitfaden die Installation und die SSH-Jail, die Sie direkt zusammen mit dieser Jail aktivieren sollten.

Beschränken Sie, worauf die einzelnen Webmin-Benutzer zugreifen können

Nicht jeder Benutzer, der das Panel benötigt, braucht root-Zugriff auf alle Bereiche. Öffnen Sie Webmin, dann Webmin Users, erstellen Sie zusätzliche Webmin-Anmeldungen und weisen Sie jedem Benutzer nur die benötigten Module zu. Ein Benutzer für Backups kann beispielsweise nur die Module für cron und das Dateisystem sehen. Beim Bearbeiten eines Benutzers wird eine Checkliste mit allen Modulen angezeigt. Wenn Sie ein Modul deaktivieren, wird es aus dem Menü dieses Benutzers entfernt und der Zugriff auf die zugehörigen URLs blockiert. Das ist eine zusätzliche Schutzebene: Selbst eine gestohlene Webmin-Sitzung mit geringen Berechtigungen kann /etc/shadow nicht ändern, wenn das Modul Users nicht in der Liste enthalten ist.

Webmin aktuell halten

Da Sie Webmin aus dem apt-Repository installiert haben, installiert sudo apt update && sudo apt upgrade neue Webmin-Releases zusammen mit den übrigen Systemaktualisierungen. Installieren Sie Sicherheitsupdates umgehend, da ein Control Panel ein bevorzugtes Angriffsziel ist. Webmin kann sich auch selbst aktualisieren: Wählen Sie dazu Webmin, anschließend Webmin Configuration und dann Upgrade Webmin. Unter Ubuntu ist der Weg über apt jedoch übersichtlicher, weil die Versionen dadurch mit Ihrer übrigen Paketverwaltung konsistent bleiben. Behandeln Sie dies nicht als optional: Mehrere frühere Webmin-CVEs ermöglichten Remote-Code-Execution. Entscheidend dafür, ob ein System gepatcht oder kompromittiert war, war allein die Geschwindigkeit, mit der der Administrator das Upgrade ausführte.

Fehlerbilder und die angezeigten Meldungen

„Your connection is not private“ / NET::ERR_CERT_AUTHORITY_INVALID. Diese Meldung wird beim ersten Aufruf angezeigt. Ursache: Das selbstsignierte Zertifikat, das Webmin bei der Installation erzeugt hat, verfügt über keine vertrauenswürdige Zertifizierungsstelle. Es handelt sich nicht um einen Angriff. Die Verbindung ist verschlüsselt, aber nicht durch eine vertrauenswürdige Stelle bestätigt. Lösung: Ignorieren Sie die Warnung zunächst und stellen Sie anschließend ein echtes Let's-Encrypt-Zertifikat aus. Wenn Sie Webmin über einen SSH-Tunnel erreichen, können Sie das Zertifikat auch dauerhaft akzeptieren.

„This web server is running in SSL mode. Try the URL https://...“ Sie haben http://server:10000 eingegeben. miniserv verwendet auf diesem Port ausschließlich TLS und teilt Ihnen das im Klartext mit. Lösung: Ändern Sie http in der Adressleiste in https.

Die Seite läuft in einen Timeout, ERR_CONNECTION_TIMED_OUT / „This site can't be reached“. Die Anfrage erreicht Webmin nicht. Unter Ubuntu verwirft ufw häufig Port 10000. Prüfen Sie dies jedoch, bevor Sie davon ausgehen. Führen Sie sudo ufw status aus. Wenn der Befehl Status: inactive meldet, blockiert ufw nichts. Ubuntu liefert ufw deaktiviert aus, und das Hinzufügen einer Allow-Regel aktiviert ufw nicht. Prüfen Sie in diesem Fall die vorgelagerten Komponenten, beispielsweise eine Firewall im Control Panel Ihres Providers. Wenn der Befehl Status: active meldet, führen Sie sudo ufw status verbose aus, um die standardmäßige Richtlinie für eingehenden Verkehr und umfassendere Regeln anzuzeigen. Wenn eingehender Verkehr abgelehnt wird und Port 10000 nicht aufgeführt ist, öffnen Sie ihn entweder mit sudo ufw allow 10000/tcp oder lassen ihn besser geschlossen und verwenden den SSH-Tunnel aus Option B. Beachten Sie den Unterschied: Ein Timeout bedeutet, dass eine Firewall Pakete stillschweigend verwirft. ERR_CONNECTION_REFUSED bedeutet dagegen, dass der Port erreichbar ist, Webmin aber nicht ausgeführt wird. Prüfen Sie sudo systemctl status webmin.

„Access denied for <your IP>.“ Sie haben unter Option A eine IP-Zugriffskontrolle eingerichtet, und Ihre aktuelle Adresse steht nicht auf der Allow-Liste. Möglicherweise hat sich Ihre dynamische IP-Adresse geändert, oder es liegt ein Tippfehler vor. Über den Browser gibt es keinen Rückweg. Beheben Sie das Problem über die Konsole: Bearbeiten Sie die Zeile allow= in /etc/webmin/miniserv.conf, korrigieren oder löschen Sie sie und führen Sie sudo systemctl restart webmin aus.

„Login failed. Please try again.“ trotz bekanntermaßen korrekter Zugangsdaten. Für das Konto ist kein Unix-Passwort gesetzt. Das ist bei Cloud-Images üblich, die ausschließlich die Anmeldung per Schlüssel erlauben. Webmin authentifiziert sich über PAM anhand des Unix-Passworts. Für den Benutzer ist jedoch kein solches Passwort vorhanden. Lösung: Führen Sie auf dem Server sudo passwd youruser aus und melden Sie sich anschließend an. Wenn /var/webmin/miniserv.log Non-existent login as ... anzeigt, verwenden Sie einen Benutzernamen, der überhaupt kein Unix-Konto ist.

Bei mehr als einigen Servern lässt sich die Automatisierung besser skalieren als ein Control Panel auf jedem einzelnen System: Ihr erstes Ansible-Playbook ist der Ausgangspunkt.

FAQ

Ist es sicher, Webmin über das öffentliche Internet erreichbar zu machen?

Betrachten Sie ein Webmin mit Internetzugriff wie eine Root-Shell mit Anmeldeseite, denn genau das ist es. Es ist nur dann ausreichend sicher, wenn es in Schichten abgesichert ist: ein echtes Zertifikat, Zwei-Faktor-Authentifizierung, Fail2ban und entweder eine strikte IP-Whitelist oder, noch besser, gar keine öffentliche Erreichbarkeit. Die Konfiguration mit dem geringsten Risiko bindet Webmin an 127.0.0.1 und greift über einen SSH-Tunnel darauf zu, sodass Port 10000 im offenen Internet auf keine Anfragen antwortet.

Wie werde ich die Zertifikatswarnung von Webmin los?

Die Warnung (NET::ERR_CERT_AUTHORITY_INVALID) erscheint, weil Webmin mit einem selbstsignierten Zertifikat ausgeliefert wird. Stellen Sie ein echtes Zertifikat über Webmin, Webmin Configuration, SSL Encryption, Let's Encrypt aus. Verwenden Sie einen DNS-Namen, der auf den Server zeigt, oder die öffentliche IP-Adresse des Servers, sofern Certbot 5.3 oder neuer installiert ist. Port 80 muss für die Challenge erreichbar sein; diese wird entweder von einem bestehenden Webserver oder dem eigenen Standalone-Server von Certbot beantwortet. Wenn Sie Webmin ausschließlich über einen SSH-Tunnel zu localhost erreichen, ist die Warnung harmlos, da SSH die Verbindung bereits verschlüsselt und authentifiziert; Sie können das selbstsignierte Zertifikat in diesem Fall bedenkenlos akzeptieren.

Wie beschränke ich Webmin auf meine IP-Adresse?

Gehen Sie zu Webmin, Webmin Configuration, IP Access Control, wählen Sie "Only allow from listed addresses" und geben Sie Ihre öffentliche IP von curl ifconfig.me ein. Webmin speichert dies in der Zeile allow= der Datei /etc/webmin/miniserv.conf. Achten Sie auf eine dynamische IP-Adresse zu Hause: Wenn sich diese ändert, sind Sie ausgesperrt und müssen die Zeile allow= über die Serverkonsole reparieren. Eine statische Adresse oder die SSH-Tunnel-Methode ist in der Praxis daher zuverlässiger.

Warum schlägt mein Login trotz korrektem Passwort fehl?

Webmin authentifiziert sich über PAM gegen Ihr Unix-Passwort. Cloud-Images verwenden für das Standardkonto normalerweise ausschließlich Schlüssel, und für dieses Konto ist in der Regel kein Passwort gesetzt; daher gibt es für PAM keine Übereinstimmung und der Login wird abgelehnt. Führen Sie sudo passwd youruser auf dem Server aus, um ein Passwort festzulegen, und melden Sie sich dann an. Eine Zeile Non-existent login as ... in /var/webmin/miniserv.log bedeutet hingegen, dass der Benutzername selbst kein echtes Unix-Konto ist.

Wofür ist Webmin im Vergleich zu reinem SSH nützlich?

Webmin ist eine Ebene für Auffindbarkeit und Komfort. Es ist tatsächlich nützlich, um Logdateien zu durchsuchen, Benutzer und Cron-Jobs zu verwalten, Firewall-Regeln zu bearbeiten sowie den Status von Festplatten und Diensten einzusehen, ohne jeden Befehl auswendig lernen zu müssen – praktisch für gelegentliche Administratoren oder Teams mit unterschiedlichen Kenntnissen. Reines SSH ist schneller, skriptfähig und bietet für Routineaufgaben eine weitaus geringere Angriffsfläche. Viele Administratoren nutzen beides: SSH für die tägliche Arbeit und Webmin, gebunden an localhost hinter einem Tunnel, für gelegentliche Point-and-Click-Aufgaben. Wenn Ihre eigentliche Frage eher die Wahl des Panels als der Vergleich zwischen Panel und Shell ist, lohnt es sich, zuerst Cockpit im Vergleich zu Webmin abzuwägen, da sich beide darin unterscheiden, wie viel sie tatsächlich am System ändern können und wie sie Sie authentifizieren.