Root-wachtwoord van uw Ubuntu VPS wijzigen

Het root-wachtwoord van uw VPS op Ubuntu wijzigen

Als u het root-wachtwoord van uw VPS (virtual private server) op Ubuntu wilt wijzigen, opent u een SSH-sessie (secure shell) als gebruiker die sudo kan uitvoeren. Voer daarna sudo passwd root uit. U wordt tweemaal om het nieuwe wachtwoord gevraagd. Het oude wachtwoord wordt niet gevraagd, omdat sudo al heeft vastgesteld wie u bent. Als u in plaats daarvan uw eigen aanmeldingswachtwoord wilt wijzigen, voert u passwd zonder argumenten uit. Eerst wordt dan om uw huidige wachtwoord gevraagd.

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

Dat is de volledige bewerking. Hieronder worden de situaties behandeld waarin het misgaat: controleren of het nieuwe wachtwoord werkt voordat u de sessie verliest waarmee u het probleem kunt oplossen, wachtwoorden vanuit een script instellen, een wachtwoord opzettelijk laten verlopen en opnieuw 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 opgelost zolang er nog één geauthenticeerde shell actief is. Zodra de laatste shell wordt gesloten, is mogelijk een bezoek aan de console nodig.

Een shell die al geopend is, blijft werken nadat u het account waaraan deze is gekoppeld wijzigt, vergrendelt of laat verlopen. SSH controleert de referenties namelijk bij het aanmelden en controleert ze daarna niet opnieuw. De uitzondering is sudo. Dit controleert uw wachtwoord opnieuw via PAM (pluggable authentication modules) nadat de tijdstempel is verlopen. Standaard gebeurt dit 15 minuten na de laatste prompt. Het nieuwe wachtwoord wordt dus voor het eerst echt getest wanneer sudo erom vraagt, niet bij het aanmelden.

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 uitvoer die betekent dat de hash in /etc/shadow is vervangen. Bij elke andere uitvoer bleef het oude wachtwoord behouden.

Hier treden twee fouten op. passwd: Authentication token manipulation error, gevolgd door passwd: password unchanged, betekent dat het huidige wachtwoord dat u hebt ingevoerd onjuist was of dat er niet naar het bestandssysteem met /etc/shadow kan worden geschreven. Dat is de normale toestand in de herstelmodus. You must choose a longer password. is afkomstig van pam_unix in /etc/pam.d/common-password. Dit voert lengte- en gelijkeniscontroles uit voor gewone gebruikers.

Op de meeste VPS-images heeft het standaardaccount (ubuntu of de naam die uw provider gebruikt) helemaal geen wachtwoord, maar alleen een SSH-sleutel. passwd heeft geen huidig wachtwoord om te controleren en komt daarom niet voorbij de eerste prompt. Gebruik in plaats daarvan sudo passwd $USER. Dit werkt omdat het sudoers-drop-inbestand van de image dat account toestaat om sudo zonder wachtwoord uit te voeren.

Het wachtwoord van een andere gebruiker wijzigen met sudo passwd

sudo passwd deploy

Er wordt niet om het oude wachtwoord van root gevraagd. Bovendien omzeilt pam_unix de sterktecontroles die voor gewone gebruikers gelden. Root kan daardoor een wachtwoord instellen dat de gebruiker niet zelf had kunnen instellen.

Het vergrendelen van het wachtwoord is een afzonderlijke actie. sudo passwd -l deploy plaatst een ! vóór de opgeslagen hash, zodat geen enkel wachtwoord ermee overeenkomt. Met sudo passwd -u deploy verwijdert u dit teken. Lees de status opnieuw uit met sudo passwd -S deploy.

Het vergrendelen van het wachtwoord voorkomt niet dat die gebruiker zich aanmeldt. Elke sleutel in ~/.ssh/authorized_keys blijft werken, omdat verificatie met een publieke sleutel /etc/shadow nooit leest. Als u een account volledig wilt uitschakelen, laat u het account zelf verlopen:

sudo usermod --expiredate 1 deploy

Hiermee wordt de vervaldatum van het account ingesteld op een datum in 1970. sshd weigert de aanmelding dan, ongeacht welke referentie wordt aangeboden. Maak dit ongedaan met sudo usermod --expiredate '' deploy.

Gebruik passwd -d niet. Hiermee wordt een leeg wachtwoord ingesteld in plaats van een vergrendeld wachtwoord. In een oudere release waarin nullok nog in de PAM-stack staat, kan iedereen een leeg wachtwoord gebruiken.

Heeft root een wachtwoord nodig op een VPS?

Ubuntu wordt geleverd met root vergrendeld. /etc/shadow bevat ! in plaats van een hash, en sudo passwd -S root geeft een regel weer die begint met root L. Er kan pas met een wachtwoord als root worden ingelogd nadat u er een hebt ingesteld. Daarom levert de image in plaats daarvan een gebruiker met sudo-rechten. Gebruik bij voorkeur gebruikersaccounts met minimale rechten op een VPS in plaats van root.

Een root-wachtwoord instellen biedt één specifiek voordeel: toegang via de console van de provider. Deze console maakt rechtstreeks verbinding met de virtuele machine, onder de netwerkstack. Daardoor blijft de console werken wanneer sshd verkeerd is geconfigureerd of een firewallregel onjuist is. Er is ook een nadeel. De root-shell in het herstelmenu van GRUB vraagt om het root-wachtwoord wanneer root een wachtwoord heeft. Het hulpmiddel waarmee u een vergeten wachtwoord zou herstellen, is dan juist achter datzelfde wachtwoord vergrendeld.

Een root-wachtwoord instellen staat root niet toe om via SSH in te loggen. Ubuntu wordt geleverd met PermitRootLogin prohibit-password, wat betekent dat alleen sleutels zijn toegestaan. Controleer wat uw server daadwerkelijk gebruikt:

sudo sshd -T | grep -i permitrootlogin

sshd -T geeft de effectieve configuratie weer nadat elke regel van Include is verwerkt. Dit is dus het enige betrouwbare antwoord wanneer /etc/ssh/sshd_config.d/ drop-inbestanden bevat.

Een wachtwoord instellen vanuit een script met chpasswd

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

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

Dit werkt, maar hierdoor komt er een wachtwoord in leesbare tekst in uw shellgeschiedenis en in uw CI- (continuous integration-)logboeken te staan. 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 invoer weer te geven en geeft daarna een SHA-512 crypt-hash terug die begint met $6$. -e geeft chpasswd aan dat het tweede veld al is gehasht, zodat het ongewijzigd naar /etc/shadow wordt gekopieerd. De hash kan veilig in een repository of als CI-variabele worden opgeslagen. Het wachtwoord in leesbare tekst verlaat de machine waarop u het hebt ingevoerd nooit.

Ubuntu 24.04 hasht nieuwe wachtwoorden met yescrypt ($y$) wanneer passwd deze instelt, terwijl openssl passwd -6 SHA-512 gebruikt. Beide indelingen worden bij het inloggen gecontroleerd, omdat libxcrypt beide indelingen kan lezen. U kunt ze zonder problemen combineren. openssl passwd -6 werkt op elke Ubuntu LTS-release op dezelfde manier. Dat geldt niet voor chpasswd -c YESCRYPT: het oudere shadow-pakket in 20.04 kent die methodenaam niet.

Hoe controleert u of het wachtwoord daadwerkelijk is gewijzigd?

Begin met de metagegevens en bevestig dit daarna met een aanmelding.

sudo passwd -S deploy

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

Het tweede veld geeft de status aan: P voor een bruikbaar wachtwoord, L voor een vergrendeld wachtwoord en NP wanneer er helemaal geen wachtwoord is. De datum geeft aan wanneer het wachtwoord voor het laatst is gewijzigd. Deze moet de datum van vandaag bevatten. De daaropvolgende getallen zijn de instellingen voor wachtwoordveroudering die hieronder worden beschreven.

De veiligste test op het actieve systeem is sudo zelf. sudo -k verwijdert de opgeslagen tijdstempel en sudo -v zorgt ervoor dat opnieuw om invoer wordt gevraagd. Als het nieuwe wachtwoord daar wordt geaccepteerd, heeft PAM het geaccepteerd en is er niets aan uw sessie gewijzigd.

sudo -k && sudo -v

Als u een ander account wilt testen, voert u su - deploy uit vanuit een shell zonder verhoogde rechten. Voer sudo su - deploy niet uit, omdat root nooit om een wachtwoord wordt gevraagd en de test dan niets bewijst. Bij een onjuist wachtwoord wordt su: Authentication failure weergegeven.

De daadwerkelijke test is een nieuwe SSH-aanmelding vanaf uw laptop, terwijl de werkende sessie nog open is:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). betekent hier dat de server geen wachtwoordauthenticatie heeft aangeboden. Met geen enkele wachtwoordwijziging krijgt u dan toegang. Permission denied, please try again. betekent dat de server dit wel heeft aangeboden, maar de ingevoerde gegevens heeft afgewezen.

Een wachtwoordwijziging bij de volgende aanmelding afdwingen met chage

sudo chage -d 0 deploy

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

Gebruik dit alleen voor accounts waarmee gebruikers zich interactief met een wachtwoord aanmelden. Een verlopen wachtwoord heeft ook gevolgen voor aanmeldingen met een sleutel, omdat sshd de PAM-accountfase uitvoert, zelfs wanneer een sleutel de authenticatie heeft uitgevoerd. Een gescript ssh deploy@203.0.113.10 'systemctl restart app' mislukt dan met deze melding en stopt:

Password change required but no TTY available.

Niets na die regel wordt uitgevoerd. De taak rapporteert alleen een afsluitcode die niet gelijk is aan 0.

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

Deze getallen zijn de velden 4 tot en met 8 van de regel van die gebruiker in /etc/shadow. Het minimumaantal dagen (chage -m) bepaalt hoelang de gebruiker moet wachten voordat het wachtwoord opnieuw kan worden gewijzigd. Hiermee voorkomt u dat iemand na een verplichte wijziging direct terugkeert naar het oude wachtwoord. Het maximumaantal dagen (chage -M) bepaalt hoelang 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 als een beleid dit vereist. NIST (het Amerikaanse National Institute of Standards and Technology) raadt sinds 2017 routinematig verlopen van wachtwoorden af. Dit zet mensen ertoe aan voorspelbare variaties op één wachtwoord te gebruiken. NIST adviseert 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 cryptografische sleutels, is beter dan een cyclus van 90 dagen.

Wat u moet doen als u het root-wachtwoord bent kwijtgeraakt

Als een account op de server sudo kan uitvoeren, hoeft u niets te herstellen: met sudo passwd root stelt u een nieuw wachtwoord in. Het moeilijke geval is wanneer geen enkele login meer werkt.

Voor alles hieronder hebt u de console van de provider nodig. In de meeste configuraties wordt deze aangeduid als een VNC-console (virtual network computing) of seriële console. Deze maakt rechtstreeks verbinding met de virtuele machine onder de netwerkstack. De instellingen van sshd en firewallregels hebben hierop geen invloed.

1. Start de server opnieuw vanuit het configuratiescherm en controleer de console.
2. Open het GRUB-menu. Cloudimages stellen meestal GRUB_TIMEOUT=0 in. Houd daarom Shift ingedrukt bij een BIOS-opstart of druk bij een UEFI-opstart herhaaldelijk op Esc zodra het opnieuw opstarten begint.
3. Kies Advanced options for Ubuntu, vervolgens de optie die eindigt op (recovery mode), en daarna root in het herstelmenu.
4. Voer eerst mount -o remount,rw / uit. In de herstelmodus wordt het root-bestandssysteem alleen-lezen gekoppeld. Zonder deze stap mislukt passwd met passwd: Authentication token manipulation error, omdat /etc/shadow niet kan worden beschreven.
5. Voer passwd ubuntu uit voor het benodigde account en start de server vervolgens opnieuw vanuit het configuratiescherm.

Als root al een wachtwoord heeft en u juist dat wachtwoord bent kwijtgeraakt, vraagt de herstel-shell erom en kunt u deze procedure niet voortzetten. Start in plaats daarvan de rescue-image van de provider op. Koppel vervolgens 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 uit met lsblk in plaats van /dev/vda1 van deze pagina over te nemen. De root-partitie is de grootste partitie. Op een UEFI-image staat deze naast een kleine EFI-partitie, die helemaal geen map /etc bevat.

Wat u moet doen wanneer SSH uw wachtwoord niet meer accepteert

Werk vanuit de sessie die u nog hebt. Gebruik de console als er geen sessie meer beschikbaar is.

Permission denied, please try again. betekent dat de server wachtwoordauthenticatie aanbood, maar uw invoer afwees. De gebruikelijke oorzaken zijn Caps Lock of een toetsenbordindeling in de console die afwijkt van de indeling die u gebruikte toen u het wachtwoord instelde.

Permission denied (publickey). betekent dat de server nooit wachtwoordauthenticatie aanbood. PasswordAuthentication no is ergens ingesteld. Op Ubuntu 22.04 en later staat deze instelling meestal in een drop-inbestand onder /etc/ssh/sshd_config.d/, dat het hoofdbestand overschrijft. Lees de effectieve waarden:

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

KbdInteractiveAuthentication yes naast PasswordAuthentication no laat nog steeds een wachtwoord toe, omdat de methode voor interactieve toetsenbordinvoer dezelfde PAM-stack gebruikt. Als u de ene methode uitschakelt en de andere ingeschakeld laat, blijft een server die alleen sleutelauthenticatie lijkt te gebruiken, getypte wachtwoorden accepteren.

Too many authentication failures in een bericht over het verbreken van de verbinding betekent dat uw client meerdere sleutels heeft aangeboden voordat deze het wachtwoord bereikte. De server heeft daarbij MaxAuthTries bereikt, standaard 6. Forceer één 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 SSH bewaakt uw adres heeft geblokkeerd na herhaalde mislukte pogingen. De standaardblokkeringsregel weigert het pakket in plaats van het stil te laten vallen. Daarom komt de weigering snel terug en treedt er geen time-out op. Voer vanaf de console sudo fail2ban-client status sshd uit om de geblokkeerde adressen weer te geven en sudo fail2ban-client set sshd unbanip 203.0.113.10 om uw adres vrij te geven.

Wachtwoorden zijn een tussenstap, sleutels zijn de eindtoestand

Een wachtwoord dat via SSH werkt, kan door elke scanner op internet worden geraden. Stap over op authenticatie met sleutels. Genereer een sleutelpaar, installeer de publieke sleutel en controleer vanuit een tweede terminal of de sleutel u aanmeldt voordat u iets anders wijzigt. Basisprincipes van SSH-sleutelbeheer behandelt het genereren, authorized_keys en wachtzinnen.

Schakel daarna wachtwoordauthenticatie uit. Controleer dit met sudo sshd -T en vertrouw niet alleen op het bestand dat u hebt bewerkt. SSH op een VPS beveiligen behandelt de overige sshd-instellingen die u kunt wijzigen. De eerste tien minuten op een nieuwe VPS zet deze instellingen in de volgorde waarin u ze op een nieuwe server uitvoert.

Bewaar daarna één wachtwoord. Een server waarop alleen authenticatie met sleutels is toegestaan en waarvan de sshd-configuratie defect is, is alleen bereikbaar via de console van de provider. Die console vraagt om een gebruikersnaam en een wachtwoord. Een account met een sterk opgeslagen wachtwoord maakt het verschil tussen een oplossing die vijf minuten duurt en een herinstallatie.

FAQ

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

Meld u aan als een gebruiker die sudo kan uitvoeren en voer sudo passwd root uit. Hiermee stelt u een nieuw wachtwoord in zonder naar het oude te vragen, omdat sudo u al heeft geauthenticeerd. Als geen enkel account op de server sudo kan uitvoeren, opent u de console van de provider, start u opnieuw op naar het GRUB-herstelmenu, kiest u de root-shelloptie, voert u mount -o remount,rw / uit en voert u daarna passwd uit. Als root al een wachtwoord heeft en u juist dat wachtwoord bent kwijtgeraakt, vraagt de herstelshell erom. De resterende optie is de rescue-image van de provider, waarbij de schijf is aangekoppeld en met chroot de hoofdmap is gewijzigd.

Waarom meldt passwd "Authentication token manipulation error"?

Twee oorzaken kunnen deze melding veroorzaken. De meest voorkomende oorzaak is een onjuist antwoord bij de prompt Current password:. De regel passwd: password unchanged eronder bevestigt dat er niets is opgeslagen. De andere oorzaak is een bestandssysteem waarop niet kan worden geschreven. Dat gebeurt in de herstelmodus, omdat / daar alleen-lezen is aangekoppeld. 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 dezelfde vermelding in /etc/shadow die SSH en su gebruiken. Daarom heeft elk account één wachtwoord. Daarom is de eerste prompt van sudo na een wijziging ook de daadwerkelijke test. Voer sudo -k && sudo -v uit om die prompt af te dwingen zolang u nog een werkende sessie hebt.

Verbreekt het wijzigen van mijn wachtwoord mijn SSH-sleutels of mijn open sessies?

Nee. Authenticatie met een publieke sleutel leest /etc/shadow nooit uit. Sleutels blijven daarom werken na een wachtwoordwijziging, na passwd -l en na chage -d 0. Sessies die al open zijn, blijven open, omdat SSH de referenties alleen bij het aanmelden controleert. Het enige dat binnen een actieve sessie verandert, is sudo. Dit vraagt eenmaal om het nieuwe wachtwoord zodra de tijdstempel van 15 minuten is verlopen.

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

Voer sudo chage -d 0 deploy of sudo passwd -e deploy uit. Beide doen hetzelfde. De opgeslagen datum van de laatste wijziging wordt op het epoch ingesteld. PAM behandelt het wachtwoord dan als verlopen. Bij de volgende interactieve aanmelding moet de gebruiker een nieuw wachtwoord instellen voordat een shell wordt gestart. Doe dit niet voor een account dat scripts via SSH gebruikt. Een niet-interactieve opdracht mislukt dan met Password change required but no TTY available. en wordt nooit uitgevoerd.