MySQL: Access denied for debian-sys-maint

Lors de la migration de bases de données d’un serveur à l’autre, j’ai déplacé la base mysql, qui contient les utilisateurs, les privilèges et une partie de la configuration interne du serveur SQL.

Sur le papier, cela évite de recréer tous les comptes SQL à la main. En pratique, cela peut aussi déplacer des comptes système propres à l’ancien serveur et casser les comptes de maintenance du nouveau.

C’est ainsi que l’on peut tomber sur cette erreur au démarrage ou à l’arrêt de MySQL :

Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)Code language: JavaScript (javascript)

Ou encore :

/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'Code language: JavaScript (javascript)

Le problème vient généralement d’un décalage entre l’utilisateur SQL debian-sys-maint présent dans MySQL/MariaDB et le mot de passe stocké dans le fichier système /etc/mysql/debian.cnf.

WPEngine: Premium Managed WooCommerce hosting

À quoi sert debian-sys-maint ?

Sur certaines anciennes installations Debian/Ubuntu, le paquet MySQL créait un utilisateur spécial nommé debian-sys-maint.

Cet utilisateur servait aux scripts de maintenance du paquet : vérifier l’état du serveur, recharger certaines informations, arrêter proprement MySQL, effectuer certaines tâches administratives, etc.

Son mot de passe était stocké dans :

/etc/mysql/debian.cnf

Le wiki Evolix résume bien ce comportement : sur Debian 10 et inférieur, certaines tâches passent par l’utilisateur SQL debian-sys-maint, avec un mot de passe stocké dans /etc/mysql/debian.cnf. Evolix Wiki : Howto MySQL

Sur des systèmes plus récents, surtout avec MariaDB et l’authentification par socket Unix, ce compte peut ne plus être présent ou ne plus être nécessaire. Il faut donc adapter le diagnostic à votre version réelle de MySQL/MariaDB.

Pourquoi l’erreur apparaît après une migration

Le cas classique est le suivant :

Le nouveau serveur installe MySQL ou MariaDB.
L’installation crée un fichier /etc/mysql/debian.cnf avec un mot de passe local.
Vous restaurez la base système mysql depuis l’ancien serveur.
Le compte SQL debian-sys-maint restauré possède l’ancien mot de passe.
Le fichier /etc/mysql/debian.cnf du nouveau serveur contient un autre mot de passe.
Les scripts de maintenance essaient de se connecter et obtiennent Access denied.

Autrement dit : le fichier système et la base SQL ne sont plus synchronisés.

C’est un tout petit fichier, mais il peut suffire à transformer un redémarrage MySQL en moment de solitude. Charmant, comme souvent avec les migrations.

Codeable: trouvez les meilleurs développeurs WordPress

Première vérification : quelle version utilisez-vous ?

Avant de réparer quoi que ce soit, vérifiez votre version SQL :

mysql --version
mysqld --version

Ou, avec MariaDB :

mariadb --version
mariadbd --version

Puis vérifiez le service :

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

Si vous êtes sur une ancienne Debian/Ubuntu avec MySQL, l’utilisateur debian-sys-maint peut être pertinent. Si vous êtes sur une installation MariaDB récente, le problème peut plutôt venir d’un vieux fichier de configuration, d’une restauration trop large de la base mysql, ou d’un script hérité.

Le plus lu : Restaurer le plan de travail (layout) sous SAM Broadcaster

Vérifier le fichier /etc/mysql/debian.cnf

Regardez si le fichier existe :

sudo ls -l /etc/mysql/debian.cnf

Affichez son contenu :

sudo cat /etc/mysql/debian.cnf

Sur une ancienne installation, il peut ressembler à ceci :

[client]
host     = localhost
user     = debian-sys-maint
password = mot-de-passe
socket   = /var/run/mysqld/mysqld.sock

[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = mot-de-passe
socket   = /var/run/mysqld/mysqld.sockCode language: JavaScript (javascript)

Le mot de passe présent dans ce fichier doit correspondre au mot de passe de l’utilisateur SQL debian-sys-maint.

Ce fichier contient un secret. Il ne doit pas être lisible par tout le monde.

sudo chmod 600 /etc/mysql/debian.cnf
sudo chown root:root /etc/mysql/debian.cnf

Kinsta: Premium Managed WordPress hosting

Solution historique : copier aussi /etc/mysql/debian.cnf

Si vous migrez toute la base système mysql d’un ancien serveur vers un nouveau serveur, il faut aussi penser au fichier correspondant :

/etc/mysql/debian.cnf

La solution la plus simple, dans le contexte d’une migration complète ancienne, consiste donc à copier ce fichier depuis l’ancien serveur vers le nouveau :

sudo scp root@ancien-serveur:/etc/mysql/debian.cnf /etc/mysql/debian.cnfCode language: JavaScript (javascript)

Puis à corriger ses permissions :

sudo chown root:root /etc/mysql/debian.cnf
sudo chmod 600 /etc/mysql/debian.cnf

Ensuite, redémarrez MySQL :

sudo systemctl restart mysql

ou MariaDB :

sudo systemctl restart mariadb

C’est tout bête, mais c’est aussi une bonne raison de conserver une sauvegarde complète de /etc lors d’une migration serveur.

Solution alternative : recréer ou réparer l’utilisateur SQL

Si vous ne pouvez pas récupérer l’ancien fichier debian.cnf, vous pouvez faire l’inverse : conserver le mot de passe présent dans /etc/mysql/debian.cnf et recréer l’utilisateur SQL avec ce même mot de passe.

Récupérez le mot de passe :

sudo awk '/password/ { print $3; exit }' /etc/mysql/debian.cnfCode language: JavaScript (javascript)

Connectez-vous à MySQL/MariaDB avec un compte administrateur :

sudo mysql

ou :

sudo mariadb

Vérifiez si l’utilisateur existe :

SELECT User, Host FROM mysql.user WHERE User = 'debian-sys-maint';Code language: JavaScript (javascript)

S’il existe, vous pouvez mettre à jour son mot de passe. Sur MySQL/MariaDB modernes, utilisez plutôt ALTER USER :

ALTER USER 'debian-sys-maint'@'localhost' IDENTIFIED BY 'mot-de-passe-du-fichier-debian-cnf';Code language: JavaScript (javascript)

Puis assurez-vous qu’il possède les privilèges nécessaires. Historiquement, ce compte avait des privilèges très élevés, parfois équivalents à un compte administrateur local. Plusieurs ressources d’administration Debian/MySQL décrivent ce compte comme utilisé par les scripts de maintenance et doté de privilèges importants. Server Fault : rôle de debian-sys-maint

GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;Code language: JavaScript (javascript)

S’il n’existe pas, vous pouvez le recréer :

CREATE USER 'debian-sys-maint'@'localhost' IDENTIFIED BY 'mot-de-passe-du-fichier-debian-cnf';
GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;Code language: JavaScript (javascript)

Adaptez évidemment le mot de passe à celui du fichier /etc/mysql/debian.cnf.

Tester la connexion debian-sys-maint

Une fois le fichier et l’utilisateur synchronisés, testez la connexion :

sudo mysql --defaults-file=/etc/mysql/debian.cnf -e "SELECT VERSION();"Code language: JavaScript (javascript)

Ou :

sudo mysqladmin --defaults-file=/etc/mysql/debian.cnf pingCode language: JavaScript (javascript)

Résultat attendu :

mysqld is alive

Si vous obtenez encore Access denied, le mot de passe du fichier et celui du compte SQL ne correspondent toujours pas.

Le plus lu : Ubuntu : supprimer les vieux kernels et libérer de la place sur la partition /boot

Cas moderne : root avec authentification unix_socket

Sur les installations MariaDB modernes, l’utilisateur root local utilise souvent l’authentification par socket Unix. Cela permet à l’utilisateur système root de se connecter avec :

sudo mariadb

sans mot de passe SQL séparé.

Dans ce contexte, debian-sys-maint peut ne plus être nécessaire. Si vous voyez cette erreur sur une machine récente, demandez-vous d’abord pourquoi un script essaie encore d’utiliser ce compte.

Pour chercher les références à debian-sys-maint :

sudo grep -R "debian-sys-maint" /etc /usr/local /home 2>/dev/nullCode language: JavaScript (javascript)

Il peut s’agir d’un vieux script de sauvegarde, d’un script de monitoring, d’un ancien cron, d’un plugin Munin/Nagios, ou d’une configuration copiée d’un ancien serveur.

Attention lors de la restauration de la base mysql

Restaurer la base système mysql d’un serveur vers un autre est une opération sensible.

Elle peut déplacer :

les comptes utilisateurs ;
les mots de passe ;
les plugins d’authentification ;
les privilèges ;
les comptes système ;
des informations internes dépendantes de la version ;
des privilèges incompatibles entre versions.

Si vous migrez entre versions majeures, ou entre MySQL et MariaDB, il est souvent plus propre d’exporter les bases applicatives et de recréer les utilisateurs explicitement, plutôt que de restaurer toute la base mysql.

Exemple pour exporter uniquement les bases applicatives :

mysqldump --single-transaction --routines --triggers --events ma_base > ma_base.sqlCode language: CSS (css)

Et recréer ensuite les utilisateurs avec des commandes CREATE USER et GRANT propres.

C’est un peu plus long au départ, mais cela évite de transporter les fantômes de l’ancien serveur. Et les fantômes SQL sont rarement bien élevés.

Sauvegarder /etc pendant une migration

Ce problème rappelle une règle simple : lors d’une migration serveur, ne sauvegardez pas seulement les bases et les fichiers web. Sauvegardez aussi les configurations système.

Au minimum :

sudo tar -czf etc-backup-$(date +%Y%m%d-%H%M%S).tar.gz /etcCode language: JavaScript (javascript)

Ou, pour cibler MySQL/MariaDB :

sudo tar -czf mysql-etc-backup-$(date +%Y%m%d-%H%M%S).tar.gz /etc/mysqlCode language: JavaScript (javascript)

Ce genre d’archive peut sauver beaucoup de temps : mots de passe de maintenance, chemins de sockets, configurations de réplication, réglages InnoDB, certificats TLS, scripts de backup, etc.

Lire les logs pour confirmer

Pour vérifier que l’erreur vient bien de debian-sys-maint, regardez les logs du service SQL :

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

Ou les logs traditionnels selon la distribution :

sudo grep -R "debian-sys-maint" /var/log/mysql /var/log/syslog /var/log/daemon.log 2>/dev/nullCode language: JavaScript (javascript)

Si l’erreur apparaît lors d’un cron, regardez aussi :

sudo grep -R "debian-sys-maint" /etc/cron* /var/spool/cron 2>/dev/nullCode language: JavaScript (javascript)

Méthode de réparation étape par étape

Voici la démarche complète que j’utiliserais aujourd’hui :

Vérifier la version : MySQL, MariaDB, Debian/Ubuntu.
Vérifier si /etc/mysql/debian.cnf existe.
Vérifier si l’utilisateur debian-sys-maint existe dans SQL.
Synchroniser le mot de passe du fichier et du compte SQL.
Tester avec mysql --defaults-file=/etc/mysql/debian.cnf.
Relancer le service.
Vérifier les logs.
Sur une installation moderne, chercher quel script utilise encore ce vieux compte.

Le plus lu : PHP : résoudre l'erreur "PHP Fatal error: Uncaught Error: Class DOMDocument"

Mémo rapide

# Erreur typique.
Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)

# Vérifier le fichier Debian.
sudo cat /etc/mysql/debian.cnf

# Vérifier les droits du fichier.
sudo chown root:root /etc/mysql/debian.cnf
sudo chmod 600 /etc/mysql/debian.cnf

# Se connecter en administrateur.
sudo mysql
# ou
sudo mariadb

# Vérifier si l’utilisateur existe.
SELECT User, Host FROM mysql.user WHERE User = 'debian-sys-maint';

# Mettre à jour le mot de passe.
ALTER USER 'debian-sys-maint'@'localhost' IDENTIFIED BY 'mot-de-passe-du-fichier-debian-cnf';

# Ou recréer l’utilisateur.
CREATE USER 'debian-sys-maint'@'localhost' IDENTIFIED BY 'mot-de-passe-du-fichier-debian-cnf';
GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

# Tester.
sudo mysql --defaults-file=/etc/mysql/debian.cnf -e "SELECT VERSION();"
sudo mysqladmin --defaults-file=/etc/mysql/debian.cnf ping

# Redémarrer.
sudo systemctl restart mysql
# ou
sudo systemctl restart mariadb

# Chercher les références héritées.
sudo grep -R "debian-sys-maint" /etc /usr/local /home 2>/dev/nullCode language: PHP (php)

Conclusion

L’erreur Access denied for user 'debian-sys-maint'@'localhost' apparaît généralement lorsque le mot de passe de l’utilisateur SQL debian-sys-maint ne correspond plus au mot de passe stocké dans /etc/mysql/debian.cnf.

Lors d’une migration ancienne où l’on restaure la base système mysql, il faut donc penser à copier aussi :

/etc/mysql/debian.cnf

ou à recréer l’utilisateur avec le mot de passe contenu dans ce fichier.

Sur une installation récente, notamment MariaDB avec authentification par socket Unix, ce compte peut ne plus être nécessaire. Dans ce cas, cherchez plutôt quel vieux script ou quelle ancienne configuration essaie encore de l’utiliser.

Enfin, cette erreur rappelle une règle simple : pendant une migration serveur, sauvegardez les bases, les fichiers web, mais aussi /etc. C’est souvent là que dorment les petits secrets qui évitent de perdre deux heures pour un mot de passe oublié par une machine très sûre d’elle-même.

Report a typo