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 toutes les erreurs de ce guide se corrigent en deux minutes tant qu’un shell authentifié reste ouvert. Une fois le dernier shell fermé, il faut généralement intervenir via la console.

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 à la connexion et ne les vérifie pas à nouveau. L’exception est sudo. Ce programme vérifie à nouveau votre mot de passe via PAM (modules d’authentification enfichables) lorsque ses identifiants mis en cache expirent, après 15 minutes par défaut sur Ubuntu. Ce délai ne part pas de la dernière invite, car sudo -v actualise les identifiants mis en cache sans demander à nouveau le mot de passe. 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, 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 opération distincte. sudo passwd -l deploy ajoute un ! devant le hash enregistré, de sorte qu’aucun mot de passe ne puisse correspondre. sudo passwd -u deploy le supprime. Consultez ensuite l’état avec sudo passwd -S deploy.

Le verrouillage du mot de passe n’empêche pas cet utilisateur de se connecter. Les clés présentes dans son fichier ~/.ssh/authorized_keys continuent de fonctionner, car l’authentification par clé publique ne vérifie pas le hash du mot de passe. Pour bloquer complètement un compte, faites expirer le compte lui-même :

sudo usermod --expiredate 1 deploy

Cela définit l’expiration du compte à une date en 1970. sshd refuse alors la connexion, quel que soit le moyen d’authentification présenté. Annulez ce réglage 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 version qui utilise encore nullok dans la pile PAM, un mot de passe vide est utilisable 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 données depuis le terminal et ne peut pas être piloté depuis un script. chpasswd lit des paires user:password depuis l’entrée standard, à raison d’une par ligne.

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

Cela fonctionne, mais le mot de passe en clair est enregistré 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 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é ; il est donc copié tel quel dans /etc/shadow. Vous pouvez conserver ce hash dans un dépôt ou une variable de CI sans risque, et 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 sans problème, et openssl passwd -6 se comporte de la même manière sur toutes les versions Ubuntu LTS depuis 18.04, contrairement à chpasswd -c YESCRYPT : le paquet shadow plus ancien d’Ubuntu 20.04 ne reconnaît pas ce nom de méthode. Ubuntu 16.04 fait exception, car son OpenSSL 1.0.2 ne propose aucune option -6. Ces hash sont également conservés lors d’un changement de 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. PAM considère ainsi que le mot de passe a 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 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 PAM de gestion du compte, même lorsqu’une clé a servi à l’authentification. Un ssh deploy@203.0.113.10 'systemctl restart app' scripté échoue alors avec ce message avant l’exécution de la commande :

Password change required but no TTY available.

La commande distante ne s’exécute jamais et ssh se termine avec un code différent de zéro. Sauf si le script appelant s’arrête en cas d’erreur avec set -e ou une vérification explicite, les lignes suivantes continuent de s’exécuter et le job peut se terminer comme si le redémarrage avait bien eu lieu.

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 refusé la valeur envoyée. 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 et, sur Ubuntu 22.04 et les versions ultérieures, se trouve généralement dans un fichier drop-in sous /etc/ssh/sshd_config.d/ qui surcharge le fichier principal. Lisez les valeurs effectives :

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

KbdInteractiveAuthentication yes associé à PasswordAuthentication no laisse quand même passer un mot de passe, car la méthode keyboard-interactive utilise la même pile PAM. Désactiver l’une des deux 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 même ligne s’affiche aussi lorsqu’une connexion par clé est refusée. Si vous proposiez une clé plutôt qu’un mot de passe, le réglage du serveur concernant les mots de passe n’est que l’un des cinq problèmes à l’origine de Permission denied (publickey), et la sortie de ssh -v indique lequel vous rencontrez.

Too many authentication failures dans un message de déconnexion signifie que la connexion a épuisé la limite MaxAuthTries du serveur, qui est de 6 tentatives par défaut. La cause habituelle est un client qui a proposé plusieurs clés avant de passer au mot de passe. 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 il y a une minute 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 silencieusement, ce qui explique que le refus revienne 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 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 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 du 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 du 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 le demande. Il faut alors utiliser l’image de secours du fournisseur, monter le disque et exécuter chroot.

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:. 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 SSH et su utilisent. 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 vrai test. Exécutez sudo -k && sudo -v pour forcer cette invite tant que votre session fonctionne encore.

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

Non, une modification du mot de passe ou de passwd -l ne les désactive pas. L’authentification par clé publique ne vérifie pas le hash du mot de passe. Les clés continuent donc de fonctionner après l’une ou l’autre opération. chage -d 0 est différent : sshd exécute toujours les contrôles de compte PAM après une connexion par clé. Ces contrôles lisent les paramètres d’expiration du mot de passe dans /etc/shadow. Un mot de passe expiré oblige donc une connexion par clé à demander un nouveau mot de passe et fait échouer les commandes SSH automatisées. Les sessions déjà ouvertes restent actives, car SSH vérifie les identifiants uniquement à la connexion. Dans une session active, seul sudo change de comportement : il demande 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. 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.