MySQL : résoudre le message "Warning: Using a password on the command line interface can be insecure." photo

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

par · Lecture: 11 minutes

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.

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

Obtenir le statut de toutes les jails fail2ban photo

Fail2ban : afficher le statut de toutes les jails

par · Lecture: 8 minutes

Fail2ban est l’un des outils les plus pratiques pour protéger un serveur Linux contre les tentatives répétées d’authentification, les attaques par force brute et certains comportements abusifs dans les logs.

Il surveille des fichiers de logs, détecte des motifs suspects, puis bannit les adresses IP concernées via le pare-feu du système. Sur un serveur exposé à Internet, il devient vite indispensable pour SSH, Postfix, Dovecot, Nginx, Apache, WordPress, Plesk ou encore les services FTP.

Une fois Fail2ban configuré, il est utile de voir rapidement quelles jails sont actives, combien d’IP elles ont bannies, et si certaines jails ne détectent plus rien à cause d’un changement de chemin de log ou de backend.

La commande de base est simple :

sudo fail2ban-client status

Elle affiche le nombre de jails actives et leur liste. Pour obtenir le détail d’une jail précise, on utilise ensuite :

sudo fail2ban-client status sshd

Mais quand le serveur contient plusieurs jails, taper la commande à la main pour chacune devient vite pénible. Voici donc plusieurs méthodes propres pour afficher le statut de toutes les jails Fail2ban d’un coup.

Afficher la liste des jails Fail2ban actives

Commencez par vérifier que Fail2ban tourne correctement :

sudo systemctl status fail2ban --no-pager

Puis listez les jails actives :

sudo fail2ban-client status

Exemple de sortie :

Status
|- Number of jail:      4
`- Jail list:           dovecot, postfix, sasl, sshdLangage du code : JavaScript (javascript)

La documentation et les manpages de fail2ban-client indiquent que la commande status affiche l’état global du serveur Fail2ban, tandis que status <JAIL> affiche l’état d’une jail précise. Manpage Debian fail2ban-client.

Lire Fail2ban : afficher le statut de toutes les jails

Logo textuel bleu en minuscules indiquant "infomaniak" sur un fond gris clair. La police de caractères moderne et grasse reflète la fiabilité de l'hébergement Infomaniak, sans graphiques ou symboles supplémentaires autour du texte.

Installer WP-CLI sur un hébergement Infomaniak en SSH

par · Lecture: 6 minutes

WP-CLI transforme vite la gestion d’un site WordPress. Au lieu de cliquer partout dans l’administration, vous lancez une commande. Vous pouvez mettre à jour les extensions, vider les transients, vérifier l’état du site, régénérer les permaliens ou lancer un search-replace proprement.

Sur un hébergement Infomaniak, WP-CLI fonctionne très bien. Toutefois, il faut garder une chose en tête : vous êtes sur un hébergement Web avec accès SSH, pas sur un serveur root. Donc, on évite la méthode classique avec sudo mv wp-cli.phar /usr/local/bin/wp. À la place, on installe WP-CLI dans l’espace utilisateur, puis on ajoute ce dossier au PATH.

C’est plus propre, plus portable, et surtout compatible avec les limites normales d’un hébergement mutualisé. Bref, on fait les choses comme un admin civilisé. C’est rare, profitons-en.

Prérequis

Avant de commencer, vérifiez que vous avez :

  • un hébergement Web Infomaniak avec accès SSH ;
  • un site WordPress déjà installé ;
  • un compte FTP + SSH actif ;
  • un terminal local, ou la console SSH disponible dans le Manager Infomaniak.

Connectez-vous ensuite en SSH à votre hébergement. Une fois dans la session, commencez par vérifier la version de PHP utilisée en ligne de commande.

php -v

Cette étape compte, car WP-CLI s’exécute avec PHP en ligne de commande. Si la version CLI ne correspond pas à celle attendue par votre site WordPress, commencez par corriger ce point dans votre configuration Infomaniak.

Lire Installer WP-CLI sur un hébergement Infomaniak en SSH

Articles suivants →