SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-08-13

Webmin auf Ubuntu 24.04 installieren und absichern

Installieren Sie Webmin auf Ubuntu 24.04 und sichern Sie Port 10000 per SSH-Tunnel oder IP-Whitelist, Let's Encrypt, Zwei-Faktor-Anmeldung und Fail2ban.

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 stellt ein signiertes apt-Repository bereit. Das Setup-Skript fügt das Repository und dessen GPG-Signaturschlüssel hinzu. Dadurch laden künftige apt upgrade-Ausführungen Webmin 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 repository? (y/N). Antworten Sie mit y. Installieren Sie anschließend 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 Raw-URL den Status 404 zurückgibt, rufen Sie den aktuellen One-Liner direkt von webmin.com/download ab, statt einen Namen fest vorzugeben. Eine korrekte 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 an syslog und unter Ubuntu 24.04 an das systemd-Journal gesendet.

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

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

Sie benötigen einen active (running)-Status sowie 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 die unten beschriebene Tunnel-Variante verwenden. Wenn ss für Port 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.

Ein selbstsigniertes Zertifikat durch ein echtes ersetzen

Wenn Sie Webmin unter Option A über einen Hostnamen erreichbar machen, können Sie die Browserwarnung mit einem echten Let's-Encrypt-Zertifikat beseitigen. Sie benötigen einen DNS-Namen, zum Beispiel panel.example.com, mit einem A-Record, der auf den Server zeigt, sowie einen Dienst, der während der Validierung die HTTP-Challenge über Port 80 beantwortet.

Webmin unterstützt dies direkt: Webmin, dann Webmin Configuration, dann SSL Encryption, dann die Registerkarte Let's Encrypt. Tragen Sie den Hostnamen ein, setzen Sie das Feld "website root directory" auf einen Pfad, der für diese Domain über Port 80 ausgeliefert wird, und fordern Sie das Zertifikat an. Webmin stellt das Zertifikat aus, aktualisiert die Zeilen certfile= und keyfile= in miniserv.conf automatisch und erneuert es vor dem Ablaufdatum. Laden Sie die Seite neu. Das Schlosssymbol zeigt dann eine gültige Verbindung an.

Der entscheidende Punkt: Der Webmin-eigene Server läuft auf Port 10000 und nicht auf Port 80. Für die http-01-Challenge muss daher ein echter Webserver wie Apache oder nginx panel.example.com über Port 80 beantworten. Alternativ ist eine DNS-basierte Validierung möglich. Auf einem reinen Webmin-System ohne Dienst auf Port 80 schlägt die Anforderung mit einem Validierungsfehler fehl, bis Sie Let's Encrypt den Zugriff auf die Challenge-Datei ermöglichen. Die Vorgehensweise, die DNS-Einträge, die Challenge über Port 80 und die Erneuerung entsprechen der Ausstellung eines Zertifikats für jede andere Website. Wenn Sie diesen Hintergrund benötigen, beschreibt der Leitfaden zu Let's-Encrypt-TLS-Zertifikaten mit Certbot und nginx den Validierungsablauf und die DNS-Einrichtung ausführlich. Wenn Sie den SSH-Tunnel verwenden, können Sie diesen Abschnitt vollständig überspringen: Hinter SSH ist das selbstsignierte Zertifikat ausreichend. Ein echtes Zertifikat für panel.example.com würde beim Aufruf von https://localhost:10000 ohnehin nur eine Warnung wegen einer nicht übereinstimmenden Namensangabe 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 von Webmin bei der Installation erzeugte selbstsignierte Zertifikat hat 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. Alternativ können Sie das Zertifikat dauerhaft akzeptieren, wenn Sie Webmin über einen SSH-Tunnel erreichen.

„This web server is running in SSL mode. Try the URL https://...“ Sie haben http://server:10000 eingegeben. miniserv spricht auf diesem Port ausschließlich TLS und weist in Klartext darauf hin. Lösung: Ändern Sie http in https in der Adressleiste.

Die Seite läuft in einen Timeout, ERR_CONNECTION_TIMED_OUT / „This site can't be reached“. Die Anfrage erreicht Webmin nicht. Unter Ubuntu lässt ufw fast immer Port 10000 fallen. Prüfen Sie dies mit sudo ufw status. Wenn 10000 nicht aufgeführt ist, öffnen Sie den Port entweder mit sudo ufw allow 10000/tcp oder lassen Sie ihn besser geschlossen und verwenden Sie 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 läuft. Prüfen Sie dies mit sudo systemctl status webmin.

„Access denied for <your IP>.“ Sie haben unter Option A die IP-Zugriffskontrolle aktiviert, und Ihre aktuelle Adresse steht nicht auf der Allow-Liste. Möglich sind auch eine geänderte dynamische IP-Adresse oder ein Tippfehler. Über den Browser gibt es keinen Weg zurück. 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 gegen das Unix-Passwort. Für diesen Benutzer ist jedoch kein solches Passwort vorhanden. Lösung: Führen Sie sudo passwd youruser auf dem Server 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 wenigen 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 im öffentlichen Internet bereitzustellen?

Behandeln Sie ein aus dem Internet erreichbares Webmin wie eine Root-Shell mit einer Anmeldeseite, denn genau das ist es. Es ist nur dann ausreichend sicher, wenn mehrere Schutzschichten vorhanden sind: ein gültiges Zertifikat, Zwei-Faktor-Authentifizierung, Fail2ban und entweder eine restriktive IP-Allowlist oder, besser, überhaupt keine öffentliche Erreichbarkeit. Die risikoärmste Konfiguration bindet Webmin an 127.0.0.1 und greift über einen SSH-Tunnel darauf zu. Dadurch nimmt Port 10000 keine Verbindungen aus dem offenen Internet an.

Wie entferne ich die Zertifikatswarnung von Webmin?

Die Warnung (NET::ERR_CERT_AUTHORITY_INVALID) erscheint, weil Webmin mit einem selbstsignierten Zertifikat ausgeliefert wird. Stellen Sie in Webmin unter Webmin, Webmin Configuration, SSL Encryption, Let's Encrypt ein gültiges Zertifikat aus. Verwenden Sie dafür einen DNS-Namen, der auf den Server zeigt, und stellen Sie für die Validierung einen Dienst bereit, der die Challenge auf Port 80 beantwortet. Wenn Sie Webmin ausschließlich über einen SSH-Tunnel zu localhost erreichen, ist die Warnung unproblematisch. SSH verschlüsselt und authentifiziert die Verbindung bereits, und Sie können das selbstsignierte Zertifikat sicher akzeptieren.

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

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

Warum schlägt meine Anmeldung trotz des richtigen Passworts fehl?

Webmin authentifiziert sich über PAM anhand Ihres Unix-Passworts. Cloud-Images sind beim Standardkonto normalerweise auf die Anmeldung per Schlüssel beschränkt, und es ist kein Passwort gesetzt. Daher gibt es für PAM keinen passenden Wert, und die Anmeldung wird abgewiesen. Führen Sie auf dem Server sudo passwd youruser aus, um ein Passwort zu setzen, und melden Sie sich anschließend an. Eine Zeile Non-existent login as ... in /var/webmin/miniserv.log bedeutet dagegen, dass der Benutzername selbst kein echtes Unix-Konto ist.

Wofür eignet sich Webmin im Vergleich zu reinem SSH?

Webmin bietet eine übersichtliche und komfortable Verwaltungsebene. Es eignet sich besonders zum Durchsuchen von Logdateien, Verwalten von Benutzern und Cron-Jobs, Bearbeiten von Firewall-Regeln sowie Anzeigen des Festplatten- und Dienstestatus, ohne dass Sie sich jeden Befehl merken müssen. Das ist für gelegentliche Administratoren oder Teams mit unterschiedlichen Kenntnisständen praktisch. Reines SSH ist schneller, lässt sich skripten und bietet bei Routineaufgaben eine deutlich kleinere Angriffsfläche. Viele Administratoren verwenden beides: SSH für die tägliche Arbeit und Webmin, an localhost gebunden und über einen Tunnel erreichbar, für gelegentliche Aufgaben per Mausklick. Wenn es bei Ihrer eigentlichen Frage um die Wahl zwischen Administrationsoberflächen und Shell geht, sollten Sie zunächst Cockpit und Webmin vergleichen, da sich beide darin unterscheiden, wie viele Systemänderungen sie tatsächlich vornehmen können und wie sie Sie authentifizieren.