MySQL : corriger “Using a password on the command line interface can be insecure”

Quand vous utilisez MySQL en ligne de commande, vous pouvez tomber sur cet avertissement :

mysql: [Warning] Using a password on the command line interface can be insecure.Langage du code : CSS (css)

Il apparaît généralement quand vous passez le mot de passe directement dans la commande MySQL :

mysql -u root -pMotDePasse

La commande fonctionne, mais MySQL vous prévient que cette pratique n’est pas sûre. Et pour une fois, l’avertissement n’est pas là pour décorer le terminal.

Voici pourquoi ce message apparaît, ce qu’il faut éviter, et les méthodes propres pour utiliser MySQL en ligne de commande sans exposer votre mot de passe.

Pourquoi MySQL affiche cet avertissement ?

MySQL affiche cet avertissement lorsque le mot de passe est fourni directement dans la ligne de commande, par exemple avec -pMotDePasse ou --password=MotDePasse.

Le risque vient du fait qu’une ligne de commande peut être visible à plusieurs endroits :

• dans l’historique du shell ;
• dans la liste des processus ;
• dans certains outils de monitoring ;
• dans des logs de scripts ;
• dans des sauvegardes de scripts ;
• dans un dépôt Git si la commande est copiée dans un fichier versionné.

Sur une machine mono-utilisateur, le risque peut sembler faible. Sur un serveur partagé, une machine de production, un environnement CI/CD ou un poste de développement avec beaucoup d’outils, c’est une mauvaise habitude à corriger.

La mauvaise pratique classique

Voici la commande qui déclenche généralement l’avertissement :

mysql -u root -pMotDePasse nom_de_base

Ou sa variante longue :

mysql --user=root --password=MotDePasse nom_de_base

Ces commandes sont pratiques, mais elles exposent le mot de passe. C’est exactement ce que MySQL vous signale.

À noter : avec l’option courte -p, il ne faut pas mettre d’espace entre -p et le mot de passe. Mais le fait que la syntaxe fonctionne ne la rend pas recommandable. C’est comme rouler sans ceinture sur un parking : techniquement possible, stratégiquement idiot.

Solution rapide : laisser MySQL demander le mot de passe

La correction la plus simple consiste à utiliser -p sans écrire le mot de passe après.

mysql -u root -p nom_de_base

MySQL vous demandera alors le mot de passe de manière interactive :

Enter password:

Cette méthode évite d’inscrire le mot de passe dans l’historique du shell ou dans la commande visible. Pour une connexion ponctuelle, c’est souvent suffisant.

Mais pour les scripts, les sauvegardes automatisées ou les commandes fréquentes, mieux vaut utiliser une méthode plus propre.

Meilleure solution MySQL : mysql_config_editor

La solution recommandée avec MySQL est mysql_config_editor. Cet outil crée un fichier .mylogin.cnf dans le répertoire de l’utilisateur. Ce fichier contient des profils de connexion appelés login paths.

Un login path peut stocker notamment :

• l’hôte ;
• l’utilisateur ;
• le mot de passe ;
• le port ;
• le socket.

Le mot de passe n’apparaît plus dans la commande. Les clients MySQL lisent les informations depuis .mylogin.cnf quand vous utilisez --login-path.

Créer un login path MySQL

Voici un exemple pour créer un profil nommé local :

mysql_config_editor set \
	--login-path=local \
	--host=localhost \
	--user=root \
	--passwordLangage du code : JavaScript (javascript)

L’outil vous demandera ensuite le mot de passe :

Enter password:

Ensuite, vous pouvez vous connecter sans écrire le mot de passe :

mysql --login-path=local

Vous pouvez aussi préciser une base :

mysql --login-path=local nom_de_base

La commande est plus propre, plus lisible et beaucoup moins risquée dans l’historique shell.

Créer plusieurs profils de connexion

Vous pouvez créer plusieurs login paths pour plusieurs environnements.

mysql_config_editor set \
	--login-path=prod \
	--host=db-prod.example.com \
	--user=backup_user \
	--password

mysql_config_editor set \
	--login-path=staging \
	--host=db-staging.example.com \
	--user=deploy_user \
	--password

mysql_config_editor set \
	--login-path=local \
	--host=localhost \
	--user=root \
	--passwordLangage du code : JavaScript (javascript)

Vous pouvez ensuite choisir le bon profil selon le contexte :

mysql --login-path=prod
mysql --login-path=staging
mysql --login-path=local

C’est particulièrement pratique quand vous administrez plusieurs sites WordPress, plusieurs serveurs ou plusieurs bases distantes.

Lister les login paths existants

Pour afficher les profils enregistrés :

mysql_config_editor print --allLangage du code : PHP (php)

Le mot de passe n’est pas affiché en clair. Vous verrez plutôt une sortie du type :

[local]
user = root
password = *****
host = localhost

Pour afficher un seul profil :

mysql_config_editor print --login-path=localLangage du code : PHP (php)

Supprimer un login path

Pour supprimer un profil :

mysql_config_editor remove --login-path=local

Pour supprimer seulement un champ, par exemple le mot de passe :

mysql_config_editor remove --login-path=local --password

Si vous voulez repartir de zéro, vous pouvez supprimer le fichier .mylogin.cnf de l’utilisateur concerné, mais préférez les commandes de l’outil quand c’est possible.

Utiliser mysql_config_editor avec mysqldump

Le login path fonctionne aussi avec plusieurs outils clients MySQL, notamment mysqldump.

mysqldump --login-path=prod nom_de_base > backup.sql

Pour compresser directement la sauvegarde :

mysqldump --login-path=prod nom_de_base | gzip > backup.sql.gz

Dans un script de sauvegarde, c’est beaucoup plus propre que d’écrire :

mysqldump -u backup_user -pMotDePasse nom_de_base > backup.sqlLangage du code : CSS (css)

Le mot de passe n’apparaît plus dans le script. Et votre futur audit sécurité évite de vous regarder avec déception.

Où se trouve le fichier .mylogin.cnf ?

Sur Linux et macOS, le fichier est créé dans le répertoire personnel de l’utilisateur :

~/.mylogin.cnf

Sur Windows, il se trouve dans le répertoire MySQL du profil utilisateur, généralement sous :

%APPDATA%\MySQL\.mylogin.cnfLangage du code : CSS (css)

Ce fichier est associé à l’utilisateur système. Si vous exécutez une commande sous un autre utilisateur, par exemple via sudo ou une tâche cron, ce n’est pas forcément le même fichier qui sera lu.

Attention avec sudo et cron

Un login path est stocké dans le répertoire de l’utilisateur qui l’a créé. Donc si vous créez un profil avec votre utilisateur normal, puis lancez une commande avec sudo, MySQL peut chercher un autre fichier .mylogin.cnf.

Exemple à éviter si le profil n’existe pas pour root :

sudo mysqldump --login-path=prod nom_de_base > backup.sql

Dans ce cas, créez le login path pour l’utilisateur qui exécutera réellement la commande.

Pour une tâche cron, connectez-vous comme l’utilisateur prévu, puis créez le profil :

sudo -iu backup
mysql_config_editor set \
	--login-path=prod \
	--host=localhost \
	--user=backup_user \
	--passwordLangage du code : JavaScript (javascript)

Ensuite, testez la commande depuis ce même utilisateur :

mysql --login-path=prod -e "SELECT 1;"Langage du code : JavaScript (javascript)

Alternative : fichier ~/.my.cnf

Une autre méthode consiste à utiliser un fichier d’options MySQL classique, par exemple ~/.my.cnf.

[client]
user=backup_user
password=MotDePasse
host=localhost

Protégez ensuite le fichier :

chmod 600 ~/.my.cnf

Vous pouvez alors utiliser :

mysql nom_de_base
mysqldump nom_de_base > backup.sqlLangage du code : CSS (css)

Cette méthode fonctionne bien, notamment avec MariaDB ou des environnements où mysql_config_editor n’est pas disponible. En revanche, le mot de passe est stocké en clair dans le fichier. Il faut donc protéger strictement ses permissions.

mysql_config_editor ou ~/.my.cnf ?

Méthode	Avantage	Limite
mysql_config_editor	Mot de passe non écrit en clair dans un fichier texte	Fichier obfusqué, pas un coffre-fort absolu
~/.my.cnf	Simple, compatible avec beaucoup d’outils	Mot de passe en clair
-p sans mot de passe	Très sûr pour une commande ponctuelle	Pas adapté à l’automatisation
Variable d’environnement	Pratique en CI/CD	Peut fuiter selon les logs et l’environnement
Socket Unix + utilisateur local	Très propre pour certains accès locaux	Dépend de la configuration MySQL/MariaDB

Pour MySQL pur, utilisez de préférence mysql_config_editor. Pour MariaDB ou certains environnements d’hébergement, ~/.my.cnf reste souvent plus universel.

Et avec MariaDB ?

MariaDB et MySQL partagent beaucoup d’outils et de syntaxes, mais tout n’est pas identique. Selon votre distribution et votre version, mysql_config_editor peut ne pas être disponible, ou le client MariaDB peut ne pas gérer les login paths exactement comme le client MySQL.

Dans ce cas, utilisez plutôt un fichier ~/.my.cnf protégé :

[client]
user=backup_user
password=MotDePasse
host=localhost

Puis :

chmod 600 ~/.my.cnf

Ce n’est pas aussi élégant qu’un login path MySQL, mais c’est robuste et largement compatible.

Utiliser une variable d’environnement

On voit parfois cette méthode :

MYSQL_PWD='MotDePasse' mysql -u backup_user nom_de_baseLangage du code : JavaScript (javascript)

Elle évite l’avertissement lié à -pMotDePasse, mais elle n’est pas idéale. Une variable d’environnement peut être visible dans certains contextes, transmise à des processus enfants, ou fuiter dans des logs de CI/CD si le masquage est mal configuré.

Je la réserverais aux environnements temporaires ou CI/CD où les secrets sont injectés proprement par le gestionnaire de secrets de la plateforme. Pour un serveur classique, préférez mysql_config_editor ou ~/.my.cnf protégé.

Utiliser l’authentification par socket Unix

Sur certains serveurs Linux, l’utilisateur local peut se connecter à MySQL ou MariaDB via un socket Unix, sans mot de passe dans la commande. C’est courant pour l’utilisateur système root avec certains paquets MariaDB ou MySQL selon la distribution.

sudo mysql

Dans ce cas, l’authentification repose sur l’utilisateur système local et le socket, pas sur un mot de passe écrit dans la commande.

Pour des scripts de sauvegarde, on peut aussi créer un utilisateur système dédié et un utilisateur SQL avec des privilèges limités. C’est souvent plus propre qu’un script lancé en root avec un mot de passe administrateur.

Exemple propre pour une sauvegarde automatisée

Créez d’abord un utilisateur SQL limité à la sauvegarde. Exemple à adapter :

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'MotDePasseFort';
GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON nom_de_base.* TO 'backup_user'@'localhost';
FLUSH PRIVILEGES;Langage du code : JavaScript (javascript)

Ensuite, créez un login path pour l’utilisateur système qui exécutera la sauvegarde :

mysql_config_editor set \
	--login-path=backup-nomdusite \
	--host=localhost \
	--user=backup_user \
	--passwordLangage du code : JavaScript (javascript)

Testez :

mysql --login-path=backup-nomdusite -e "SHOW DATABASES;"Langage du code : JavaScript (javascript)

Puis utilisez mysqldump :

mysqldump \
	--login-path=backup-nomdusite \
	--single-transaction \
	--quick \
	--routines \
	--triggers \
	nom_de_base | gzip > nom_de_base-$(date +%F).sql.gzLangage du code : JavaScript (javascript)

Cette commande évite de mettre le mot de passe dans le script tout en gardant une sauvegarde exploitable. Pour une base WordPress InnoDB classique, --single-transaction évite de verrouiller inutilement les tables pendant le dump.

Exemple WordPress avec WP-CLI

Si vous travaillez sur un site WordPress, WP-CLI lit généralement les identifiants de base de données depuis wp-config.php. Vous n’avez donc pas besoin de passer le mot de passe MySQL dans la ligne de commande.

wp db query "SHOW TABLES;"Langage du code : JavaScript (javascript)

Pour exporter la base :

wp db export backup.sqlLangage du code : JavaScript (javascript)

Pour une sauvegarde compressée :

wp db export - | gzip > backup.sql.gzLangage du code : JavaScript (javascript)

C’est souvent la méthode la plus pratique pour WordPress, surtout si vous êtes déjà dans le répertoire du site et que WP-CLI est correctement configuré.

Nettoyer l’historique du shell si vous avez exposé un mot de passe

Si vous avez déjà tapé un mot de passe MySQL dans la ligne de commande, commencez par nettoyer l’historique du shell.

Avec Bash, affichez les lignes récentes :

history | tail -50

Supprimez la ligne concernée, en remplaçant 1234 par son numéro :

history -d 1234
history -w

Avec Zsh, l’historique se trouve généralement dans ~/.zsh_history. Vous pouvez l’éditer prudemment, puis recharger le shell.

Mais soyons clairs : si le mot de passe a pu être exposé dans des logs, un historique partagé ou un dépôt Git, le vrai correctif consiste à le changer.

Changer un mot de passe MySQL exposé

Si vous pensez qu’un mot de passe a fuité, changez-le. Exemple :

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

Mettez ensuite à jour le login path :

mysql_config_editor set \
	--login-path=backup-nomdusite \
	--host=localhost \
	--user=backup_user \
	--passwordLangage du code : JavaScript (javascript)

Ou mettez à jour le fichier ~/.my.cnf si vous utilisez cette méthode, puis vérifiez ses permissions :

chmod 600 ~/.my.cnf

Ce qu’il ne faut pas faire

• Ne mettez pas -pMotDePasse dans un script.
• Ne stockez pas un mot de passe MySQL dans un dépôt Git.
• Ne mettez pas le mot de passe dans une commande cron en clair.
• Ne collez pas une commande avec mot de passe dans un ticket support.
• Ne réutilisez pas le mot de passe root MySQL pour des sauvegardes.
• Ne donnez pas tous les privilèges SQL à un utilisateur de backup.
• Ne supposez pas que .mylogin.cnf est un coffre-fort inviolable.

Le bon objectif n’est pas seulement de faire disparaître l’avertissement. C’est d’éviter que le secret se balade dans les endroits où il n’a rien à faire.

Checklist de correction

• Remplacez -pMotDePasse par -p pour les commandes ponctuelles.
• Utilisez mysql_config_editor avec MySQL quand c’est disponible.
• Utilisez ~/.my.cnf protégé en 600 si nécessaire.
• Créez un utilisateur SQL avec des privilèges limités pour les scripts.
• Vérifiez quel utilisateur système exécute les scripts ou cron jobs.
• Évitez sudo si le login path existe seulement pour votre utilisateur.
• Nettoyez l’historique du shell si un mot de passe a été tapé en clair.
• Changez le mot de passe s’il a pu fuiter.
• Pour WordPress, privilégiez wp db export quand WP-CLI est disponible.

À retenir

• L’avertissement MySQL apparaît quand le mot de passe est passé directement sur la ligne de commande.
• La commande peut fonctionner tout en restant une mauvaise pratique.
• Pour une connexion ponctuelle, utilisez mysql -u utilisateur -p.
• Pour MySQL, mysql_config_editor permet de créer des login paths dans .mylogin.cnf.
• Pour MariaDB ou certains environnements, ~/.my.cnf protégé reste une solution simple.
• Pour WordPress, WP-CLI évite souvent d’avoir à manipuler directement le mot de passe SQL.
• Si un mot de passe a été exposé, nettoyez l’historique et changez-le.

En résumé, ne cherchez pas seulement à masquer l’avertissement Using a password on the command line interface can be insecure. Corrigez la méthode. Pour une commande ponctuelle, laissez MySQL demander le mot de passe. Pour un usage régulier ou automatisé, utilisez un login path, un fichier d’options protégé ou WP-CLI selon le contexte. Le terminal restera silencieux, et vos mots de passe resteront à leur place.

Sources

• MySQL Reference Manual — mysql_config_editor
• MySQL Reference Manual — Using Option Files
• MySQL Reference Manual — mysql Client Options
• MySQL Blog — Login path file and –no-login-paths
• WP-CLI Handbook — wp db export

Report a typo