Tags: ESXi, Troubleshooting, Authentifizierung
Hat man mehrmals versucht, sich mit einem falschen root-Kennwort an einem ESXi-Host anzumelden, dann wird das Konto für eine konfigurierbare Zeitspanne gesperrt. Währenddessen ist ein Login per SSH oder am Host-Client nicht möglich, aber mit korrektem root-Passwort an der DCUI. Dort kann man das Konto entsperren.
Standardmäßig gilt bei ESXi 6.x folgendes Sperrverhalten bei ungültigen Login-Versuchen:
- Maximal 10 fehlgeschlagene Versuche sind zulässig, bevor das Konto gesperrt wird.
- Die Kennwortsperre ist in SSH und im vSphere Web Service SDK aktiv, aber nicht auf dem Direct Console Interface (DCUI) und der ESXi-Shell.
- Die ungültigen Anmeldeversuche und die Kontosperrung werden in den Log-Dateien hostd.log und auth.log protokolliert.
Die mit ESXi 6 eingeführte Kontosperrfunktion für den root-Account erhöht den Sperrzeitgeber nach einer bestimmten Anzahl fehlgeschlagener Anmeldeversuche schrittweise auf bis zu 900 Sekunden. Dieser Zeitgeber scheint kumulativ zu sein.
Root-Konto entsperren
Zum Lösen des Problems meldet man sich zunächst an der DCUI an, die ja von der Sperre nicht betroffen ist. Das klappt natürlich nur, wenn man das Passwort kennt und der Lock-out durch externe Programme oder dritte Personen verursacht wurde. Wenn Sie das Passwort vergessen haben, dann führt kein Weg an der Neuinstallation des Hosts vorbei.
Auf der DCUI aktiviert man dann die ESXi-Shell. Sie erlaubt es, sich interaktiv mit dem Host zu verbinden und Befehle abzusetzen. Um festzustellen, wie viele fehlgeschlagene Anmeldeversuche es gegeben hat, setzt man folgendes Kommando ab:
pam_tally2 --user root
Für das Zurücksetzen des Passwort-Locks verwendet man dann
pam_tally2 --user root –reset
Kontosperren vermeiden
Tools wie ILO, IDRAC oder solche, die IPMI nutzen, können der Auslöser des Problems sein, aber auch Monitoring-Software. Wenn solche Programme einen Host permanent kontaktieren, aber nicht richtig konfiguriert sind, dann ist die Zahl der ungültigen Anmeldungen schnell erreicht.
Unversehens zu Kontosperren kann es auch kommen, wenn das Management-Netzwerk aus einem öffentlichen Netzwerk erreichbar ist. In diesem Fall setzt man sich Brute-Force-SSH-Bot-Angriffen aus, die dann eine vom Nutzer nicht bemerkte Kontosperre auslösen.
Soll der Host aus einem öffentlichen Netzwerk oder per Remote-Steuerung erreichbar sein, kann es helfen, die integrierte Firewall so konfigurieren, dass nur der Datenverkehr von vertrauenswürdigen Netzwerken akzeptiert wird.
Mit den folgenden Befehlen kann nur das Netzwerk a.b.c.d / e auf den vSphere-Webclient und SSH zugreifen.
Ansonsten kann man alternativ SSH deaktivieren oder warten, bis die Sperre abläuft.
Täglich Know-how für IT-Pros mit unserem Newsletter
Seine Themenschwerpunkte sind Virtualisierung und Cloud Computing, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zertifizierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas ist außerdem zertifizierter AWS Solutions Architect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Administrator.
Thomas führt aktuell jeden zweiten Montag einen 4-tägigen Grundlagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Informationen und Anmeldung über sein AWS-Blog.
Verwandte Beiträge
- Event-ID 14,4771: Benutzer können sich nach November-Update nicht anmelden
- Authentifizierung am Active Directory mittels Zertifikat scheitert nach Mai-Update
- VMware bringt App mit Benachrichtigungen zu Patches, Schwachstellen und Troubleshooting
- Sicherheitsstandards verwalten: Microsoft 365 erzwingt unerwünschte MFA-Registrierung
- Troubleshooting von VMware vSphere: Logs, Events und Tasks
Weitere Links