Ubuntu: VPS-root-Passwort mit passwd ändern

So ändern Sie das root-Passwort Ihres VPS unter Ubuntu

Um das root-Passwort Ihres VPS (Virtual Private Server) unter Ubuntu zu ändern, öffnen Sie eine SSH-Sitzung (Secure Shell) als Benutzer, der sudo ausführen darf, und führen Sie anschließend sudo passwd root aus. Der Befehl fordert das neue Passwort zweimal an. Das alte Passwort wird nicht abgefragt, weil sudo Ihre Identität bereits bestätigt hat. Um stattdessen Ihr eigenes Anmeldepasswort zu ändern, führen Sie passwd ohne Argumente aus. In diesem Fall werden Sie zuerst nach Ihrem aktuellen Passwort gefragt.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

Damit ist der Vorgang abgeschlossen. Im Folgenden geht es um die Fälle, in denen Probleme auftreten: Sie prüfen, ob das neue Passwort funktioniert, bevor Sie die Sitzung verlieren, über die Sie den Fehler noch beheben könnten, setzen Passwörter aus einem Skript, lassen ein Passwort absichtlich ablaufen und erhalten wieder Zugriff, wenn das Passwort bereits verloren ist.

Öffnen Sie eine zweite Sitzung, bevor Sie ein Passwort ändern

Öffnen Sie jetzt eine zweite SSH-Sitzung und lassen Sie sie verbunden. Fast jeder Fehler in dieser Anleitung lässt sich in zwei Minuten beheben, solange noch eine authentifizierte Shell aktiv ist. Sobald auch die letzte Sitzung geschlossen ist, ist dafür möglicherweise ein Zugriff über die Konsole erforderlich.

Eine bereits geöffnete Shell funktioniert weiter, nachdem Sie das zugehörige Konto ändern, sperren oder dessen Gültigkeit ablaufen lassen. SSH prüft die Zugangsdaten bei der Anmeldung und prüft sie danach nicht erneut. Die Ausnahme ist sudo. Dieses Programm prüft Ihr Passwort über PAM (Pluggable Authentication Modules) erneut, sobald der Zeitstempel abläuft. Das geschieht standardmäßig 15 Minuten nach der letzten Passwortabfrage. Das neue Passwort wird daher erstmals tatsächlich beim nächsten Start von sudo geprüft, nicht bei der Anmeldung.

Testen Sie das neue Passwort in der zweiten Sitzung, während die erste Sitzung geöffnet bleibt.

Eigenes Passwort mit passwd ändern

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully ist die einzige Ausgabe, die bedeutet, dass der Hash in /etc/shadow ersetzt wurde. Bei jeder anderen Ausgabe bleibt das alte Passwort bestehen.

Hier treten zwei Fehler auf. passwd: Authentication token manipulation error, gefolgt von passwd: password unchanged, bedeutet, dass das eingegebene aktuelle Passwort falsch war oder dass das Dateisystem mit /etc/shadow nicht beschreibbar ist. Letzteres ist im Recovery-Modus der Normalfall. You must choose a longer password. stammt aus pam_unix in /etc/pam.d/common-password. Diese Prüfung erzwingt für normale Benutzer Längen- und Ähnlichkeitsregeln.

Auf den meisten VPS-Images hat das Standardkonto (ubuntu oder der von Ihrem Provider vergebene Name) überhaupt kein Passwort, sondern nur einen SSH-Schlüssel. passwd hat kein aktuelles Passwort, das geprüft werden kann, und kommt deshalb nicht über die erste Eingabeaufforderung hinaus. Verwenden Sie stattdessen sudo passwd $USER. Das funktioniert, weil die Sudoers-Drop-in-Datei des Images diesem Konto erlaubt, sudo ohne Passwort auszuführen.

Passwort eines anderen Benutzers mit sudo passwd ändern

sudo passwd deploy

Root wird nicht nach dem alten Passwort gefragt. Außerdem überspringt pam_unix die für normale Benutzer geltenden Prüfungen der Passwortstärke. Root kann daher ein Passwort setzen, das der Benutzer nicht selbst hätte setzen können.

Das Sperren des Passworts ist eine separate Aktion. sudo passwd -l deploy setzt ein ! vor den gespeicherten Hash. Dadurch passt kein Passwort mehr dazu. sudo passwd -u deploy entfernt es wieder. Lesen Sie den Status mit sudo passwd -S deploy aus.

Das Sperren des Passworts verhindert nicht, dass sich der Benutzer anmeldet. Jeder Schlüssel in seiner ~/.ssh/authorized_keys funktioniert weiterhin, weil die Authentifizierung mit öffentlichen Schlüsseln /etc/shadow nie ausliest. Um ein Konto vollständig zu sperren, müssen Sie das Konto selbst ablaufen lassen:

sudo usermod --expiredate 1 deploy

Dadurch wird der Ablauf des Kontos auf ein Datum im Jahr 1970 gesetzt. sshd verweigert die Anmeldung dann unabhängig vom angebotenen Anmeldedatenträger. Machen Sie dies mit sudo usermod --expiredate '' deploy rückgängig.

Vermeiden Sie passwd -d. Damit wird ein leeres Passwort statt eines gesperrten Passworts gesetzt. Bei einer älteren Version, die nullok weiterhin im PAM-Stack verwendet, kann ein leeres Passwort von jedem verwendet werden.

Benötigt root auf einem VPS ein Passwort?

Ubuntu wird mit einem gesperrten root-Konto ausgeliefert. /etc/shadow setzt ! anstelle eines Hashes ein, und sudo passwd -S root gibt eine Zeile aus, die mit root L beginnt. Ohne dass Sie ein Passwort setzen, kann sich niemand per Passwort als root anmelden. Deshalb stellt das Image stattdessen einen Benutzer mit sudo-Berechtigung bereit. Arbeiten Sie weiterhin mit Benutzerkonten mit geringsten Berechtigungen auf einem VPS und nicht als root.

Ein root-Passwort bietet genau einen Vorteil: Es ermöglicht den Zugang über die Konsole des Providers. Diese Konsole verbindet sich unterhalb des Netzwerk-Stacks mit der virtuellen Maschine. Sie funktioniert daher auch dann, wenn sshd falsch konfiguriert ist oder eine Firewall-Regel nicht stimmt. Das hat jedoch einen Nachteil. Die root-Shell im GRUB-Wiederherstellungsmenü verlangt das root-Passwort, sobald für root eines gesetzt ist. Das Werkzeug, mit dem Sie ein vergessenes Passwort zurücksetzen würden, ist dann durch dasselbe Passwort geschützt.

Ein root-Passwort ermöglicht keine Anmeldung von root über SSH. Ubuntu wird mit PermitRootLogin prohibit-password ausgeliefert. Das bedeutet: Es sind nur Schlüssel zulässig. Prüfen Sie, welche Einstellung Ihr Server tatsächlich verwendet:

sudo sshd -T | grep -i permitrootlogin

sshd -T gibt die effektive Konfiguration aus, nachdem jede Include-Zeile aufgelöst wurde. Sobald /etc/ssh/sshd_config.d/ Drop-in-Dateien enthält, ist dies daher die einzige verlässliche Antwort.

Passwort aus einem Skript mit chpasswd setzen

passwd liest aus dem Terminal und kann nicht aus einem Skript gesteuert werden. chpasswd liest user:password-Paare aus der Standardeingabe, jeweils eines pro Zeile.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

Das funktioniert, schreibt jedoch ein Klartextpasswort in Ihre Shell-History und in Ihre CI-Logs (Continuous Integration). Erzeugen Sie stattdessen zuerst den Hash:

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6 fordert das Passwort zweimal ohne Echo an und gibt anschließend einen SHA-512-Crypt-Hash aus, der mit $6$ beginnt. -e teilt chpasswd mit, dass das zweite Feld bereits gehasht ist. Es wird daher unverändert in /etc/shadow übernommen. Der Hash kann sicher in einem Repository oder als CI-Variable gespeichert werden. Das Klartextpasswort verlässt niemals den Rechner, auf dem Sie es eingegeben haben.

Ubuntu 24.04 hasht neue Passwörter mit yescrypt ($y$), wenn passwd sie setzt. openssl passwd -6 verwendet dagegen SHA-512. Beide Formate werden bei der Anmeldung überprüft, weil libxcrypt beide Formate lesen kann. Eine Mischung ist unproblematisch. openssl passwd -6 verhält sich in jedem Ubuntu-LTS-Release gleich. Das gilt für chpasswd -c YESCRYPT nicht: Das ältere shadow-Paket in 20.04 kennt diesen Methodennamen nicht. Diese Hashes bleiben auch bei einem Release-Upgrade erhalten. Das Upgrade eines 24.04-Servers auf 26.04 zwingt Sie daher nicht dazu, Passwörter zurückzusetzen.

Wie prüfen Sie, ob das Passwort tatsächlich geändert wurde?

Beginnen Sie mit den Metadaten und weisen Sie die Änderung anschließend mit einer Anmeldung nach.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

Das zweite Feld enthält den Status: P steht für ein verwendbares Passwort, L für ein gesperrtes Passwort und NP dafür, dass überhaupt kein Passwort gesetzt ist. Das Datum gibt an, wann das Passwort zuletzt geändert wurde. Es sollte dem heutigen Datum entsprechen. Die nachfolgenden Zahlen sind die unten beschriebenen Felder für die Passwortalterung.

Der sicherste Test am laufenden System ist sudo selbst. sudo -k verwirft den zwischengespeicherten Zeitstempel, und sudo -v erzwingt eine neue Eingabeaufforderung. Wenn das neue Passwort dort akzeptiert wird, hat PAM es akzeptiert, und an Ihrer Sitzung wurde nichts geändert.

sudo -k && sudo -v

Um ein anderes Konto zu testen, führen Sie su - deploy aus einer Shell ohne privilegierte Rechte aus. Führen Sie nicht sudo su - deploy aus, weil root nie nach einem Passwort gefragt wird und der Test daher nichts beweist. Bei einem falschen Passwort wird su: Authentication failure ausgegeben.

Der eigentliche Test ist eine neue SSH-Anmeldung von Ihrem Laptop, während die funktionierende Sitzung weiterhin geöffnet bleibt:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). bedeutet hier, dass der Server keine Passwortauthentifizierung angeboten hat. Eine Passwortänderung ermöglicht dann keine Anmeldung. Permission denied, please try again. bedeutet, dass der Server die Passwortauthentifizierung angeboten, die eingegebene Eingabe aber abgelehnt hat.

Eine Passwortänderung bei der nächsten Anmeldung mit chage erzwingen

sudo chage -d 0 deploy

-d 0 setzt das Datum der letzten Änderung auf die Unix-Epoche. Dadurch behandelt PAM das Passwort als abgelaufen. Bei der nächsten interaktiven Anmeldung wird zunächst das aktuelle Passwort und anschließend ein neues Passwort abgefragt, bevor eine Shell gestartet wird. sudo passwd -e deploy bewirkt genau dasselbe.

Verwenden Sie dies nur für Konten, bei denen eine interaktive Anmeldung mit Passwort erfolgt. Ein abgelaufenes Passwort wirkt sich auch auf schlüsselbasierte Anmeldungen aus, weil sshd die PAM-Account-Phase ausführt, selbst wenn ein Schlüssel die Authentifizierung übernommen hat. Ein skriptgesteuertes ssh deploy@203.0.113.10 'systemctl restart app' schlägt dann mit dieser Meldung fehl und wird beendet:

Password change required but no TTY available.

Nach dieser Zeile wird nichts mehr ausgeführt. Der Auftrag meldet lediglich einen Exit-Code ungleich 0.

Bedeutung der Felder für den Ablauf von Passwörtern

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Diese Zahlen sind die Felder 4 bis 8 der Zeile dieses Benutzers in /etc/shadow. Die minimale Anzahl an Tagen (chage -m) gibt an, wie lange der Benutzer vor der nächsten Änderung warten muss. Dadurch kann ein Benutzer nach einer erzwungenen Änderung nicht sofort wieder das alte Passwort verwenden. Die maximale Anzahl an Tagen (chage -M) gibt an, wie lange das Passwort gültig bleibt. Die Anzahl der Warntage (chage -W) legt fest, ab wann Anmeldungen eine Warnung ausgeben. Die Anzahl der inaktiven Tage (chage -I) ist die Kulanzfrist nach dem Ablauf. Danach wird das Passwort nicht mehr akzeptiert. Der Ablauf des Kontos (chage -E) ist ein festes Datum und unabhängig vom Passwort.

sudo chage -M 90 -W 14 deploy

Setzen Sie diesen Wert nur, wenn eine Richtlinie dies erfordert. NIST (das US-amerikanische National Institute of Standards and Technology) rät seit 2017 von einem routinemäßigen Passwortablauf ab. Dieser führt dazu, dass Benutzer vorhersehbare Varianten desselben Passworts verwenden. Stattdessen empfiehlt NIST, eine Änderung zu erzwingen, sobald Hinweise auf eine Kompromittierung vorliegen. Ein langes, eindeutiges Passwort in einem Passwortmanager zusammen mit SSH auf Basis kryptografischer Schlüssel ist sicherer als ein Zyklus von 90 Tagen.

Was tun, wenn Sie das root-Passwort verloren haben

Wenn ein beliebiges Konto auf dem Server sudo ausführen darf, muss nichts wiederhergestellt werden: sudo passwd root setzt ein neues Passwort. Schwieriger ist der Fall, wenn überhaupt keine funktionierende Anmeldung mehr möglich ist.

Für alle folgenden Schritte benötigen Sie die Provider-Konsole. Sie wird in vielen Bedienfeldern als VNC (Virtual Network Computing) oder serielle Konsole aufgeführt. Sie stellt die Verbindung unterhalb des Netzwerk-Stacks zur virtuellen Maschine her. Daher haben sshd-Einstellungen und Firewall-Regeln keinen Einfluss darauf.

1. Starten Sie den Server über das Bedienfeld neu und beobachten Sie die Konsole.
2. Öffnen Sie das GRUB-Menü. Bei Cloud-Images ist normalerweise GRUB_TIMEOUT=0 gesetzt. Halten Sie bei einem BIOS-Start Shift gedrückt. Bei einem UEFI-Start drücken Sie Esc wiederholt, sobald der Neustart beginnt.
3. Wählen Sie Advanced options for Ubuntu, anschließend den Eintrag, der mit (recovery mode) endet, und danach root im Recovery-Menü.
4. Führen Sie zuerst mount -o remount,rw / aus. Recovery bindet das Root-Dateisystem schreibgeschützt ein. Ohne diesen Schritt schlägt passwd mit passwd: Authentication token manipulation error fehl, weil /etc/shadow nicht geschrieben werden kann.
5. Führen Sie passwd ubuntu für das benötigte Konto aus und starten Sie den Server anschließend über das Bedienfeld neu.

Wenn für root bereits ein Passwort gesetzt ist und Sie genau dieses verloren haben, fordert diese Recovery-Shell das Passwort an. Dieser Weg ist dann nicht möglich. Starten Sie stattdessen das Rescue-Image des Providers. Binden Sie anschließend die tatsächliche Festplatte ein und ändern Sie das Passwort innerhalb dieses Systems.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

Lesen Sie das Partitionslayout mit lsblk aus, statt /dev/vda1 von dieser Seite zu übernehmen. Die Root-Partition ist die große Partition. Bei einem UEFI-Image liegt sie neben einer kleinen EFI-Partition, die überhaupt kein /etc-Verzeichnis enthält.

Was tun, wenn SSH Ihr Passwort nicht mehr akzeptiert

Arbeiten Sie in der Sitzung weiter, die noch besteht. Wenn keine Sitzung mehr offen ist, verwenden Sie die Konsole.

Permission denied, please try again. bedeutet, dass der Server Passwortauthentifizierung angeboten und die von Ihnen gesendeten Anmeldedaten abgelehnt hat. Häufige Ursachen sind die aktivierte Feststelltaste oder ein Konsolentastaturlayout, das sich von dem beim Festlegen des Passworts verwendeten Layout unterscheidet.

Permission denied (publickey). bedeutet, dass der Server keine Passwortauthentifizierung angeboten hat. PasswordAuthentication no ist an einer Stelle aktiviert. Unter Ubuntu 22.04 und höher befindet sich die Einstellung normalerweise in einer Drop-in-Datei unter /etc/ssh/sshd_config.d/, die die Hauptdatei überschreibt. Lesen Sie die effektiven Werte aus:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes zusammen mit PasswordAuthentication no lässt weiterhin eine Passworteingabe zu, weil die Methode für interaktive Tastatureingaben denselben PAM-Stack verwendet. Wenn eine der beiden Methoden deaktiviert und die andere aktiviert bleibt, akzeptiert ein scheinbar ausschließlich schlüsselbasierter Server weiterhin eingegebene Passwörter.

Too many authentication failures in einer Meldung zum Verbindungsabbruch bedeutet, dass Ihr Client mehrere Schlüssel angeboten hat, bevor er das Passwort versuchte, und der Server MaxAuthTries erreicht hat. Der Standardwert ist 6. Erzwingen Sie eine einzelne Methode:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

Connection refused an einem Port, der vor einer Minute noch funktioniert hat, bedeutet normalerweise, dass fail2ban SSH überwacht und Ihre Adresse nach mehreren Fehlversuchen gesperrt hat. Die Standardregel für die Sperre weist das Paket zurück, anstatt es zu verwerfen. Deshalb kommt die Ablehnung schnell zurück, statt in einen Timeout zu laufen. Über die Konsole listet sudo fail2ban-client status sshd die gesperrten Adressen auf, und sudo fail2ban-client set sshd unbanip 203.0.113.10 hebt die Sperre für Ihre Adresse auf.

Passwörter sind ein Zwischenschritt, Schlüssel sind das Ziel

Ein Passwort, das über SSH funktioniert, kann jeder Scanner im Internet ausprobieren. Wechseln Sie zur schlüsselbasierten Authentifizierung. Dann spielen solche Rateversuche keine Rolle mehr. Erzeugen Sie ein Schlüsselpaar, installieren Sie den öffentlichen Schlüssel und prüfen Sie in einem zweiten Terminal, dass Sie sich damit anmelden können, bevor Sie weitere Änderungen vornehmen. Grundlagen der SSH-Schlüsselverwaltung behandelt die Erzeugung, authorized_keys und Passphrasen.

Deaktivieren Sie anschließend die Passwortauthentifizierung. Überprüfen Sie die Einstellung mit sudo sshd -T, statt sich auf die bearbeitete Datei zu verlassen. SSH auf einem VPS härten behandelt die übrigen sshd-Einstellungen, deren Änderung sinnvoll ist. Die ersten zehn Minuten auf einem neuen VPS ordnet diese Schritte für einen frisch eingerichteten Server.

Bewahren Sie danach ein Passwort auf. Ein Server, der ausschließlich Schlüssel akzeptiert, ist bei einer fehlerhaften sshd-Konfiguration nur noch über die Provider-Konsole erreichbar. Diese Konsole verlangt einen Benutzernamen und ein Passwort. Ein Konto mit einem starken, gespeicherten Passwort entscheidet darüber, ob die Reparatur fünf Minuten dauert oder eine Neuinstallation erforderlich ist.

FAQ

Wie ändere ich das root-Passwort auf meinem VPS, wenn ich das alte nicht kenne?

Melden Sie sich als Benutzer an, der sudo ausführen darf, und führen Sie sudo passwd root aus. Damit wird ein neues Passwort gesetzt, ohne nach dem alten zu fragen, weil sudo Sie bereits authentifiziert hat. Wenn kein Konto auf dem System sudo ausführen darf, öffnen Sie die Provider-Konsole, starten Sie im GRUB-Recovery-Menü neu, wählen Sie den Shell-Eintrag root, führen Sie mount -o remount,rw / aus und anschließend passwd. Wenn root bereits ein Passwort hat und Sie genau dieses verloren haben, fragt die Recovery-Shell danach. Als verbleibender Weg muss das Rescue-Image des Providers mit eingehängtem Datenträger und chroot verwendet werden.

Warum meldet passwd „Authentication token manipulation error“?

Diese Meldung kann zwei Ursachen haben. Häufig wurde die Eingabe an der Current password:-Abfrage falsch beantwortet. Die passwd: password unchanged-Zeile darunter bestätigt dann, dass nichts geschrieben wurde. Die andere Ursache ist ein nicht beschreibbares Dateisystem. Das tritt im Recovery-Modus auf, weil / dort schreibgeschützt eingehängt ist. Führen Sie mount -o remount,rw / aus und versuchen Sie es erneut.

Ändert das Ändern meines Linux-Passworts auch mein sudo-Passwort?

Ja. sudo hat kein eigenes Passwort. Es authentifiziert Sie über PAM anhand desselben /etc/shadow-Eintrags, den auch SSH und su verwenden. Daher gibt es pro Konto ein Passwort. Deshalb ist auch die erste sudo-Abfrage nach einer Änderung der maßgebliche Test. Führen Sie sudo -k && sudo -v aus, um diese Abfrage zu erzwingen, solange Ihre Sitzung noch funktioniert.

Werden meine SSH-Schlüssel oder meine offenen Sitzungen durch die Passwortänderung unbrauchbar?

Nein. Die Authentifizierung mit öffentlichen Schlüsseln liest /etc/shadow nie aus. Daher funktionieren die Schlüssel auch nach einer Passwortänderung, nach passwd -l und nach chage -d 0 weiterhin. Bereits geöffnete Sitzungen bleiben geöffnet, weil SSH die Zugangsdaten nur bei der Anmeldung prüft. In einer laufenden Sitzung ändert sich lediglich sudo. Dieses fragt nach dem neuen Passwort, sobald der Zeitstempel von 15 minutes abgelaufen ist.

Wie zwinge ich einen Benutzer, sein Passwort bei der nächsten Anmeldung zu ändern?

Führen Sie sudo chage -d 0 deploy oder sudo passwd -e deploy aus. Beide Befehle bewirken dasselbe. Das gespeicherte Datum der letzten Änderung wird auf die Unix-Epoche gesetzt. PAM behandelt das Passwort dadurch als abgelaufen. Bei der nächsten interaktiven Anmeldung muss der Benutzer ein neues Passwort setzen, bevor eine Shell gestartet wird. Wenden Sie dies nicht auf ein Konto an, das von Skripten über SSH verwendet wird. Ein nicht interaktiver Befehl schlägt dann mit Password change required but no TTY available. fehl und wird nicht ausgeführt.