Root-wachtwoord wijzigen op een 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 een geauthenticeerde shell actief is, terwijl het sluiten van de laatste sessie een fysieke tussenkomst bij 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 inloggen controleert en daarna niet meer. De uitzondering is sudo. Deze controleert uw wachtwoord opnieuw via PAM (pluggable authentication modules) zodra de gecachte inloggegevens verlopen, wat op Ubuntu standaard na 15 minuten gebeurt. Dit tijdsvenster wordt niet geteld vanaf de laatste prompt, omdat sudo -v de gecachte inloggegevens ververst zonder opnieuw om toestemming te vragen. Het nieuwe wachtwoord wordt dus pas echt getest de volgende keer dat sudo er daadwerkelijk om vraagt, niet bij het inloggen.

Test het nieuwe wachtwoord in de tweede sessie terwijl de eerste sessie geopend 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 overeenkomt. sudo passwd -u deploy verwijdert deze markering. Lees de status uit met sudo passwd -S deploy.

Het vergrendelen van het wachtwoord verhindert niet dat de gebruiker inlogt. Elke sleutel in hun ~/.ssh/authorized_keys blijft werken, omdat authenticatie via publieke sleutels de wachtwoordhash niet controleert. Om een account volledig te blokkeren, moet u het account zelf laten 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 legitimatiebewijs. Maak dit ongedaan met sudo usermod --expiredate '' deploy.

Vermijd passwd -d. Dit stelt een leeg wachtwoord in in plaats van een vergrendeld wachtwoord. Op een oudere release die nog nullok in de PAM-stack heeft staan, is een leeg wachtwoord een wachtwoord dat iedereen kan 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 invoer vanaf de terminal en kan niet vanuit een script worden aangestuurd. chpasswd leest user:password-paren via de standaardinvoer, één per regel.

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

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

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 op te slaan in een repository of een CI-variabele, 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 kan lezen. Het mengen van deze methoden is geen probleem en openssl passwd -6 gedraagt zich identiek op elke Ubuntu LTS-release vanaf 18.04, wat bij chpasswd -c YESCRYPT niet het geval is: het oudere shadow-pakket op 20.04 herkent die methodenaam niet. Ubuntu 16.04 vormt de uitzondering, omdat de OpenSSL 1.0.2-versie daarvan helemaal geen -6-optie heeft. Deze hashes blijven ook behouden na 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 dan met de volgende melding voordat het commando wordt uitgevoerd:

Password change required but no TTY available.

Het externe commando wordt nooit uitgevoerd en ssh eindigt met een non-zero exitcode. Tenzij het aanroepende script stopt bij fouten, met set -e of een expliciete controle, worden de regels daarna alsnog uitgevoerd en kan de taak voltooien alsof de herstart heeft plaatsgevonden.

Wat de velden voor wachtwoordveroudering 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

Die getallen zijn de velden 4 tot en met 8 van de regel van die gebruiker in /etc/shadow. Het minimumaantal dagen (chage -m) is de tijd die de gebruiker moet wachten voordat het wachtwoord opnieuw mag worden gewijzigd. Dit voorkomt dat iemand na een verplichte wijziging direct terugkeert naar het oude wachtwoord. Het maximumaantal dagen (chage -M) bepaalt hoe lang het wachtwoord geldig blijft. Het aantal waarschuwingsdagen (chage -W) bepaalt wanneer bij het aanmelden een waarschuwing wordt weergegeven. Het aantal inactieve dagen (chage -I) is de respijtperiode na het verlopen van het wachtwoord. Daarna wordt het wachtwoord helemaal niet meer geaccepteerd. Het verlopen van het account (chage -E) is een vaste datum en staat los van het wachtwoord.

sudo chage -M 90 -W 14 deploy

Stel dit alleen in wanneer een beleid dit vereist. NIST (het Amerikaanse National Institute of Standards and Technology) adviseert sinds 2017 om wachtwoorden niet routinematig te laten verlopen, omdat dit gebruikers aanzet tot voorspelbare varianten van één wachtwoord. NIST adviseert om een wijziging af te dwingen wanneer er aanwijzingen zijn dat het wachtwoord is gecompromitteerd. Een lang, uniek wachtwoord dat in een wachtwoordmanager wordt bewaard, gecombineerd met SSH op basis van sleutels, is beter 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. Als er geen sessie meer beschikbaar 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 nooit wachtwoordauthenticatie heeft aangeboden, waardoor de effectieve waarde PasswordAuthentication no is. Die no kan in het hoofdbestand of in een drop-in-bestand staan, dus controleer beide. sshd leest de bestanden onder /etc/ssh/sshd_config.d/ aan het begin van de configuratie en hanteert de eerste waarde die het voor elk trefwoord tegenkomt; een drop-in overschrijft dus /etc/ssh/sshd_config. Dezelfde regel werkt vaak andersom op Ubuntu 24.04-servers die vanaf de ISO met SSH ingeschakeld zijn geïnstalleerd: de installer laat een cloud-init drop-in achter, 50-cloud-init.conf, die PasswordAuthentication yes instelt, waardoor een no die aan het hoofdbestand is toegevoegd, wordt genegeerd. 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 uitvoert. Het uitschakelen van de een terwijl de ander aan blijft staan, is de reden waarom een server die eruitziet als key-only, toch getypte wachtwoorden blijft accepteren.

Diezelfde regel is ook wat een afgewezen key-login rapporteert. 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-output vertelt u welke fout bij u van toepassing is.

Too many authentication failures in een verbrekingsbericht betekent dat de verbinding het MaxAuthTries-quotum van de server heeft verbruikt, wat standaard 6 pogingen zijn. De gebruikelijke oorzaak is een client die meerdere keys aanbood voordat het wachtwoord werd bereikt. 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, 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 sudo fail2ban-client set sshd unbanip 203.0.113.10 verwijdert uw adres uit de lijst.

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 weet?

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 vervolgens passwd. Als root al een wachtwoord heeft en u bent dat verloren, dan vraagt de herstel-shell erom. De enige overgebleven optie is dan de rescue-image van de provider, waarbij de schijf wordt 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 (read-only) 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. Dat is ook de reden waarom de eerste sudo-prompt na een wijziging de echte test is. 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?

Een wachtwoordwijziging of passwd -l doet dat niet. Authenticatie via publieke sleutels controleert de wachtwoord-hash niet, dus keys blijven na beide acties werken. chage -d 0 is anders: sshd voert na een login met een key nog steeds de PAM-accountcontroles uit. Deze lezen de verloopvelden in /etc/shadow; een verlopen wachtwoord zorgt er dus voor dat een login met een key om een nieuw wachtwoord vraagt en dat gescripte SSH-commando's falen. 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 de volgende interactieve login moet een nieuw wachtwoord instellen voordat een shell start. Doe dit niet bij een account dat door scripts via SSH wordt gebruikt: een niet-interactief commando faalt dan met Password change required but no TTY available. en wordt nooit uitgevoerd.