Ubuntu: VPS-root-Passwort ändern und Zugriff behalten

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 zweimal zur Eingabe des neuen Passworts auf. 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 wird zuerst Ihr aktuelles Passwort abgefragt.

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 beheben könnten, setzen Passwörter aus einem Skript, lassen ein Passwort absichtlich ablaufen und stellen den Zugriff wieder her, 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 diesem Leitfaden lässt sich in zwei Minuten beheben, solange noch eine authentifizierte Shell geöffnet ist. Sobald die letzte Sitzung geschlossen ist, ist dafür möglicherweise ein Konsolenzugriff erforderlich.

Eine bereits geöffnete Shell arbeitet weiter, nachdem Sie das zugehörige Konto ändern, sperren oder dessen Gültigkeit beenden. SSH prüft die Zugangsdaten bei der Anmeldung und danach nicht erneut. Eine 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 erst dann 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.

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 normale Zustand. You must choose a longer password. stammt aus pam_unix in /etc/pam.d/common-password. Diese Einstellung erzwingt Längen- und Ähnlichkeitsprüfungen für normale Benutzer.

Bei den meisten VPS-Images hat das Standardkonto (ubuntu oder der von Ihrem Anbieter 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.

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 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 seiner ~/.ssh/authorized_keys funktioniert weiterhin, weil die Public-Key-Authentifizierung /etc/shadow niemals ausliest. Um ein Konto vollständig zu deaktivieren, müssen Sie das Konto selbst ablaufen lassen:

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 verwendeten Zugangsnachweis. Machen Sie diese Änderung mit sudo usermod --expiredate '' deploy rückgängig.

Vermeiden Sie passwd -d. Damit wird ein leeres Passwort statt eines gesperrten Passworts gesetzt. In einer älteren Version, die nullok noch im PAM-Stack verwendet, ist ein leeres Passwort für jeden verwendbar.

Benötigt root auf einem VPS ein Passwort?

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

Ein root-Passwort bietet einen konkreten Vorteil: Es ermöglicht den Zugang über die Konsole des Providers. Diese Konsole ist unterhalb des Netzwerk-Stacks mit der virtuellen Maschine verbunden. Sie funktioniert daher auch dann, wenn sshd falsch konfiguriert ist oder eine Firewall-Regel nicht stimmt. Das hat jedoch einen Nachteil. Das GRUB-Recovery-Menü fordert das root-Passwort an, wenn 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, dass nur Schlüssel verwendet werden. 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 Prüfung.

Ein Passwort mit chpasswd aus einem Skript setzen

passwd liest das Passwort vom 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-History und in Ihre CI-Logs (Continuous Integration). Erstellen Sie stattdessen zuerst einen 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. Daher 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 den Rechner, auf dem Sie es eingegeben haben, nicht.

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 geprüft, weil libxcrypt beide Formate liest. Sie können die Formate problemlos mischen. openssl passwd -6 verhält sich bei 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-Wechsel gültig. Daher müssen Sie beim Upgrade eines 24.04-Servers auf 26.04 keine Passwörter zurücksetzen.

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 folgenden Zahlen sind die unten beschriebenen Felder für die 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 wurde dabei nicht verä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, da root nie nach einem Passwort gefragt wird und der Test daher nichts beweist. Ein falsches Passwort erzeugt die Ausgabe su: Authentication failure.

Der eigentliche Test ist eine neue SSH-Anmeldung von Ihrem Laptop aus, 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, aber Ihre Eingabe abgelehnt hat.

Bei der nächsten Anmeldung mit chage eine Passwortänderung 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 bereitgestellt 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 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 weiter ausgeführt. Der Job meldet lediglich einen Exit-Code ungleich 0.

Bedeutung der Felder für das Passwortalter

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 der Tage (chage -m) gibt an, wie lange der Benutzer warten muss, bevor er das Passwort erneut ändern darf. Dadurch kann er nach einer erzwungenen Änderung nicht unmittelbar wieder das alte Passwort festlegen. Die maximale Anzahl der Tage (chage -M) gibt an, wie lange das Passwort gültig bleibt. Die Anzahl der Warntage (chage -W) legt fest, ab wann bei Anmeldungen eine Warnung ausgegeben wird. Die Anzahl der inaktiven Tage (chage -I) ist der Zeitraum nach dem Ablauf, in dem das Passwort noch akzeptiert wird. Der Ablauf des Kontos (chage -E) ist ein festes Datum und unabhängig vom Passwort.

sudo chage -M 90 -W 14 deploy

Legen Sie diesen Wert nur fest, wenn eine Richtlinie dies erfordert. NIST (das US-amerikanische National Institute of Standards and Technology) rät seit 2017 von einem regelmäßigen Passwortablauf ab. Er führt dazu, dass Benutzer vorhersehbare Varianten desselben Passworts verwenden. Stattdessen empfiehlt NIST, eine Änderung zu erzwingen, wenn Hinweise auf eine Kompromittierung vorliegen. Ein langes, eindeutiges Passwort in einem Passwortmanager und SSH mit Schlüsselauthentifizierung sind sicherer als ein 90-Tage-Zyklus.

Was tun, wenn Sie das root-Passwort verloren haben

Wenn ein beliebiges Konto auf dem Server sudo ausführen kann, müssen Sie nichts wiederherstellen: sudo passwd root setzt ein neues Passwort. Der schwierige Fall liegt vor, wenn überhaupt keine funktionierende Anmeldung mehr möglich ist.

Für alle folgenden Schritte benötigen Sie die Provider-Konsole. Sie wird in den meisten Bedienfeldern als VNC-Konsole (Virtual Network Computing) oder serielle Konsole bezeichnet. Sie stellt die Verbindung zur virtuellen Maschine unterhalb des Netzwerk-Stacks her. Einstellungen von sshd und Firewall-Regeln wirken sich daher nicht auf sie aus.

1. Starten Sie den Server über das Bedienfeld neu und beobachten Sie die Konsole.
2. Öffnen Sie das GRUB-Menü. Cloud-Images setzen GRUB_TIMEOUT=0 normalerweise so, dass Sie bei einem BIOS-Boot Shift gedrückt halten müssen. Bei einem UEFI-Boot drücken Sie wiederholt Esc, 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 nur lesbar 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 root bereits ein Passwort hat und Sie genau dieses Passwort verloren haben, fordert Sie die Recovery-Shell dazu auf. Dieser Weg ist dann versperrt. Starten Sie stattdessen das Rescue-Image des Providers, binden Sie anschließend das tatsächliche Laufwerk 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 die Partitionsaufteilung mit lsblk aus, statt /dev/vda1 von dieser Seite zu übernehmen. Die Root-Partition ist die große Partition. Bei einem UEFI-Image liegt daneben eine kleine EFI-Partition, die überhaupt kein Verzeichnis /etc enthält.

Was Sie tun sollten, wenn SSH Ihr Passwort nicht mehr akzeptiert

Arbeiten Sie mit der Sitzung, die noch besteht. Wenn keine Sitzung mehr aktiv ist, verwenden Sie die Konsole.

Permission denied, please try again. bedeutet, dass der Server eine Passwortauthentifizierung angeboten und Ihre Eingabe abgelehnt hat. Häufige Ursachen sind eine aktivierte Feststelltaste oder ein Konsolentastaturlayout, das sich von dem Layout unterscheidet, das Sie beim Festlegen des Passworts verwendet haben.

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 sich die Einstellung 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, weil die interaktive Tastaturauthentifizierung denselben PAM-Stack verwendet. Wenn Sie eine der beiden Methoden deaktivieren und die andere aktiviert lassen, akzeptiert ein Server, der scheinbar nur Schlüssel zulässt, weiterhin eingegebene Passwörter.

Dieselbe Meldung wird auch bei einer abgelehnten Schlüsselanmeldung ausgegeben. Wenn Sie also einen Schlüssel und kein Passwort angeboten haben, ist die Passworteinstellung des Servers nur einer von fünf Fehlern hinter Permission denied (publickey). Die Ausgabe von ssh -v zeigt, welcher Fehler vorliegt.

Too many authentication failures in einer Trennungsmeldung bedeutet, dass Ihr Client mehrere Schlüssel angeboten hat, bevor er das Passwort erreichte. Der Server hat dabei MaxAuthTries erreicht, den Standardwert 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 meist, dass fail2ban SSH überwacht und Ihre Adresse nach wiederholten Fehlversuchen gesperrt hat. Die standardmäßige Sperrregel weist das Paket zurück, statt es zu verwerfen. Deshalb erfolgt die Ablehnung schnell und es kommt nicht zu einer Zeitüberschreitung. Führen Sie auf 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 nur ein Zwischenschritt, Schlüssel sind das Ziel

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

Deaktivieren Sie anschließend die Passwortauthentifizierung. Prüfen Sie die Einstellung mit sudo sshd -T, statt sich auf die bearbeitete Datei zu verlassen. SSH auf einem VPS absichern 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, auf dem nur die Anmeldung mit Schlüsseln erlaubt ist, kann bei einer fehlerhaften sshd-Konfiguration nur über die Konsole des Providers erreicht werden. Diese Konsole verlangt einen Benutzernamen und ein Passwort. Ein Konto mit einem starken, gespeicherten Passwort entscheidet darüber, ob die Fehlerbehebung 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 das System in das GRUB-Recovery-Menü neu, wählen Sie den root-Shell-Eintrag aus, führen Sie mount -o remount,rw / und anschließend passwd aus. Wenn root bereits ein Passwort hat und Sie genau dieses verloren haben, fragt die Recovery-Shell danach. In diesem Fall bleibt der Weg über das Rescue-Image des Providers, wobei der Datenträger eingehängt und per chroot verwendet wird.

Warum meldet passwd „Authentication token manipulation error“?

Diese Meldung kann zwei Ursachen haben. Die häufigste ist eine falsche Eingabe an der Current password:-Eingabeaufforderung. Die darunter angezeigte passwd: password unchanged-Zeile bestätigt, dass nichts geschrieben wurde. Die andere Ursache ist ein Dateisystem, auf das nicht geschrieben werden kann. Das passiert im Recovery-Modus, weil / dort schreibgeschützt eingehängt ist. Führen Sie mount -o remount,rw / aus und versuchen Sie es erneut.

Wird durch die Änderung meines Linux-Passworts auch mein sudo-Passwort geändert?

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

Werden durch die Änderung meines Passworts meine SSH-Schlüssel oder offenen Sitzungen unbrauchbar?

Nein. Bei der Public-Key-Authentifizierung wird /etc/shadow nicht gelesen. Daher funktionieren die Schlüssel auch nach einer Passwortänderung, nach passwd -l und nach chage -d 0 weiterhin. Bereits geöffnete Sitzungen bleiben aktiv, weil SSH die Zugangsdaten nur bei der Anmeldung prüft. In einer laufenden Sitzung ändert sich nur sudo. Dieses fordert das neue Passwort an, sobald der Zeitstempel von 15 Minuten abgelaufen ist.

Wie erzwinge ich, dass ein Benutzer sein Passwort bei der nächsten Anmeldung ändert?

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 Epoch-Zeit gesetzt. PAM behandelt das Passwort als abgelaufen, und bei der nächsten interaktiven Anmeldung 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.