Réinitialiser le mot de passe root de MySQL ou MariaDB sous Debian

Vous avez perdu le mot de passe root de MySQL ou MariaDB sur Debian ? Avant de sortir la grosse artillerie, respirez deux secondes. Sur beaucoup d’installations Debian, le compte SQL root n’utilise pas forcément un mot de passe classique.

Avec MariaDB, il est fréquent que root utilise l’authentification par socket Unix. Cela signifie que l’utilisateur système root peut se connecter à MariaDB avec sudo mariadb ou sudo mysql, sans saisir de mot de passe SQL.

Donc, avant de réinitialiser brutalement le mot de passe, il faut identifier le serveur, vérifier le mode d’authentification, puis choisir la bonne procédure.

MySQL, MariaDB et root : attention au faux problème

Sur un serveur Debian récent, perdre le “mot de passe root MySQL” peut vouloir dire plusieurs choses :

• vous ne connaissez plus le mot de passe SQL de root@localhost ;
• le compte root n’accepte plus l’authentification par mot de passe ;
• MariaDB utilise unix_socket, donc aucun mot de passe SQL n’est nécessaire en local ;
• vous utilisez le mauvais client : mysql, mariadb, phpMyAdmin, Adminer ou une application distante ;
• le service SQL ne démarre plus, ce qui n’a rien à voir avec le mot de passe ;
• un plugin d’authentification a été modifié pendant une migration.

Le compte root SQL n’est pas le même que le compte root Linux. Le premier administre MySQL ou MariaDB. Le second administre le serveur. Les deux ont de grands pouvoirs, donc deux excellentes occasions de casser un serveur un vendredi soir.

Identifier le serveur installé

Commencez par savoir si vous utilisez MySQL ou MariaDB :

mysql --version

ou :

mariadb --version

Vous pouvez aussi vérifier les paquets installés :

dpkg -l | grep -Ei 'mysql-server|mariadb-server'Langage du code : JavaScript (javascript)

Puis regardez le service systemd actif :

systemctl status mariadb --no-pager
systemctl status mysql --no-pager

Sur Debian, MariaDB utilise généralement le service mariadb. MySQL utilise plutôt mysql. Selon l’installation, certains alias peuvent exister, mais ne partez pas du principe que les deux commandes pointent vers le même service.

Essayer d’abord l’accès socket

Avant de réinitialiser quoi que ce soit, essayez la connexion locale avec sudo.

Pour MariaDB :

sudo mariadb

Ou, selon votre installation :

sudo mysql

Si vous obtenez un prompt SQL, vous n’avez pas vraiment perdu l’accès administrateur. Vous pouvez vérifier l’utilisateur courant :

SELECT USER(), CURRENT_USER();

Vous pouvez aussi lister les comptes administrateurs :

SELECT User, Host FROM mysql.user WHERE User = 'root';Langage du code : JavaScript (javascript)

Si cette connexion fonctionne, utilisez la méthode normale de changement de mot de passe. Ne démarrez pas le serveur en mode --skip-grant-tables juste par nostalgie du cambouis.

Changer le mot de passe root quand l’accès sudo fonctionne

Si vous pouvez entrer avec sudo mariadb ou sudo mysql, changez le mot de passe proprement.

Pour MariaDB :

sudo mariadb

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('NouveauMotDePasseTresLong');
FLUSH PRIVILEGES;Langage du code : JavaScript (javascript)

Pour MySQL 8 ou plus récent :

sudo mysql

ALTER USER 'root'@'localhost' IDENTIFIED BY 'NouveauMotDePasseTresLong';
FLUSH PRIVILEGES;Langage du code : JavaScript (javascript)

Ensuite, quittez :

EXIT;Langage du code : PHP (php)

Testez la connexion par mot de passe :

mysql -u root -p

Attention : selon le plugin d’authentification utilisé, le compte root peut continuer à privilégier l’authentification socket locale. Ce n’est pas forcément un problème. Sur un serveur Debian, c’est même souvent souhaitable.

Sauvegarder avant une réinitialisation forcée

Si l’accès administrateur ne fonctionne plus du tout, sauvegardez ce qui peut l’être avant de modifier les comptes système de MySQL ou MariaDB.

Si le service SQL tourne encore et qu’un autre compte admin fonctionne, exportez les bases :

mysqldump --all-databases --single-transaction --routines --triggers --events > all-databases-before-root-reset.sqlLangage du code : CSS (css)

Si vous n’avez plus aucun accès SQL, sauvegardez au moins le répertoire de données à froid après arrêt du service. Sur Debian, il se trouve généralement dans /var/lib/mysql.

sudo systemctl stop mariadb
sudo rsync -aHAX --numeric-ids /var/lib/mysql/ /root/mysql-datadir-backup/Langage du code : JavaScript (javascript)

Adaptez le service si vous utilisez MySQL :

sudo systemctl stop mysql
sudo rsync -aHAX --numeric-ids /var/lib/mysql/ /root/mysql-datadir-backup/Langage du code : JavaScript (javascript)

Une sauvegarde logique avec mysqldump est plus portable. Une copie du datadir est utile en dernier recours, mais elle doit être faite service arrêté pour éviter une copie incohérente.

Méthode de secours : démarrer avec –skip-grant-tables

Si vous ne pouvez plus vous connecter avec aucun compte administrateur, vous pouvez démarrer temporairement le serveur avec --skip-grant-tables.

Ce mode désactive les contrôles de privilèges. Toute personne capable de se connecter au socket local peut entrer sans mot de passe. Il faut donc aussi désactiver les connexions réseau avec --skip-networking.

Arrêtez d’abord le service.

Pour MariaDB :

sudo systemctl stop mariadb

Pour MySQL :

sudo systemctl stop mysql

Vérifiez qu’aucun processus serveur ne tourne encore :

ps aux | grep -E 'mysqld|mariadbd' | grep -v grepLangage du code : JavaScript (javascript)

Si un vieux processus reste actif, identifiez-le proprement avant de le tuer. Ne faites pas un killall rageur sur un serveur en production.

Démarrer MariaDB en mode récupération

Sur MariaDB, vous pouvez essayer :

sudo mariadbd-safe --skip-grant-tables --skip-networking --pid-file=/tmp/mariadb-reset.pid &Langage du code : JavaScript (javascript)

Selon la distribution et la version, la commande peut aussi être :

sudo mysqld_safe --skip-grant-tables --skip-networking --pid-file=/tmp/mariadb-reset.pid &Langage du code : JavaScript (javascript)

Attendez quelques secondes, puis connectez-vous sans mot de passe :

mysql -u root

Rechargez ensuite les tables de privilèges. C’est important, car les instructions de gestion des comptes peuvent être bloquées tant que les grant tables ne sont pas rechargées.

FLUSH PRIVILEGES;

Puis changez le mot de passe :

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('NouveauMotDePasseTresLong');
FLUSH PRIVILEGES;Langage du code : JavaScript (javascript)

Quittez :

EXIT;Langage du code : PHP (php)

Démarrer MySQL en mode récupération

Pour MySQL, démarrez temporairement le serveur avec les grant tables désactivées et le réseau coupé :

sudo mysqld_safe --skip-grant-tables --skip-networking --pid-file=/tmp/mysql-reset.pid &Langage du code : JavaScript (javascript)

Connectez-vous sans mot de passe :

mysql -u root

Rechargez les privilèges :

FLUSH PRIVILEGES;

Puis changez le mot de passe :

ALTER USER 'root'@'localhost' IDENTIFIED BY 'NouveauMotDePasseTresLong';
FLUSH PRIVILEGES;Langage du code : JavaScript (javascript)

Quittez :

EXIT;Langage du code : PHP (php)

Si ALTER USER échoue encore avec une erreur liée à --skip-grant-tables, c’est généralement que FLUSH PRIVILEGES n’a pas été exécuté ou n’a pas réussi.

Redémarrer normalement après la modification

Après avoir changé le mot de passe, arrêtez le serveur lancé manuellement. Si vous avez utilisé un fichier PID temporaire :

sudo kill "$(cat /tmp/mysql-reset.pid 2>/dev/null || cat /tmp/mariadb-reset.pid 2>/dev/null)"Langage du code : JavaScript (javascript)

Si le fichier PID n’existe pas, identifiez le processus :

ps aux | grep -E 'mysqld|mariadbd' | grep -v grepLangage du code : JavaScript (javascript)

Puis redémarrez le vrai service systemd.

Pour MariaDB :

sudo systemctl start mariadb
sudo systemctl status mariadb --no-pager

Pour MySQL :

sudo systemctl start mysql
sudo systemctl status mysql --no-pager

Vérifiez les logs si le service ne démarre pas :

journalctl -u mariadb -n 100 --no-pager
journalctl -u mysql -n 100 --no-pager

Tester la connexion après réinitialisation

Testez d’abord avec sudo :

sudo mysql -e "SELECT VERSION(), USER(), CURRENT_USER();"Langage du code : JavaScript (javascript)

ou :

sudo mariadb -e "SELECT VERSION(), USER(), CURRENT_USER();"Langage du code : JavaScript (javascript)

Testez ensuite avec mot de passe :

mysql -u root -p -e "SELECT VERSION(), USER(), CURRENT_USER();"Langage du code : JavaScript (javascript)

Si la connexion par mot de passe échoue mais que sudo mysql fonctionne, vérifiez le plugin d’authentification du compte root.

Vérifier le plugin d’authentification du compte root

Sur MySQL, vous pouvez généralement afficher le plugin avec :

SELECT User, Host, plugin FROM mysql.user WHERE User = 'root';Langage du code : JavaScript (javascript)

Sur MariaDB récent, les informations peuvent être stockées différemment. Essayez d’abord :

SELECT User, Host, plugin FROM mysql.user WHERE User = 'root';Langage du code : JavaScript (javascript)

Si le résultat n’est pas assez clair, inspectez la table mysql.global_priv :

SELECT Host, User, Priv FROM mysql.global_priv WHERE User = 'root'\GLangage du code : JavaScript (javascript)

Sur MariaDB, unix_socket signifie que le compte peut s’authentifier via l’utilisateur système local. Sur MySQL, vous pouvez rencontrer des plugins comme auth_socket, caching_sha2_password ou mysql_native_password selon la version et l’origine des paquets.

Faut-il garder root en unix_socket ou forcer un mot de passe ?

Sur Debian, je préfère souvent garder root accessible uniquement localement via socket et sudo. C’est propre pour l’administration serveur, et cela évite d’avoir un mot de passe root SQL réutilisé dans des scripts, des applications ou des interfaces web.

Pour les applications, créez plutôt des utilisateurs dédiés :

CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'MotDePasseTresLongEtUnique';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP
ON nom_de_base.*
TO 'app_user'@'localhost';
FLUSH PRIVILEGES;Langage du code : JavaScript (javascript)

Adaptez les privilèges au besoin réel. Une application WordPress n’a pas besoin d’utiliser le compte root. Jamais. Même si “ça marche”. Surtout si “ça marche”.

Créer un compte admin SQL de secours

Si vous voulez éviter de dépendre uniquement du compte root, créez un compte administrateur SQL local avec un mot de passe fort.

CREATE USER 'dbadmin'@'localhost' IDENTIFIED BY 'MotDePasseAdminTresLong';
GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;Langage du code : JavaScript (javascript)

Gardez ce mot de passe dans un gestionnaire sécurisé. N’utilisez pas ce compte dans une application. Il sert à l’administration humaine, pas à WordPress, phpMyAdmin ou un script cron oublié.

Cas phpMyAdmin ou Adminer

Si votre seul problème est l’impossibilité de vous connecter à phpMyAdmin avec root, ce n’est pas forcément une panne. Avec l’authentification par socket, root peut être réservé à l’administration locale via sudo.

La bonne pratique consiste à créer un utilisateur dédié pour phpMyAdmin ou Adminer, avec les privilèges nécessaires mais sans utiliser root si ce n’est pas indispensable.

Pour administrer une base WordPress précise :

CREATE USER 'wp_admin'@'localhost' IDENTIFIED BY 'MotDePasseTresLong';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_admin'@'localhost';
FLUSH PRIVILEGES;Langage du code : JavaScript (javascript)

C’est moins spectaculaire que de forcer root dans phpMyAdmin, mais beaucoup plus propre.

Cas WordPress : ne touchez pas à wp-config.php trop vite

Si WordPress affiche une erreur de connexion à la base, le problème ne vient pas forcément du mot de passe root. WordPress n’utilise normalement pas root, mais un utilisateur défini dans wp-config.php.

Vérifiez les constantes :

grep -E "DB_NAME|DB_USER|DB_HOST" wp-config.phpLangage du code : JavaScript (javascript)

Ne faites pas afficher le mot de passe en clair dans un terminal partagé. Si vous devez tester l’utilisateur WordPress :

mysql -u utilisateur_wordpress -p -h localhost nom_de_base

Si le mot de passe WordPress est perdu mais que vous avez un accès admin SQL, changez plutôt le mot de passe de cet utilisateur applicatif. Ne basculez pas WordPress sur root. C’est comme donner les clés du datacenter au grille-pain.

Commandes utiles de diagnostic

Voici les commandes que j’utilise pour diagnostiquer rapidement un problème d’accès root MySQL ou MariaDB sous Debian :

# Version du client.
mysql --version
mariadb --version

# Paquets installés.
dpkg -l | grep -Ei 'mysql-server|mariadb-server'

# Services actifs.
systemctl status mariadb --no-pager
systemctl status mysql --no-pager

# Logs récents.
journalctl -u mariadb -n 100 --no-pager
journalctl -u mysql -n 100 --no-pager

# Test d’accès local par socket.
sudo mariadb -e "SELECT VERSION(), USER(), CURRENT_USER();"
sudo mysql -e "SELECT VERSION(), USER(), CURRENT_USER();"

# Test d’accès par mot de passe.
mysql -u root -p -e "SELECT VERSION(), USER(), CURRENT_USER();"

# Comptes root SQL.
sudo mysql -e "SELECT User, Host FROM mysql.user WHERE User = 'root';"

# Plugins d’authentification si disponible.
sudo mysql -e "SELECT User, Host, plugin FROM mysql.user WHERE User = 'root';"Langage du code : PHP (php)

Erreurs fréquentes

ERROR 1698 (28000): Access denied for user ‘root’@’localhost’

Cette erreur apparaît souvent quand vous essayez mysql -u root -p alors que root utilise une authentification par socket. Essayez plutôt :

sudo mysql

ou :

sudo mariadb

ERROR 1290 avec –skip-grant-tables

MySQL peut refuser ALTER USER tant que le serveur tourne avec --skip-grant-tables. Dans la session SQL, lancez d’abord :

FLUSH PRIVILEGES;

Puis relancez ALTER USER.

mysqld_safe ou mariadbd-safe introuvable

Selon la distribution, la commande peut avoir changé de nom ou ne pas être dans votre PATH. Cherchez-la :

command -v mysqld_safe
command -v mariadbd-safe
ls -l /usr/bin/*safe | grep -Ei 'mysql|maria'

Si nécessaire, consultez aussi les logs systemd pour comprendre comment le serveur est lancé normalement.

Le service ne redémarre plus après la manipulation

Vérifiez qu’il ne reste pas un serveur lancé manuellement :

ps aux | grep -E 'mysqld|mariadbd' | grep -v grepLangage du code : JavaScript (javascript)

Puis consultez les logs :

journalctl -u mariadb -n 150 --no-pager
journalctl -u mysql -n 150 --no-pager

Si MariaDB refuse de démarrer, lisez aussi MariaDB ne veut plus redémarrer : quelques solutions.

Ancienne méthode avec UPDATE mysql.user : à éviter

Les anciens tutoriels proposaient souvent une commande comme celle-ci :

UPDATE mysql.user SET Password=PASSWORD('nouveau_mot_de_passe') WHERE User='root';Langage du code : JavaScript (javascript)

Je ne recommande plus cette méthode. Les colonnes, tables et plugins d’authentification ont changé selon les versions de MySQL et MariaDB. Sur MySQL moderne, la colonne Password n’est plus le bon point d’entrée. Sur MariaDB récent, la logique peut passer par mysql.global_priv.

Utilisez plutôt les instructions de gestion de compte prévues par le serveur :

• ALTER USER pour MySQL moderne ;
• SET PASSWORD FOR pour MariaDB ;
• FLUSH PRIVILEGES quand vous êtes passé par --skip-grant-tables.

Modifier directement les tables système, c’est parfois nécessaire en réparation avancée. Mais en procédure standard, c’est le genre de raccourci qui finit par coûter plus cher que la route normale.

Checklist de réinitialisation root MySQL/MariaDB

• Identifier si le serveur utilise MySQL ou MariaDB.
• Tester sudo mariadb ou sudo mysql avant toute manipulation.
• Vérifier les comptes root et leurs hôtes.
• Changer le mot de passe normalement si l’accès socket fonctionne.
• Sauvegarder les bases ou le datadir avant une procédure forcée.
• Arrêter le service avec systemctl.
• Démarrer temporairement avec --skip-grant-tables --skip-networking.
• Exécuter FLUSH PRIVILEGES avant ALTER USER ou SET PASSWORD.
• Redémarrer le vrai service systemd.
• Tester l’accès avec sudo et avec mot de passe.
• Créer un compte admin de secours si nécessaire.
• Ne jamais utiliser root pour une application WordPress.
• Documenter le nouveau mode d’accès dans votre coffre de mots de passe.

Besoin d’aide pour réparer MySQL, MariaDB ou WordPress ?

FAQ : mot de passe root MySQL/MariaDB sous Debian

Pourquoi sudo mysql fonctionne mais mysql -u root -p échoue ?

Parce que le compte root SQL utilise probablement une authentification par socket Unix. L’utilisateur système root peut se connecter localement avec sudo, mais l’authentification par mot de passe n’est pas forcément active.

Faut-il toujours définir un mot de passe root MySQL ?

Pas forcément. Sur Debian avec MariaDB, garder root en authentification socket peut être une bonne pratique. Pour les applications, créez plutôt des utilisateurs SQL dédiés avec des privilèges limités.

Que fait –skip-grant-tables ?

Cette option démarre MySQL ou MariaDB sans appliquer les tables de privilèges. Elle permet de se connecter sans mot de passe. C’est pratique pour récupérer l’accès, mais dangereux si le réseau n’est pas désactivé.

Pourquoi ajouter –skip-networking ?

Parce que --skip-grant-tables désactive l’authentification. Avec --skip-networking, le serveur n’accepte pas de connexions réseau pendant la récupération. Cela limite le risque aux accès locaux.

Pourquoi ALTER USER échoue en mode skip-grant-tables ?

MySQL désactive certaines instructions de gestion de comptes tant que les grant tables ne sont pas rechargées. Lancez d’abord FLUSH PRIVILEGES, puis relancez ALTER USER.

Puis-je utiliser root dans wp-config.php ?

Non. WordPress doit utiliser un utilisateur SQL dédié à sa base, avec les privilèges nécessaires et rien de plus. Utiliser root dans wp-config.php est une mauvaise pratique de sécurité.

Sources

• MySQL 8.4 Reference Manual : How to Reset the Root Password
• MySQL 9.6 Reference Manual : How to Reset the Root Password
• MariaDB Documentation : Authentication from MariaDB 10.4
• MariaDB Documentation : Authentication Plugin unix_socket
• MariaDB Documentation : SET PASSWORD
• MySQL Reference Manual : ALTER USER
• SkyMinds : réinitialiser le mot de passe root d’un serveur MySQL ou MariaDB
• SkyMinds : MariaDB ne veut plus redémarrer, quelques solutions
• SkyMinds : WordPress, changer le mot de passe d’un utilisateur depuis le serveur SQL
• SkyMinds : nettoyer et optimiser la base de données WordPress

Report a typo