Changer le mot de passe root d’un VPS Ubuntu

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 et ne demande jamais l’ancien, car sudo a déjà vérifié votre identité. Pour modifier votre propre mot de passe 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

L’opération s’arrête là. La suite traite les problèmes possibles : vérifier que le nouveau mot de passe fonctionne avant de perdre la session qui permettrait de corriger l’erreur, définir des mots de passe depuis un script, en rendre un volontairement expiré 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 rencontrés dans ce guide se corrigent en deux minutes lorsqu’un shell authentifié reste ouvert. Une intervention sur la console est nécessaire 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 demande. Le nouveau mot de passe est donc réellement testé la fois suivante où 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.

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 indique 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 n’est pas accessible en écriture, ce qui 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, 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 : cela fonctionne parce que le fichier sudoers drop-in 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é, de sorte qu’aucun mot de passe ne puisse correspondre. sudo passwd -u deploy le supprime. Consultez à nouveau 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 continuent 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, quelle que soit l’authentification présentée. 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 version qui contient encore nullok dans la pile PAM, un mot de passe vide peut être utilisé par n’importe qui.

Faut-il un mot de passe pour root sur un VPS ?

Ubuntu fournit root verrouillé. /etc/shadow contient ! à la place d’un hash, et sudo passwd -S root affiche une ligne commençant par root L. Il est impossible de 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 autorisé à utiliser sudo. Il faut conserver cette approche en travaillant avec des comptes utilisateur soumis au principe du moindre privilège sur un VPS, plutôt qu’en tant que root.

Définir un mot de passe pour root apporte un avantage précis : un moyen d’accès via la console du fournisseur. Cette console se connecte à la machine virtuelle sous la couche réseau. Elle reste donc disponible lorsque sshd est mal configuré ou qu’une règle de pare-feu est incorrecte. Cette configuration a aussi un inconvénient. Le shell root du menu de récupération GRUB demande le mot de passe de root lorsqu’il en existe un. L’outil qui permettrait de réinitialiser un mot de passe oublié se retrouve donc protégé par ce même mot de passe.

Définir un mot de passe pour root ne permet pas à root de se connecter via SSH. Ubuntu fournit PermitRootLogin prohibit-password, ce qui signifie que seules les clés sont acceptées. Vérifiez ce qu’utilise réellement votre serveur :

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 saisies depuis le terminal et ne peut pas être utilisé 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

Cela fonctionne, mais le mot de passe en clair apparaît 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 afficher les caractères saisis, puis affiche 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 à la connexion, car libxcrypt sait lire les deux. 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 reconnaî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 compte verrouillé et NP lorsqu’il n’y a aucun mot de passe. La date indique la dernière modification du mot de passe. Elle doit correspondre à la date du jour. Les nombres qui suivent sont les paramètres d’expiration détaillés ci-dessous.

Le test en conditions réelles 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 non privilégié. 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 laissant la session actuelle 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 refusé le mot de passe saisi.

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 à l’époque Unix. PAM considère donc 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 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 si une clé a servi à l’authentification. Un ssh deploy@203.0.113.10 'systemctl restart app' exécuté dans 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 job indique 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 l’utilisateur de revenir 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 à partir de quand les connexions affichent 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 définitivement refusé. 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 politique l’exige. Le NIST (National Institute of Standards and Technology des États-Unis) déconseille depuis 2017 l’expiration systématique des mots de passe. Cette pratique pousse les utilisateurs à choisir des variantes prévisibles d’un même mot de passe. Le NIST recommande plutôt de forcer un changement lorsqu’il existe des indices de compromission. Un mot de passe long et unique conservé dans un gestionnaire de mots de passe, associé à l’authentification SSH par clé, offre une meilleure protection qu’un cycle de 90 jours.

Que faire lorsque vous avez perdu le mot de passe root

Si un compte présent 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.

La procédure ci-dessous nécessite la console du fournisseur, généralement proposée dans les interfaces sous la forme d’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 l’interface du fournisseur 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 qui se termine 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 commande, 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 l’interface du fournisseur.

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 sur l’image de secours du fournisseur, puis montez 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. 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é 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 prend le pas sur le fichier principal. Consultez les valeurs effectives :

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

KbdInteractiveAuthentication yes associé à PasswordAuthentication no autorise toujours 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 explique pourquoi un serveur qui semble limité aux clés continue d’accepter les mots de passe saisis.

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 il y a une minute signifie généralement que fail2ban qui surveille SSH 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 plutôt que 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 le bannissement de la vôtre.

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

Un mot de passe utilisable 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 permet de vous connecter 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 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 tout de même 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 protégé par un mot de passe robuste que vous avez conservé peut faire la différence entre une correction de 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, sélectionnez 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 vous le demande. Il faut alors utiliser l’image de secours du fournisseur, monter le disque et effectuer un chroot.

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

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

Modifier mon mot de passe Linux modifie-t-il aussi mon mot de passe sudo ?

Oui. sudo n’a pas de mot de passe propre. Il vous authentifie via PAM en utilisant la même entrée /etc/shadow que 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 provoquer cette invite pendant que votre session fonctionne encore.

Modifier mon mot de passe désactive-t-il 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. 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. Les deux commandes ont le même effet. 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.