Modifier le mot de passe root sur Ubuntu

Comment modifier le mot de passe root de votre VPS sous Ubuntu

Pour modifier le mot de passe root de votre VPS (serveur privé virtuel) sous 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. Elle ne demande pas l’ancien, car sudo a déjà vérifié votre identité. Pour modifier le mot de passe de votre propre compte de connexion, exécutez passwd sans argument. La commande demande d’abord votre mot de passe actuel.

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

C’est toute l’opération. La suite traite les problèmes courants : vérifier que le nouveau mot de passe fonctionne avant de perdre la session qui permettrait de le corriger, 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 tant qu’un shell authentifié reste actif. Ils nécessitent une intervention sur la console dès que le dernier shell se ferme.

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 de nouveau. L’exception est sudo. Une fois son horodatage expiré, il vérifie de nouveau votre mot de passe via PAM (modules d’authentification enfichables), soit 15 minutes après la dernière invite par défaut. Le nouveau mot de passe est donc réellement testé la prochaine fois que sudo vous 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.

Modifier 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 qui signifie que le hash dans /etc/shadow a été remplacé. Tout autre résultat signifie que l’ancien mot de passe est resté 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é. C’est l’état normal en mode de récupération. You must choose a longer password. provient de pam_unix dans /etc/pam.d/common-password, qui applique des contrôles de longueur et de similarité aux utilisateurs ordinaires.

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, 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. Cela fonctionne parce que le fichier drop-in sudoers de l’image permet à ce compte d’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 fournir 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. Consultez l’état avec sudo passwd -S deploy.

Le verrouillage du mot de passe n’empêche pas l’utilisateur de se connecter. Toute clé présente dans son fichier ~/.ssh/authorized_keys continue de fonctionner, car l’authentification par clé publique ne lit jamais /etc/shadow. Pour désactiver 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 donc la connexion, quel que soit l’identifiant d’authentification fourni. 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. Dans une ancienne version qui contient encore nullok dans la pile PAM, un mot de passe vide peut être utilisé par n’importe qui.

root a-t-il besoin d’un mot de passe sur un VPS ?

Ubuntu fournit root verrouillé. /etc/shadow contient ! à la place d’un hash, et sudo passwd -S root affiche une ligne qui commence par root L. Aucun utilisateur ne peut se connecter en tant que root avec un mot de passe tant que vous n’en avez pas défini un. C’est pourquoi l’image vous fournit plutôt un utilisateur capable d’utiliser sudo. Utiliser des comptes utilisateur avec le principe du moindre privilège sur un VPS plutôt que root est la méthode à conserver.

Définir un mot de passe root apporte un seul avantage précis : un moyen d’accès via la console du fournisseur. Cette console se connecte à la machine virtuelle sous la pile réseau. Elle continue donc de fonctionner lorsque sshd est mal configuré ou qu’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 lorsqu’il existe. 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 ne permet pas à root de se connecter via SSH. Ubuntu fournit PermitRootLogin prohibit-password, ce qui signifie que seules les clés sont autorisées. Vérifiez ce que votre serveur utilise réellement :

sudo sshd -T | grep -i permitrootlogin

sshd -T affiche la configuration effective après la 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 depuis le terminal et ne peut pas être piloté depuis un script. chpasswd lit des paires user:password sur l’entrée standard, à raison d’une par ligne.

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

Cette commande fonctionne, mais elle place un mot de passe en clair dans l’historique de votre 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 le mot de passe deux fois sans l’afficher, puis imprime 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. Vous pouvez conserver ce hash 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 lit ces deux formats. Vous pouvez les mélanger. openssl passwd -6 se comporte de la même manière sur toutes les versions Ubuntu LTS, contrairement à chpasswd -c YESCRYPT : le paquet shadow plus ancien d’Ubuntu 20.04 ne connaît pas ce nom de méthode.

Comment vérifier que le mot de passe a réellement changé ?

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é, 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 ci-dessous.

Le test en direct le plus sûr consiste à utiliser sudo lui-même. sudo -k supprime l’horodatage mis en cache et sudo -v force une nouvelle invite. Si le nouveau mot de passe est accepté à ce stade, PAM l’a accepté et votre session n’a pas été modifiée.

sudo -k && sudo -v

Pour tester un autre compte, exécutez su - deploy depuis un shell non privilégié. N’exécutez pas sudo su - deploy, car root ne reçoit jamais de demande de mot de passe et le test ne prouve rien. Un mot de passe incorrect affiche su: Authentication failure.

Le véritable test consiste à ouvrir une nouvelle connexion SSH depuis votre ordinateur portable, tout en laissant la session active ouverte :

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Ici, Permission denied (publickey). signifie 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é ce que vous avez saisi.

Forcer le changement du 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 un nouveau mot de passe, avant d’ouvrir un shell. sudo passwd -e deploy fait exactement la même chose.

Utilisez cette commande 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 ssh deploy@203.0.113.10 'systemctl restart app' exécuté par un script é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 travail 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 à respecter avant de pouvoir modifier à nouveau le mot de passe. Cela empêche de reprendre immédiatement l’ancien mot de passe après un changement forcé. Le nombre maximal de jours (chage -M) indique la durée de validité du mot de passe. Le nombre de jours d’avertissement (chage -W) indique quand les connexions commencent à afficher un avertissement. Le nombre de jours d’inactivité (chage -I) correspond au délai de grâce après l’expiration, avant que le mot de passe ne soit plus du tout 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 cette valeur uniquement si une stratégie l’exige. Le NIST (National Institute of Standards and Technology des États-Unis) déconseille depuis 2017 l’expiration périodique 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 de forcer un changement lorsqu’il existe des preuves de compromission. Un mot de passe long et unique conservé dans un gestionnaire de mots de passe, associé à SSH avec authentification par clé, est plus sûr qu’un cycle de 90 jours.

Que faire lorsque vous avez perdu le mot de passe root

Si un compte sur le serveur 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ù aucune connexion ne fonctionne.

Tout ce qui suit nécessite la console du fournisseur, généralement indiquée dans les panels comme une console VNC (virtual network computing) ou série. Elle se connecte à la machine virtuelle sous la pile 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 panel 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 /. Le mode de récupération monte le système de fichiers root en lecture seule. Sans cette étape, passwd échoue avec passwd: Authentication token manipulation error, car il ne peut pas écrire dans /etc/shadow.
5. Exécutez passwd ubuntu pour le compte concerné, puis redémarrez depuis le panel.

Si root possède déjà un mot de passe et qu’il s’agit de 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 dans le système monté.

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 copier /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 dont vous disposez encore. S’il ne reste aucune session, utilisez la console.

Permission denied, please try again. signifie que le serveur a proposé l’authentification par mot de passe, puis a rejeté les informations envoyées. Les causes courantes sont l’activation de la touche Verr. Maj. 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 remplace les valeurs du fichier principal. Affichez les valeurs effectives :

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

La présence de KbdInteractiveAuthentication yes avec PasswordAuthentication no permet toujours l’utilisation d’un mot de passe, car la méthode keyboard-interactive utilise la même pile PAM. Désactiver l’une de ces méthodes tout en laissant l’autre active permet à un serveur qui semble limité aux clés de continuer à accepter les mots de passe saisis.

La présence de 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

La présence de Connection refused sur un port qui fonctionnait encore une minute auparavant signifie généralement que fail2ban qui surveille SSH a bloqué votre adresse après plusieurs échecs. Sa règle de bannissement par défaut rejette le paquet au lieu de le supprimer silencieusement. C’est pourquoi le refus revient rapidement au lieu d’expirer. 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, les clés sont l’objectif final

Un mot de passe utilisable via 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 sont alors plus pertinentes. Générez une paire de clés, installez la clé publique et vérifiez que la clé vous connecte depuis un deuxième terminal avant de modifier quoi que ce soit d’autre. Notions de base sur la gestion des clés SSH présente la génération, authorized_keys et les phrases secrètes.

Désactivez ensuite l’authentification par mot de passe et vérifiez le résultat 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, et Les dix premières minutes sur un nouveau VPS les classe dans l’ordre à suivre sur un serveur fraîchement installé.

Conservez ensuite un mot de passe. Un serveur qui n’autorise que les clés et dont la configuration de sshd est incorrecte n’est accessible que par la console du fournisseur, qui demande un nom d’utilisateur et un mot de passe. Un compte avec un mot de passe robuste que vous avez enregistré fait 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 autorisé à 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. La seule solution restante consiste à utiliser l’image de secours du fournisseur, avec le disque monté et l’environnement chroot configuré.

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

Deux causes produisent ce message. La plus courante est une réponse incorrecte à l’invite Current password:. 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 sur lequel il est impossible d’écrire. 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 ne possède pas son propre mot de passe. Il vous authentifie via PAM avec la même entrée /etc/shadow que SSH et su utilisent. Chaque compte possède donc un seul mot de passe. C’est également 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 interrompt-elle 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 lors de la connexion. Dans une session active, seul sudo change de comportement. Cette commande demande le nouveau mot de passe une fois que son horodatage de 15 minutes a expiré.

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. Ces commandes ont le même effet. La date de dernière modification enregistrée est définie sur l’époque. 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. N’appliquez pas cette procédure à 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.