Root-wachtwoord wijzigen op Ubuntu VPS

Het wijzigen van het root-wachtwoord van uw VPS op Ubuntu

Om het root-wachtwoord van uw VPS (virtual private server) op Ubuntu te wijzigen, opent u een SSH (secure shell)-sessie als een gebruiker die sudo kan uitvoeren, en voert u vervolgens sudo passwd root uit. Het systeem vraagt tweemaal om het nieuwe wachtwoord en vraagt nooit om het oude, omdat sudo reeds heeft vastgesteld wie u bent. Om in plaats daarvan uw eigen inlogwachtwoord te wijzigen, voert u passwd uit zonder argumenten; het systeem vraagt dan eerst om uw huidige wachtwoord.

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

Dit is de volledige procedure. Alles hieronder betreft de onderdelen waar het mis kan gaan: verifiëren of het nieuwe wachtwoord werkt voordat u de sessie verliest waarmee u het kunt herstellen, wachtwoorden instellen vanuit een script, een wachtwoord bewust laten verlopen en weer toegang krijgen wanneer het wachtwoord al verloren is.

Open een tweede sessie voordat u een wachtwoord wijzigt

Open nu een tweede SSH-sessie en laat deze verbonden. Bijna elke fout in deze handleiding is binnen twee minuten hersteld zolang er nog één geauthenticeerde shell actief is; zodra de laatste sessie sluit, is fysieke toegang tot de console vereist.

Een reeds geopende shell blijft werken nadat u het bijbehorende account wijzigt, vergrendelt of laat verlopen, omdat SSH de inloggegevens alleen bij het aanmelden controleert en daarna niet meer. De uitzondering is sudo. Deze controleert uw wachtwoord opnieuw via PAM (pluggable authentication modules) zodra de tijdstempel verloopt, standaard 15 minuten na de laatste prompt. Het nieuwe wachtwoord wordt dus pas echt getest de volgende keer dat sudo erom vraagt, niet bij het inloggen.

Test het nieuwe wachtwoord in de tweede sessie terwijl de eerste sessie open blijft.

Wijzig uw eigen wachtwoord met passwd

passwd

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

passwd: password updated successfully is de enige output die aangeeft dat de hash in /etc/shadow is vervangen. Elke andere melding betekent dat het oude wachtwoord behouden is gebleven.

Hier treden twee fouten op. passwd: Authentication token manipulation error, gevolgd door passwd: password unchanged, betekent dat het huidige wachtwoord dat u heeft ingevoerd onjuist was, of dat het bestandssysteem dat /etc/shadow bevat niet beschrijfbaar is; dit is de normale status in de recovery mode. You must choose a longer password. is afkomstig van pam_unix in /etc/pam.d/common-password, die lengte- en gelijkeniscontroles toepast op gewone gebruikers.

Op de meeste VPS-images heeft het standaardaccount (ubuntu, of de naam die uw provider meelevert) helemaal geen wachtwoord, enkel een SSH-sleutel. passwd heeft geen huidig wachtwoord om te controleren, waardoor het niet voorbij de eerste prompt komt. Gebruik in plaats daarvan sudo passwd $USER; dit werkt omdat het sudoers-bestand van de image toestaat dat dat account sudo uitvoert zonder wachtwoord.

Het wachtwoord van een andere gebruiker wijzigen met sudo passwd

sudo passwd deploy

Aan root wordt niet gevraagd om het oude wachtwoord, en pam_unix slaat de sterktecontroles over die voor gewone gebruikers gelden. Root kan dus een wachtwoord instellen dat de gebruiker zelf niet had kunnen kiezen.

Vergrendelen is een afzonderlijke actie. sudo passwd -l deploy plaatst een ! voor de opgeslagen hash, waardoor geen enkel wachtwoord meer overeenkomt. sudo passwd -u deploy verwijdert deze markering. Lees de status uit met sudo passwd -S deploy.

Het vergrendelen van het wachtwoord voorkomt niet dat de gebruiker inlogt. Elke sleutel in hun ~/.ssh/authorized_keys blijft werken, omdat authenticatie via public key nooit /etc/shadow leest. Om een account volledig te blokkeren, laat u het account zelf verlopen:

sudo usermod --expiredate 1 deploy

Dit stelt de verloopdatum van het account in op een datum in 1970, waardoor sshd de login weigert, ongeacht het aangeboden bewijs. Maak dit ongedaan met sudo usermod --expiredate '' deploy.

Vermijd passwd -d. Dit stelt een leeg wachtwoord in in plaats van een vergrendeld wachtwoord. Op oudere releases die nog nullok in de PAM-stack hebben staan, kan iedereen een leeg wachtwoord gebruiken.

Heeft root een wachtwoord nodig op een VPS?

Ubuntu wordt geleverd met een vergrendeld root-account. /etc/shadow bevat ! in plaats van een hash, en sudo passwd -S root toont een regel die begint met root L. Niets kan inloggen als root met een wachtwoord totdat u er een instelt; daarom krijgt u bij de image een gebruiker met sudo-rechten. Werken via gebruikersaccounts met minimale rechten op een VPS in plaats van als root is de aanbevolen werkwijze.

Het instellen van een root-wachtwoord biedt één specifiek voordeel: een toegangsweg via de console van de provider. Die console is verbonden met de virtuele machine onder de netwerkstack, waardoor deze blijft werken wanneer sshd verkeerd is geconfigureerd of een firewallregel onjuist is. Het heeft echter ook een nadeel. De root-shell in het GRUB-herstelmenu vraagt om het root-wachtwoord als root er een heeft; de tool die u zou gebruiken om een vergeten wachtwoord te herstellen, bevindt zich nu achter datzelfde wachtwoord.

Het instellen van een root-wachtwoord staat niet toe dat root inlogt via SSH. Ubuntu gebruikt standaard PermitRootLogin prohibit-password, wat betekent dat alleen sleutels worden geaccepteerd. Controleer wat uw server daadwerkelijk gebruikt:

sudo sshd -T | grep -i permitrootlogin

sshd -T toont de effectieve configuratie nadat elke Include-regel is verwerkt; dit is het enige betrouwbare antwoord zodra /etc/ssh/sshd_config.d/ drop-in-bestanden bevat.

Een wachtwoord instellen vanuit een script met chpasswd

passwd leest vanaf de terminal en kan niet worden aangestuurd vanuit een script. chpasswd leest user:password-paren via de standaardinvoer, één per regel.

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

Dat werkt, maar het plaatst een wachtwoord in platte tekst in uw shell-geschiedenis en uw CI-logs (continuous integration). Hash het wachtwoord eerst:

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

openssl passwd -6 vraagt tweemaal om het wachtwoord zonder echo en print vervolgens een SHA-512 crypt-hash die begint met $6$. -e vertelt chpasswd dat het tweede veld al gehasht is, waardoor het ongewijzigd naar /etc/shadow wordt gekopieerd. De hash is veilig om in een repository of een CI-variabele te bewaren en het wachtwoord in platte tekst verlaat nooit de machine waar u het heeft ingevoerd.

Ubuntu 24.04 hasht nieuwe wachtwoorden met yescrypt ($y$) wanneer passwd ze instelt, terwijl openssl passwd -6 SHA-512 gebruikt. Beide worden bij het inloggen geverifieerd, omdat libxcrypt beide formaten leest. Het mengen van deze methoden is geen probleem en openssl passwd -6 gedraagt zich op elke Ubuntu LTS-release hetzelfde, in tegenstelling tot chpasswd -c YESCRYPT: het oudere shadow-pakket op 20.04 herkent die methodenaam niet. Deze hashes blijven ook behouden bij een release-upgrade, dus het migreren van een 24.04-server naar 26.04 dwingt u niet om wachtwoorden van gebruikers opnieuw in te stellen.

Hoe controleert u of het wachtwoord daadwerkelijk is gewijzigd?

Begin met de metadata en verifieer dit vervolgens met een inlogpoging.

sudo passwd -S deploy

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

Het tweede veld is de status: P voor een bruikbaar wachtwoord, L voor vergrendeld, NP voor geen wachtwoord. De datum geeft aan wanneer het wachtwoord voor het laatst is gewijzigd; deze zou dus de datum van vandaag moeten tonen. De getallen daarna zijn de verouderingsvelden die hieronder worden behandeld.

De veiligste live-test is sudo zelf. sudo -k verwijdert de gecachte tijdstempel en sudo -v dwingt een nieuwe prompt af. Als het nieuwe wachtwoord daar wordt geaccepteerd, heeft PAM het geaccepteerd en is er niets aan uw sessie veranderd.

sudo -k && sudo -v

Om een ander account te testen, voert u su - deploy uit vanuit een shell zonder verhoogde rechten. Voer niet sudo su - deploy uit, omdat aan root nooit om een wachtwoord wordt gevraagd en de test dus niets bewijst. Een onjuist wachtwoord resulteert in su: Authentication failure.

De definitieve test is een nieuwe SSH-inlogpoging vanaf uw laptop, terwijl de huidige sessie nog openstaat:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). betekent hier dat de server wachtwoordauthenticatie nooit heeft aangeboden, waardoor een wachtwoordwijziging u geen toegang zal verschaffen. Permission denied, please try again. betekent dat de server dit wel aanbood, maar het ingevoerde wachtwoord heeft afgewezen.

Wachtwoordwijziging afdwingen bij de volgende aanmelding met chage

sudo chage -d 0 deploy

-d 0 stelt de datum van de laatste wijziging in op de epoch, waardoor PAM het wachtwoord als verlopen beschouwt. Bij de volgende interactieve aanmelding wordt om het huidige wachtwoord gevraagd en vervolgens om een nieuw wachtwoord, voordat de shell wordt toegewezen. sudo passwd -e deploy doet exact hetzelfde.

Gebruik dit alleen voor accounts die interactief inloggen met een wachtwoord. Een verlopen wachtwoord heeft ook invloed op aanmeldingen op basis van sleutels, omdat sshd de PAM-accountfase uitvoert, zelfs wanneer een sleutel de authenticatie heeft afgehandeld. Een gescripte ssh deploy@203.0.113.10 'systemctl restart app' mislukt hierdoor en stopt:

Password change required but no TTY available.

Alles na die regel wordt niet uitgevoerd en de taak rapporteert enkel een exitcode die niet nul is.

Wat de velden voor wachtwoordverloop betekenen

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

Deze getallen zijn veld 4 tot en met 8 van de regel van de betreffende gebruiker in /etc/shadow. Minimum aantal dagen (chage -m) is de periode die een gebruiker moet wachten voordat het wachtwoord opnieuw mag worden gewijzigd; dit voorkomt dat iemand direct terugschakelt naar het oude wachtwoord na een gedwongen wijziging. Maximum aantal dagen (chage -M) is de geldigheidsduur van het wachtwoord. Waarschuwingsdagen (chage -W) is het aantal dagen vóór verloop waarop bij het inloggen een waarschuwing wordt getoond. Inactieve dagen (chage -I) is de respijtperiode na verloop waarna het wachtwoord helemaal niet meer wordt geaccepteerd. Accountverloop (chage -E) is een harde datum en staat los van het wachtwoord.

sudo chage -M 90 -W 14 deploy

Stel dit alleen in wanneer een beleid dit vereist. Het NIST (het Amerikaanse National Institute of Standards and Technology) adviseert sinds 2017 tegen routinematige wachtwoordverloop, omdat dit gebruikers aanzet tot voorspelbare variaties op één wachtwoord. Het NIST adviseert om alleen een wijziging af te dwingen wanneer er bewijs is van een inbreuk. Een lang, uniek wachtwoord in een wachtwoordmanager, in combinatie met SSH op basis van sleutels, is effectiever dan een cyclus van 90 dagen.

Wat te doen als u het root-wachtwoord bent verloren

Als een account op de server sudo kan uitvoeren, is er niets te herstellen: sudo passwd root stelt een nieuw wachtwoord in. Het lastige scenario is wanneer er helemaal geen werkende login is.

Alles hieronder vereist de console van de provider, in de meeste panelen aangeduid als VNC (virtual network computing) of een seriële console. Deze maakt verbinding met de virtuele machine onder de netwerkstack, waardoor sshd-instellingen en firewallregels geen invloed hebben.

1. Start de server opnieuw op via het paneel en bekijk de console.
2. Open het GRUB-menu. Cloud-images hebben meestal GRUB_TIMEOUT=0 ingesteld, dus houd Shift ingedrukt bij een BIOS-boot, of druk herhaaldelijk op Esc bij een UEFI-boot zodra het opstarten begint.
3. Kies Advanced options for Ubuntu, vervolgens het item dat eindigt op (recovery mode), en daarna root in het herstelmenu.
4. Voer eerst mount -o remount,rw / uit. De herstelmodus koppelt het root-bestandssysteem als alleen-lezen; zonder dit commando mislukt passwd met passwd: Authentication token manipulation error omdat het niet naar /etc/shadow kan schrijven.
5. Voer passwd ubuntu uit voor het account dat u nodig heeft en start daarna opnieuw op via het paneel.

Als root al een wachtwoord heeft en u bent dat verloren, dan vraagt de herstel-shell erom en is deze route afgesloten. Start in dat geval de rescue-image van de provider, koppel de echte schijf en wijzig het wachtwoord daarin.

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

Lees de partitie-indeling af van lsblk in plaats van /dev/vda1 van deze pagina te kopiëren. De root-partitie is de grote partitie. Op een UEFI-image bevindt deze zich naast een kleine EFI-partitie die helemaal geen /etc-map bevat.

Wat te doen als SSH uw wachtwoord niet langer accepteert

Werk vanuit de sessie die u nog open heeft staan. Als er geen sessie meer actief is, gebruik dan de console.

Permission denied, please try again. betekent dat de server wachtwoordauthenticatie aanbood en de door u verzonden gegevens afwees. De gebruikelijke oorzaken zijn Caps Lock of een toetsenbordindeling van de console die afwijkt van de indeling die u gebruikte bij het instellen van het wachtwoord.

Permission denied (publickey). betekent dat de server wachtwoordauthenticatie nooit heeft aangeboden. PasswordAuthentication no is ergens ingesteld, en op Ubuntu 22.04 en later bevindt dit zich meestal in een drop-in bestand onder /etc/ssh/sshd_config.d/ dat het hoofdbestand overschrijft. Lees de effectieve waarden uit:

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

KbdInteractiveAuthentication yes in combinatie met PasswordAuthentication no laat nog steeds een wachtwoord toe, omdat de keyboard-interactive methode dezelfde PAM-stack gebruikt. Het uitschakelen van de een terwijl de ander aan blijft staan, is de reden waarom een server die lijkt op 'key-only' toch getypte wachtwoorden blijft accepteren.

Diezelfde regel is wat een geweigerde key-login ook weergeeft. Als u dus een key aanbood in plaats van een wachtwoord, is de wachtwoordinstelling van de server slechts een van de vijf fouten achter Permission denied (publickey), en de ssh -v-uitvoer vertelt u welke fout u heeft.

Too many authentication failures in een verbrekingsbericht betekent dat uw client meerdere keys aanbood voordat het wachtwoord werd bereikt, en de server MaxAuthTries bereikte, wat standaard op 6 staat. Forceer een enkele methode:

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

Connection refused op een poort die een minuut geleden nog werkte, betekent meestal dat fail2ban die SSH monitort uw adres heeft verbannen na herhaalde mislukte pogingen. De standaard ban-regel weigert het pakket in plaats van het te negeren (drop), wat de reden is dat de weigering snel terugkomt in plaats van in een time-out te lopen. Vanuit de console geeft sudo fail2ban-client status sshd de verbannen adressen weer en verwijdert sudo fail2ban-client set sshd unbanip 203.0.113.10 uw adres.

Wachtwoorden zijn een tussenstap, sleutels zijn het einddoel

Een wachtwoord dat werkt via SSH is een wachtwoord dat elke scanner op het internet kan raden. Stap over op authenticatie op basis van sleutels en het raden is niet langer relevant. Genereer een sleutelpaar, installeer de publieke helft en bevestig dat de sleutel u inlogt vanuit een tweede terminal voordat u iets anders wijzigt. Basisprincipes van SSH-sleutelbeheer behandelt het genereren, authorized_keys en wachtzinnen.

Schakel daarna wachtwoordauthenticatie uit en bevestig dit met sudo sshd -T in plaats van te vertrouwen op het bestand dat u heeft bewerkt. SSH beveiligen op een VPS doorloopt de overige sshd-instellingen die het wijzigen waard zijn, en de eerste tien minuten op een nieuwe VPS plaatst deze in de juiste volgorde voor een verse server.

Behoud daarna één wachtwoord. Een server die alleen sleutels accepteert met een defecte sshd-configuratie is alleen bereikbaar via de console van de provider, en die console vraagt om een gebruikersnaam en een wachtwoord. Een account met een sterk wachtwoord dat u veilig heeft opgeslagen, is het verschil tussen een reparatie van vijf minuten en een volledige herinstallatie.

FAQ

Hoe wijzig ik het root-wachtwoord op mijn VPS als ik het oude niet ken?

Log in als een gebruiker die sudo kan uitvoeren en draai sudo passwd root. Dit stelt een nieuw wachtwoord in zonder om het oude te vragen, omdat sudo u al heeft geauthenticeerd. Als geen enkel account op de server sudo kan uitvoeren, open dan de console van de provider, start opnieuw op in het GRUB-herstelmenu, kies de root-shell-optie, voer mount -o remount,rw / uit en draai daarna passwd. Als root al een wachtwoord heeft en u dat bent vergeten, zal de herstel-shell erom vragen; de enige overgebleven optie is dan de rescue-image van de provider waarbij de schijf is gemount en ge-chroot.

Waarom geeft passwd de melding "Authentication token manipulation error"?

Twee oorzaken leiden tot deze melding. De meest voorkomende is een onjuist antwoord bij de Current password:-prompt, waarbij de passwd: password unchanged-regel eronder bevestigt dat er niets is weggeschreven. De andere oorzaak is een bestandssysteem dat niet beschrijfbaar is; dit treedt op in de herstelmodus, omdat / daar alleen-lezen is gemount. Voer mount -o remount,rw / uit en probeer het opnieuw.

Wijzigt het wijzigen van mijn Linux-wachtwoord ook mijn sudo-wachtwoord?

Ja. sudo heeft geen eigen wachtwoord. Het authenticeert u via PAM tegen hetzelfde /etc/shadow-item dat SSH en su gebruiken, dus er is één wachtwoord per account. Daarom is de eerste sudo-prompt na een wijziging de echte test. Voer sudo -k && sudo -v uit om die prompt af te dwingen terwijl u nog een actieve sessie heeft.

Breekt het wijzigen van mijn wachtwoord mijn SSH-keys of open sessies?

Nee. Authenticatie via publieke sleutels leest nooit /etc/shadow, dus keys blijven werken na een wachtwoordwijziging, na passwd -l en na chage -d 0. Sessies die al open zijn, blijven open, omdat SSH alleen bij het inloggen de inloggegevens controleert. Het enige dat in een actieve sessie verandert is sudo, dat om het nieuwe wachtwoord vraagt zodra de tijdstempel van 15 minuten is verlopen.

Hoe dwing ik een gebruiker om het wachtwoord bij de volgende login te wijzigen?

Voer sudo chage -d 0 deploy uit, of sudo passwd -e deploy, wat hetzelfde doet. De opgeslagen datum van de laatste wijziging wordt verplaatst naar de epoch, PAM behandelt het wachtwoord als verlopen en bij de volgende interactieve login moet een nieuw wachtwoord worden ingesteld voordat een shell start. Doe dit niet bij een account dat door scripts via SSH wordt gebruikt: een niet-interactief commando zal dan falen met Password change required but no TTY available. en wordt niet uitgevoerd.