Changer le mot de passe root d’un VPS Ubuntu

Comment changer le mot de passe root de votre VPS sur Ubuntu

Pour changer le mot de passe root de votre VPS (serveur privé virtuel) sur Ubuntu, ouvrez une session SSH (Secure Shell) avec un utilisateur autorisé à exécuter sudo, puis exécutez sudo passwd root. La commande demande deux fois le nouveau mot de passe et ne demande jamais l’ancien, car sudo a déjà vérifié votre identité. Pour changer uniquement votre propre mot de passe de connexion, exécutez passwd sans argument. La commande demande alors d’abord votre mot de passe actuel.

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

L’opération se limite à cela. La suite traite des problèmes qui surviennent ensuite : vérifier que le nouveau mot de passe fonctionne avant de perdre la session qui permettrait de corriger le problème, définir des mots de passe dans un script, en faire expirer un volontairement et récupérer l’accès lorsque le mot de passe est déjà perdu.

Ouvrez une deuxième session avant de modifier un mot de passe

Ouvrez maintenant une deuxième session SSH et laissez-la connectée. Presque tous les problèmes de ce guide se corrigent en deux minutes lorsqu’un shell authentifié reste ouvert, mais nécessitent un accès à la console dès que la dernière session est fermée.

Un shell déjà ouvert continue de fonctionner après la modification, le verrouillage ou l’expiration du compte auquel il appartient, car SSH vérifie les identifiants lors de la connexion et ne les vérifie pas à nouveau. L’exception est sudo. Il vérifie à nouveau votre mot de passe via PAM (modules d’authentification enfichables) lorsque son horodatage expire, par défaut 15 minutes après la dernière invite. Le nouveau mot de passe est donc réellement testé la prochaine fois que sudo le demande, et non lors de la connexion.

Testez le nouveau mot de passe dans la deuxième session, tout en laissant la première ouverte.

Modifiez votre propre mot de passe avec passwd

passwd

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

passwd: password updated successfully est le seul résultat indiquant que le hash dans /etc/shadow a été remplacé. Tout autre résultat signifie que l’ancien mot de passe est toujours en place.

Deux échecs se produisent ici. passwd: Authentication token manipulation error, suivi de passwd: password unchanged, signifie que le mot de passe actuel saisi est incorrect ou que le système de fichiers contenant /etc/shadow ne peut pas être modifié, ce qui est l’état normal en mode de récupération. You must choose a longer password. vient de pam_unix dans /etc/pam.d/common-password, qui applique aux utilisateurs ordinaires des contrôles de longueur et de similarité.

Sur la plupart des images VPS, le compte par défaut (ubuntu, ou le nom utilisé par votre fournisseur) n’a aucun mot de passe, mais uniquement une clé SSH. passwd n’a aucun mot de passe actuel à vérifier et ne peut donc pas dépasser la première invite. Utilisez plutôt sudo passwd $USER, qui fonctionne parce que le fichier drop-in sudoers de l’image autorise ce compte à exécuter sudo sans mot de passe.

Modifier le mot de passe d’un autre utilisateur avec sudo passwd

sudo passwd deploy

root n’a pas besoin de saisir l’ancien mot de passe, et pam_unix ignore les contrôles de robustesse appliqués aux utilisateurs ordinaires. root peut donc définir un mot de passe que l’utilisateur n’aurait pas pu définir lui-même.

Le verrouillage est une action distincte. sudo passwd -l deploy ajoute un ! devant le hash enregistré. Aucun mot de passe ne peut alors correspondre. sudo passwd -u deploy le supprime. Vérifiez ensuite l’état avec sudo passwd -S deploy.

Le verrouillage du mot de passe n’empêche pas l’utilisateur de se connecter. Toutes les clés présentes dans son ~/.ssh/authorized_keys restent utilisables, car l’authentification par clé publique ne lit jamais /etc/shadow. Pour bloquer complètement un compte, faites expirer le compte lui-même :

sudo usermod --expiredate 1 deploy

Cette commande définit l’expiration du compte à une date de 1970. sshd refuse alors la connexion, quelle que soit l’identification fournie. Annulez cette modification avec sudo usermod --expiredate '' deploy.

Évitez passwd -d. Cette commande définit un mot de passe vide au lieu de verrouiller le compte. Sur une ancienne release qui contient encore nullok dans la pile PAM, un mot de passe vide peut être utilisé par n’importe qui.

Un compte root doit-il avoir un mot de passe sur un VPS ?

Ubuntu est fourni avec le compte root verrouillé. /etc/shadow contient ! à la place d’un hash, et sudo passwd -S root affiche une ligne commençant par root L. Tant que vous n’avez pas défini de mot de passe, aucune connexion root par mot de passe n’est possible. C’est pourquoi l’image vous fournit à la place un utilisateur autorisé à utiliser sudo. Il faut conserver le principe des comptes utilisateur avec privilèges minimaux sur un VPS, plutôt que de travailler en root.

Définir un mot de passe root apporte une seule chose précise : un accès via la console du fournisseur. Cette console se connecte à la machine virtuelle sous la pile réseau. Elle continue donc de fonctionner si sshd est mal configuré ou si une règle de pare-feu est incorrecte. Cela a aussi un coût. Le shell root du menu de récupération GRUB demande le mot de passe root lorsque le compte root en possède un. L’outil que vous utiliseriez pour réinitialiser un mot de passe oublié se retrouve alors protégé par ce même mot de passe.

Définir un mot de passe root n’autorise pas les connexions root via SSH. Ubuntu est fourni avec PermitRootLogin prohibit-password, ce qui signifie que seules les clés sont acceptées. Vérifiez ce que votre serveur utilise réellement :

sudo sshd -T | grep -i permitrootlogin

sshd -T affiche la configuration effective après résolution de chaque ligne Include. C’est donc la seule réponse fiable lorsque /etc/ssh/sshd_config.d/ contient des fichiers drop-in.

Définir un mot de passe depuis un script avec chpasswd

passwd lit les entrées depuis le terminal et ne peut pas être piloté depuis un script. chpasswd lit des paires user:password depuis l’entrée standard, une par ligne.

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

Cette méthode fonctionne, mais elle écrit un mot de passe en clair dans l’historique du shell et dans les journaux de votre CI (intégration continue). Hachez-le d’abord :

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

openssl passwd -6 demande deux fois le mot de passe sans l’afficher, puis écrit un hash crypt SHA-512 commençant par $6$. -e indique à chpasswd que le deuxième champ est déjà haché ; celui-ci est donc copié tel quel dans /etc/shadow. Le hash peut être conservé sans risque dans un dépôt ou une variable de CI. Le mot de passe en clair ne quitte jamais la machine sur laquelle vous l’avez saisi.

Ubuntu 24.04 hache les nouveaux mots de passe avec yescrypt ($y$) lorsque passwd les définit, tandis que openssl passwd -6 utilise SHA-512. Les deux formats sont vérifiés lors de la connexion, car libxcrypt sait les lire tous les deux. Vous pouvez les mélanger. openssl passwd -6 se comporte de la même manière avec toutes les versions Ubuntu LTS, contrairement à chpasswd -c YESCRYPT : l’ancien paquet shadow de 20.04 ne connaît pas ce nom de méthode. Ces hash restent valides après une mise à niveau vers une nouvelle version. Ainsi, mettre à niveau un serveur 24.04 vers 26.04 ne vous oblige pas à réinitialiser les mots de passe des utilisateurs.

Comment vérifier que le mot de passe a bien été modifié ?

Commencez par les métadonnées, puis vérifiez avec une connexion.

sudo passwd -S deploy

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

Le deuxième champ indique l’état : P pour un mot de passe utilisable, L pour un mot de passe verrouillé et NP pour l’absence totale de mot de passe. La date correspond à la dernière modification du mot de passe. Elle doit donc être celle d’aujourd’hui. Les nombres qui suivent sont les paramètres d’expiration décrits plus bas.

Le test direct le plus sûr consiste à utiliser sudo. sudo -k ignore l’horodatage mis en cache et sudo -v force une nouvelle invite. Si le nouveau mot de passe est accepté, PAM l’a validé et rien n’a changé dans votre session.

sudo -k && sudo -v

Pour tester un autre compte, exécutez su - deploy depuis un shell sans privilèges. N’exécutez pas sudo su - deploy, car root n’a jamais à saisir de mot de passe et le test ne prouve rien. Un mot de passe incorrect affiche su: Authentication failure.

Le vrai test consiste à ouvrir une nouvelle connexion SSH depuis votre ordinateur portable, tout en gardant la session active ouverte :

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). signifie ici que le serveur n’a jamais proposé l’authentification par mot de passe. Aucun changement de mot de passe ne vous permettra donc de vous connecter. Permission denied, please try again. signifie qu’il l’a bien proposée, mais qu’il a rejeté la valeur saisie.

Forcer le changement de mot de passe à la prochaine connexion avec chage

sudo chage -d 0 deploy

-d 0 définit la date du dernier changement sur l’epoch, afin que PAM considère le mot de passe comme expiré. À la prochaine connexion interactive, le système demande le mot de passe actuel, puis le nouveau, avant d’ouvrir un shell. sudo passwd -e deploy fait exactement la même chose.

Utilisez cette méthode uniquement pour les comptes qui se connectent de manière interactive avec un mot de passe. Un mot de passe expiré affecte également les connexions par clé, car sshd exécute l’étape account de PAM même lorsqu’une clé a servi à l’authentification. Un script ssh deploy@203.0.113.10 'systemctl restart app' échoue alors avec ce message et s’arrête :

Password change required but no TTY available.

Aucune instruction située après cette ligne ne s’exécute, et le job signale uniquement un code de sortie différent de zéro.

Signification des champs d’expiration du mot de passe

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

Ces nombres correspondent aux champs 4 à 8 de la ligne de cet utilisateur dans /etc/shadow. Le nombre minimal de jours (chage -m) indique le délai que l’utilisateur doit attendre avant de pouvoir modifier à nouveau son mot de passe. Cela empêche de reprendre immédiatement l’ancien mot de passe après une modification forcée. Le nombre maximal de jours (chage -M) indique pendant combien de temps le mot de passe reste valide. Le nombre de jours d’avertissement (chage -W) indique à partir de quand les connexions affichent un avertissement. Le nombre de jours d’inactivité (chage -I) correspond à la période de grâce après l’expiration. Une fois cette période écoulée, le mot de passe n’est plus accepté. L’expiration du compte (chage -E) correspond à une date fixe et ne dépend pas du mot de passe.

sudo chage -M 90 -W 14 deploy

Définissez ce champ uniquement si une règle de sécurité l’exige. Depuis 2017, le NIST (National Institute of Standards and Technology des États-Unis) déconseille l’expiration systématique des mots de passe. Cette pratique pousse les utilisateurs à créer des variantes prévisibles d’un même mot de passe. Le NIST recommande plutôt de forcer une modification lorsqu’il existe des signes de compromission. Un mot de passe long et unique conservé dans un gestionnaire de mots de passe, associé à l’authentification SSH par clé, est plus efficace qu’un renouvellement tous les 90 jours.

Que faire lorsque vous avez perdu le mot de passe root

Si un compte sur la machine peut exécuter sudo, il n’y a rien à récupérer : sudo passwd root en définit un nouveau. Le cas difficile est celui où aucun accès ne fonctionne.

Tout ce qui suit nécessite la console du fournisseur, généralement indiquée dans les panneaux comme une console VNC (virtual network computing) ou série. Elle se connecte à la machine virtuelle sous la couche réseau. Les paramètres de sshd et les règles du pare-feu ne l’affectent donc pas.

1. Redémarrez le serveur depuis le panneau et surveillez la console.
2. Affichez le menu GRUB. Les images cloud définissent généralement GRUB_TIMEOUT=0. Maintenez donc Shift lors d’un démarrage BIOS, ou appuyez plusieurs fois sur Esc lors d’un démarrage UEFI, dès que le redémarrage commence.
3. Sélectionnez Advanced options for Ubuntu, puis l’entrée se terminant par (recovery mode), puis root dans le menu de récupération.
4. Exécutez d’abord mount -o remount,rw /. La récupération monte le système de fichiers root en lecture seule. Sans cette commande, passwd échoue avec passwd: Authentication token manipulation error, car elle ne peut pas écrire dans /etc/shadow.
5. Exécutez passwd ubuntu pour le compte concerné, puis redémarrez depuis le panneau.

Si root possède déjà un mot de passe et que c’est celui que vous avez perdu, ce shell de récupération vous le demande et cette méthode ne fonctionne pas. Démarrez plutôt l’image de secours du fournisseur, montez ensuite le disque réel et modifiez le mot de passe depuis ce système.

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

Consultez la disposition des partitions avec lsblk au lieu de recopier /dev/vda1 depuis cette page. La partition root est la plus grande. Sur une image UEFI, elle se trouve à côté d’une petite partition EFI qui ne contient aucun répertoire /etc.

Que faire lorsque SSH n’accepte plus votre mot de passe

Travaillez depuis la session que vous avez encore ouverte. Si aucune session ne reste ouverte, utilisez la console.

Permission denied, please try again. signifie que le serveur a proposé l’authentification par mot de passe, puis a rejeté ce que vous avez envoyé. Les causes habituelles sont la touche Verr. Maj. activée ou une disposition de clavier différente sur la console de celle utilisée lors de la définition du mot de passe.

Permission denied (publickey). signifie que le serveur n’a jamais proposé l’authentification par mot de passe. PasswordAuthentication no est défini quelque part. Sur Ubuntu 22.04 et les versions ultérieures, il se trouve généralement dans un fichier drop-in sous /etc/ssh/sshd_config.d/, qui surcharge le fichier principal. Consultez les valeurs effectives :

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

KbdInteractiveAuthentication yes associé à PasswordAuthentication no permet encore l’utilisation d’un mot de passe, car la méthode keyboard-interactive utilise la même pile PAM. Désactiver l’une tout en laissant l’autre activée explique qu’un serveur qui semble limité aux clés continue d’accepter les mots de passe saisis.

Cette même ligne s’affiche aussi lorsqu’une connexion avec une clé est rejetée. Si vous proposiez une clé plutôt qu’un mot de passe, le réglage des mots de passe du serveur ne constitue donc qu’un des cinq problèmes à l’origine de Permission denied (publickey). La sortie de ssh -v indique lequel vous rencontrez.

Too many authentication failures dans un message de déconnexion signifie que votre client a proposé plusieurs clés avant d’arriver au mot de passe, et que le serveur a atteint MaxAuthTries, dont la valeur par défaut est 6. Forcez l’utilisation d’une seule méthode :

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

Connection refused sur un port qui fonctionnait encore une minute auparavant signifie généralement que fail2ban surveille SSH et a banni votre adresse après plusieurs échecs. Sa règle de bannissement par défaut rejette le paquet au lieu de le supprimer, ce qui explique que le refus soit renvoyé rapidement plutôt que d’entraîner un délai d’attente. Depuis la console, sudo fail2ban-client status sshd affiche les adresses bannies et sudo fail2ban-client set sshd unbanip 203.0.113.10 supprime la vôtre.

Les mots de passe sont une étape intermédiaire, les clés sont l’objectif

Un mot de passe qui fonctionne avec SSH est un mot de passe que tous les scanners sur Internet peuvent tenter de deviner. Passez à l’authentification par clé : les tentatives de devinette ne servent alors plus à rien. Générez une paire de clés, installez la clé publique, puis vérifiez depuis un deuxième terminal que la clé vous connecte avant de modifier quoi que ce soit d’autre. Notions de base sur la gestion des clés SSH couvre la génération, authorized_keys et les phrases secrètes.

Désactivez ensuite l’authentification par mot de passe et vérifiez-le avec sudo sshd -T au lieu de faire confiance au fichier que vous avez modifié. Renforcer la sécurité de SSH sur un VPS présente les autres paramètres de sshd qu’il est utile de modifier, tandis que Les dix premières minutes sur un nouveau VPS indique dans quel ordre les appliquer sur un serveur neuf.

Conservez tout de même un mot de passe. Un serveur qui n’accepte que les clés et dont la configuration de sshd est incorrecte n’est accessible que depuis la console du fournisseur, qui demande un nom d’utilisateur et un mot de passe. Un compte protégé par un mot de passe robuste que vous avez conservé peut faire la différence entre une correction en cinq minutes et une réinstallation.

FAQ

Comment modifier le mot de passe root sur mon VPS si je ne connais pas l’ancien ?

Connectez-vous avec un utilisateur qui peut exécuter sudo, puis exécutez sudo passwd root. Cette commande définit un nouveau mot de passe sans demander l’ancien, car sudo vous a déjà authentifié. Si aucun compte sur le serveur ne peut exécuter sudo, ouvrez la console du fournisseur, redémarrez dans le menu de récupération GRUB, choisissez l’entrée de shell root, exécutez mount -o remount,rw /, puis passwd. Si root possède déjà un mot de passe et que c’est celui que vous avez perdu, le shell de récupération vous le demande. Il ne reste alors que l’image de secours du fournisseur, avec le disque monté et un chroot configuré.

Pourquoi passwd affiche-t-il « Authentication token manipulation error » ?

Deux causes produisent ce message. La plus fréquente est une réponse incorrecte à l’invite Current password:, et la ligne passwd: password unchanged située dessous confirme qu’aucune modification n’a été écrite. L’autre cause est un système de fichiers impossible à modifier. C’est le cas en mode de récupération, car / y est monté en lecture seule. Exécutez mount -o remount,rw /, puis réessayez.

La modification de mon mot de passe Linux modifie-t-elle aussi mon mot de passe sudo ?

Oui. sudo n’a pas de mot de passe propre. Il vous authentifie via PAM à partir de la même entrée /etc/shadow que celle utilisée par SSH et su. Chaque compte possède donc un seul mot de passe. C’est aussi pourquoi la première invite sudo après une modification constitue le véritable test. Exécutez sudo -k && sudo -v pour forcer cette invite tant que votre session fonctionne encore.

La modification de mon mot de passe va-t-elle désactiver mes clés SSH ou mes sessions ouvertes ?

Non. L’authentification par clé publique ne lit jamais /etc/shadow. Les clés continuent donc de fonctionner après une modification du mot de passe, après passwd -l et après chage -d 0. Les sessions déjà ouvertes restent actives, car SSH vérifie les identifiants uniquement à la connexion. Dans une session active, le seul élément qui change est sudo, qui demande une fois le nouveau mot de passe lorsque son horodatage de 15 minutes expire.

Comment forcer un utilisateur à modifier son mot de passe lors de sa prochaine connexion ?

Exécutez sudo chage -d 0 deploy ou sudo passwd -e deploy, qui produit le même résultat. La date de dernière modification enregistrée revient à l’epoch. PAM considère alors le mot de passe comme expiré, et la prochaine connexion interactive doit en définir un nouveau avant le démarrage du shell. Ne faites pas cela pour un compte utilisé par des scripts via SSH : une commande non interactive échoue alors avec Password change required but no TTY available. et ne s’exécute jamais.