Ubuntu: VPS-root-Passwort mit passwd ändern

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

Um das root-Passwort Ihres VPS (virtueller privater 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. Der Befehl fordert zuerst Ihr aktuelles Passwort an.

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 typischen Fehler: Prüfen, ob das neue Passwort funktioniert, bevor Sie die Sitzung verlieren, über ein Skript gesetzte Passwörter, das absichtliche Ablaufen eines Passworts und den erneuten 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 geöffnet ist. Sobald die letzte Sitzung geschlossen wird, ist dafür möglicherweise ein Konsolenzugriff 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 Anmeldedaten beim Anmelden und danach nicht erneut. Die Ausnahme ist sudo. Nach Ablauf des Zeitstempels prüft es Ihr Passwort über PAM (Pluggable Authentication Modules) erneut. Standardmäßig geschieht dies 15 Minuten nach der letzten Abfrage. Das neue Passwort wird daher erstmals wirklich getestet, wenn sudo danach fragt, nicht bei der Anmeldung.

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

Ändern Sie Ihr eigenes Passwort mit passwd

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. Jede andere Ausgabe lässt das alte Passwort unverändert.

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. Das ist im Recovery-Modus der normale Zustand. You must choose a longer password. stammt aus pam_unix in /etc/pam.d/common-password. Diese Einstellung wendet Längen- und Ähnlichkeitsprüfungen auf normale Benutzer an.

Auf den meisten VPS-Images hat das Standardkonto (ubuntu oder der von Ihrem Provider verwendete Name) überhaupt kein Passwort, sondern nur einen SSH-Schlüssel. passwd hat kein aktuelles Passwort, das geprüft werden kann, und kommt daher 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.

Das Passwort eines anderen Benutzers mit sudo passwd ändern

sudo passwd deploy

root wird nicht nach dem alten Passwort gefragt. pam_unix umgeht außerdem die für normale Benutzer geltenden Prüfungen der Passwortstärke. Daher kann root ein Passwort festlegen, das der Benutzer selbst nicht hätte festlegen können.

Das Sperren ist eine separate Aktion. sudo passwd -l deploy setzt ein ! vor den gespeicherten Hash. Dadurch passt kein Passwort mehr. sudo passwd -u deploy entfernt dieses Zeichen 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 ~/.ssh/authorized_keys funktioniert weiterhin, weil die Authentifizierung mit einem öffentlichen Schlüssel /etc/shadow nicht verwendet. Um ein Konto vollständig zu sperren, setzen Sie das Ablaufdatum des Kontos:

sudo usermod --expiredate 1 deploy

Dadurch wird das Ablaufdatum des Kontos auf ein Datum im Jahr 1970 gesetzt. sshd verweigert die Anmeldung dann unabhängig vom angebotenen Anmeldemittel. Machen Sie die Änderung 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 noch im PAM-Stack verwendet, kann ein leeres Passwort von jedem verwendet werden.

Benötigt root auf einem VPS ein Passwort?

Ubuntu wird mit gesperrtem root ausgeliefert. /etc/shadow enthält anstelle eines Hashes !, und sudo passwd -S root gibt eine Zeile aus, die mit root L beginnt. Solange Sie kein Passwort festlegen, kann sich niemand per Passwort als root anmelden. Deshalb stellt das Image stattdessen einen Benutzer mit sudo-Berechtigung bereit. Arbeiten Sie mit Benutzerkonten mit geringsten Berechtigungen auf einem VPS statt als root. Dieses Vorgehen sollten Sie beibehalten.

Ein root-Passwort bietet genau einen Vorteil: einen Zugang über die Provider-Konsole. Diese Konsole wird unterhalb des Netzwerk-Stacks an die virtuelle Maschine angeschlossen. Sie funktioniert daher weiter, wenn sshd falsch konfiguriert ist oder eine Firewall-Regel nicht stimmt. Das hat jedoch auch einen Nachteil. Das root-Shell-Menü der GRUB-Wiederherstellung fordert das root-Passwort an, wenn root ein Passwort besitzt. Das Werkzeug, mit dem Sie ein vergessenes Passwort zurücksetzen würden, ist dann durch dasselbe Passwort geschützt.

Ein root-Passwort ermöglicht root keine Anmeldung über SSH. Ubuntu wird mit PermitRootLogin prohibit-password ausgeliefert, das bedeutet: nur Schlüssel. 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.

Mit chpasswd ein Passwort aus einem Skript 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 Passwort im Klartext in Ihre Shell-Historie und in Ihre CI-Logs (Continuous Integration). Hashen Sie das Passwort zuerst:

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

openssl passwd -6 fordert das Passwort zweimal ohne Anzeige 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. Deshalb wird es unverändert in /etc/shadow übernommen. Der Hash kann sicher in einem Repository oder einer CI-Variable gespeichert werden. Das Passwort im Klartext verlässt das Gerät, auf dem Sie es eingegeben haben, nie.

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 liest. Sie können sie problemlos mischen. openssl passwd -6 verhält sich auf jeder Ubuntu-LTS-Version gleich. Das gilt für chpasswd -c YESCRYPT nicht: Das ältere shadow-Paket in 20.04 kennt diesen Methodennamen nicht.

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 festgelegt 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 zur Passwortalterung.

Der sicherste Test im 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. Ihre Sitzung bleibt dabei unverändert.

sudo -k && sudo -v

Um ein anderes Konto zu testen, führen Sie su - deploy in 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 nachweist. Ein falsches Passwort gibt su: Authentication failure aus.

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

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). bedeutet hier, dass der Server keine Passwortauthentifizierung angeboten hat. Daher kann Sie keine Passwortänderung anmelden. Permission denied, please try again. bedeutet, dass der Server sie angeboten, aber Ihre Eingabe abgelehnt hat.

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

sudo chage -d 0 deploy

-d 0 setzt das Datum der letzten Änderung auf den Epoch-Beginn. Dadurch behandelt PAM das Passwort als abgelaufen. Bei der nächsten interaktiven Anmeldung wird zuerst 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, die sich interaktiv mit einem Passwort anmelden. Ein abgelaufenes Passwort wirkt sich auch auf schlüsselbasierte Anmeldungen aus, weil sshd die PAM-Kontophase ausführt, selbst wenn ein Schlüssel zur Authentifizierung verwendet wurde. 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 nur einen Exit-Code ungleich 0.

Bedeutung der Felder für die Passwortalterung

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 Mindestanzahl an Tagen (chage -m) gibt an, wie lange der Benutzer vor der nächsten Änderung warten muss. Dadurch wird verhindert, dass jemand nach einer erzwungenen Änderung sofort wieder das alte Passwort verwendet. Die maximale Anzahl an Tagen (chage -M) gibt an, wie lange das Passwort gültig bleibt. Die Anzahl der Warntage (chage -W) gibt an, ab wann Anmeldungen eine Warnung ausgeben. Die Anzahl der Tage bis zur Inaktivierung (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 verlangt. 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. NIST empfiehlt, eine Änderung zu erzwingen, wenn Hinweise auf eine Kompromittierung vorliegen. Ein langes, einmaliges Passwort in einem Passwortmanager zusammen mit SSH auf Basis kryptografischer Schlüssel ist besser als ein Zyklus von 90 Tagen.

Was zu tun ist, wenn Sie das root-Passwort verloren haben

Wenn ein beliebiges Konto auf dem Server sudo ausführen kann, gibt es nichts wiederherzustellen: sudo passwd root setzt ein neues Passwort. Schwieriger ist der Fall, wenn überhaupt kein funktionierender Login möglich ist.

Für alle folgenden Schritte benötigen Sie die Provider-Konsole. Sie wird in den meisten Panels als VNC-Konsole (Virtual Network Computing) oder serielle Konsole aufgeführt. Sie verbindet sich mit der virtuellen Maschine unterhalb des Netzwerk-Stacks. Daher haben sshd-Einstellungen und Firewall-Regeln keinen Einfluss darauf.

1. Starten Sie den Server über das Panel neu und überwachen Sie die Konsole.
2. Rufen Sie das GRUB-Menü auf. Cloud-Images setzen normalerweise GRUB_TIMEOUT=0. Halten Sie daher bei einem BIOS-Boot Shift gedrückt. Bei einem UEFI-Boot drücken Sie wiederholt Esc, sobald der Neustart beginnt.
3. Wählen Sie Advanced options for Ubuntu, danach den Eintrag, der mit (recovery mode) endet, und anschließend root im Wiederherstellungsmenü.
4. Führen Sie zuerst mount -o remount,rw / aus. Die Wiederherstellung 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 Panel neu.

Wenn für root bereits ein Passwort festgelegt ist und Sie dieses Passwort verloren haben, fordert die Wiederherstellungs-Shell dieses Passwort an. Dieser Weg ist dann versperrt. Starten Sie stattdessen das Rescue-Image des Providers. Binden Sie anschließend die tatsächliche Festplatte ein und ändern Sie das Passwort darin.

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 die Partitionsaufteilung mit lsblk aus, anstatt /dev/vda1 von dieser Seite zu übernehmen. Die Root-Partition ist die große Partition. Bei einem UEFI-Image befindet sie sich neben einer kleinen EFI-Partition, die überhaupt kein Verzeichnis /etc enthält.

Was Sie tun können, wenn SSH Ihr Passwort nicht mehr akzeptiert

Arbeiten Sie von der Sitzung aus, die noch besteht. Wenn keine Sitzung mehr besteht, verwenden Sie die Konsole.

Permission denied, please try again. bedeutet, dass der Server die Passwortauthentifizierung angeboten und Ihre Eingabe abgelehnt hat. Die üblichen Ursachen sind aktiviertes Caps Lock 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 gesetzt. Unter Ubuntu 22.04 und höher befindet es sich meist 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 ein Passwort zu, da die Methode keyboard-interactive denselben PAM-Stack verwendet. Wenn eine Methode deaktiviert und die andere aktiviert bleibt, akzeptiert ein Server, der scheinbar nur Schlüssel zulässt, weiterhin eingegebene Passwörter.

Too many authentication failures in einer Trennungsmeldung bedeutet, dass Ihr Client mehrere Schlüssel angeboten hat, bevor er das Passwort erreichte, und der Server MaxAuthTries erreicht hat, was standardmäßig 6 ist. 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 meist, dass fail2ban, das SSH überwacht Ihre Adresse nach wiederholten Fehlern gesperrt hat. Die Standardsperrregel weist das Paket zurück, anstatt es zu verwerfen. Deshalb kommt die Ablehnung schnell zurück und es tritt kein Timeout auf. Führen Sie in der Konsole sudo fail2ban-client status sshd aus, um die gesperrten Adressen aufzulisten, und sudo fail2ban-client set sshd unbanip 203.0.113.10, um Ihre Adresse zu entsperren.

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

Ein Passwort, das über SSH funktioniert, kann von jedem Scanner im Internet ausprobiert werden. Wechseln Sie zur schlüsselbasierten Authentifizierung. Dann sind diese Rateversuche nicht mehr relevant. Erzeugen Sie ein Schlüsselpaar, installieren Sie den öffentlichen Schlüssel und bestätigen Sie die Anmeldung mit dem Schlüssel in einem zweiten Terminal, bevor Sie weitere Änderungen vornehmen. Grundlagen der SSH-Schlüsselverwaltung behandelt die Erzeugung, authorized_keys und Passphrasen.

Deaktivieren Sie anschließend die Passwortauthentifizierung. Bestätigen 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, die Sie ändern sollten. Die ersten zehn Minuten auf einem neuen VPS legt die Reihenfolge für die Einrichtung eines neuen Servers fest.

Bewahren Sie danach ein Passwort auf. Ein Server, auf dem nur die Anmeldung mit einem Schlüssel möglich ist, ist bei einer fehlerhaften sshd-Konfiguration nur über die Konsole des Providers erreichbar. Diese Konsole erfordert einen Benutzernamen und ein Passwort. Ein Konto mit einem starken, von Ihnen gespeicherten Passwort entscheidet darüber, ob die Behebung 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 festgelegt, 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 aus, führen Sie mount -o remount,rw / aus und danach passwd. Wenn für root bereits ein Passwort festgelegt ist und Sie genau dieses verloren haben, fordert die Recovery-Shell es an. Dann bleibt der Weg über das Rescue-Image des Providers, wobei Sie den Datenträger einhängen und chroot verwenden.

Warum meldet passwd „Authentication token manipulation error“?

Diese Meldung hat zwei Ursachen. Häufig wurde an der Eingabeaufforderung Current password: eine falsche Antwort eingegeben. Die darunter angezeigte Zeile passwd: password unchanged bestätigt dann, dass nichts geschrieben wurde. Die andere Ursache ist ein Dateisystem, in das nicht geschrieben werden kann. 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 besitzt 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-Eingabeaufforderung nach einer Änderung der eigentliche Test. Führen Sie sudo -k && sudo -v aus, um diese Eingabeaufforderung zu erzwingen, solange Ihre Sitzung noch funktioniert.

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

Nein. Die Public-Key-Authentifizierung liest /etc/shadow nie aus. Daher funktionieren die Schlüssel nach einer Passwortänderung, nach passwd -l und nach chage -d 0 weiterhin. Bereits geöffnete Sitzungen bleiben geöffnet, weil SSH die Anmeldedaten nur beim Login prüft. In einer laufenden Sitzung ändert sich nur sudo. Dieses fragt nach Ablauf seines Zeitstempels von 15 Minuten einmal nach dem neuen Passwort.

Wie zwinge ich einen Benutzer, sein Passwort beim nächsten Login 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 Epoche gesetzt. PAM behandelt das Passwort dann als abgelaufen. Beim nächsten interaktiven Login muss ein neues Passwort festgelegt werden, bevor eine Shell startet. 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.