Je viens d'installer Ubuntu 16.04 LTS avec les paquets php
, mariadb
et nginx
. J'ai couru mysql_secure_installation
et changé le mot de passe root.
Maintenant, lorsque j'essaie de me connecter à mysql
en utilisant le compte root en étant connecté à Ubuntu en tant que compte d'utilisateur normal, l'accès est refusé.
Lorsque je me connecte avec Sudo mysql
, mysql ne me demande même pas de mot de passe. Si je lance mysql_secure_installtion
, je constate que les anciens paramètres ne sont jamais définis de manière permanente.
Qu'est-ce que je fais mal?
J'ai récemment mis à jour mon Ubuntu 15.04 à 16.04 et cela a fonctionné pour moi:
Tout d'abord, connectez-vous dans Sudo mysql
Sudo mysql -u root
Vérifiez vos comptes présents dans votre base de données
SELECT User,Host FROM mysql.user;
+------------------+-----------+
| User | Host |
+------------------+-----------+
| admin | localhost |
| debian-sys-maint | localhost |
| magento_user | localhost |
| mysql.sys | localhost |
| root | localhost |
Supprimer le compte root @ localhost actuel
mysql> DROP USER 'root'@'localhost';
Query OK, 0 rows affected (0,00 sec)
Recréez votre utilisateur
mysql> CREATE USER 'root'@'%' IDENTIFIED BY '';
Query OK, 0 rows affected (0,00 sec)
Donnez des autorisations à votre utilisateur (n'oubliez pas de supprimer les privilèges)
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
Query OK, 0 rows affected (0,00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0,01 sec)
Quittez MySQL et essayez de vous reconnecter sans Sudo.
J'espère que cela aidera quelqu'un :)
Si vous installez 5.7 sans fournir de mot de passe à l'utilisateur
root
name__, il utilisera le pluginauth_socket
. Ce plugin ne s’inquiète pas et n’a pas besoin de mot de passe. Il vérifie simplement si l'utilisateur se connecte à l'aide d'un socket UNIX, puis compare le nom d'utilisateur.
Extrait de Changer le mot de passe de l'utilisateur dans MySQL 5.7 avec "plugin: auth_socket"
Donc, pour changer le plugin
à mysql_native_password
:
Se connecter avec Sudo:
Sudo mysql -u root
Changez le plugin
et définissez un mot de passe avec une seule commande:
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'test';
Bien sûr, vous pouvez également utiliser la commande ci-dessus pour définir un mot de passe vide.
Pour mémoire, et pour les utilisateurs de MariaDB < 10.2
, il existe un autre moyen de modifier uniquement le plugin
sans fournir de mot de passe (en le laissant vide):
update mysql.user set plugin = 'mysql_native_password' where User='root';
// to change the password too (credits goes to Pothi Kalimuthu)
// UPDATE mysql.user SET plugin = 'mysql_native_password', Password = PASSWORD('secret') WHERE User = 'root';
FLUSH PRIVILEGES;
En bref, sur MariaDB
UPDATE mysql.user SET plugin = 'mysql_native_password',
Password = PASSWORD('NEWPASSWORD') WHERE User = 'root';
où vous remplacez NEWPASSWORD par le mot de passe que vous voulez et tout le reste mot pour mot.
Le problème ici est que, lorsque MariaDB ou MySQL sont installés/mis à jour (en particulier si, à un moment donné, root est défini sans mot de passe), dans le tableau Utilisateurs, le mot de passe est réellement vide (ou ignoré) et la connexion dépend de l'utilisateur système correspondant. à un utilisateur MySQL. Vous pouvez le tester comme suit en basculant sur la racine du système, puis en tapant:
mysql -uroot -p
Ensuite, entrez soit pas de mot de passe, soit le mot de passe incorrect . Vous serez probablement laissé entrer (vous pourrez même vous connecter à partir de la racine unix simplement par # mysql
car le mot de passe n’est pas pertinent et que l’utilisateur est défini).
Alors que se passe-t-il? Eh bien, si vous vous connectez en tant que root et procédez comme suit:
select User,Host,plugin from mysql.user;
+----------------+-----------+-----------------------+
| User | Host | plugin |
+----------------+-----------+-----------------------+
| root | localhost | auth_socket |
+----------------+-----------+-----------------------+
vous noterez auth_socket
(qui peut lire unix_socket
sur MariaDB). Ces sockets ignorent les mots de passe et autorisent l’utilisateur Unix correspondant à sans vérifier le mot de passe. C'est pourquoi vous pouvez vous connecter avec root mais pas avec un autre utilisateur.
La solution consiste donc à mettre à jour les utilisateurs pour qu'ils n'utilisent pas le auth_socket/unix_socket
et ne définissent pas correctement un mot de passe.
Sur MariaDB (<10.2, voir les commentaires ci-dessous) qui est sur la version 16 d'Ubuntu à partir de 2017, cela devrait suffire. NEWPASSWORD est votre mot de passe. mysql_native_password
vous tapez textuellement.
UPDATE mysql.user SET plugin = 'mysql_native_password', Password = PASSWORD('NEWPASSWORD') WHERE User = 'root';
(Il est possible que régler le plug-in sur vide fonctionne. YMMV. Je n'ai pas essayé cela. C'est donc une alternative.)
UPDATE mysql.user SET plugin = '', Password = PASSWORD('NEWPASSWORD') WHERE User = 'root';
Autrement:
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'NEWPASSWORD';
Ensuite
FLUSH PRIVILEGES;
Pour mémoire, la solution consistant à supprimer l'utilisateur et à le recréer avec '%' m'a totalement bloquée en dehors de la base de données et peut causer d'autres problèmes à moins que vous obteniez l'instruction grant
correctement - il est plus facile de mettre à jour la racine que vous avez déjà.
D'après mon expérience, le problème ne concerne que l'utilisateur racine, car d'autres utilisateurs seront ajoutés manuellement, mais ne feront pas partie d'une installation/mise à jour initiale.
Si vous avez installé MySQL/MariaDB à partir du référentiel de base, les utilisateurs ne peuvent pas se connecter à MySQL en tant qu'utilisateur root MySQL à partir de leurs connexions Unix (non applicable s'ils ont Sudo accès)
Connectez-vous à MySQL root Shell:
$ Sudo mysql -u root -p
Exécuter les requêtes ci-dessous:
use mysql;
update user set plugin='mysql_native_password' where user='root';
flush privileges;
quit;
Ouvrez un nouveau shell, puis:
$ mysql -u root -p
Essayez de créer un nouveau compte mysql, cela a fonctionné pour moi (mysql 5.7.12):
Se connecter en tant que Sudo:
Sudo mysql -uroot
Créez un nouvel utilisateur et accordez-lui des privilèges (pas de mot de passe):
CREATE USER 'admin'@'localhost' IDENTIFIED BY '';
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost';
Se connecter en tant que nouvel utilisateur:
mysql -uadmin
Je devais faire deux choses (grâce à @Todor et @Loremhipsum):
update mysql.user set plugin = 'mysql_native_password' where User='root';
grant all privileges on *.* to 'root'@'localhost';
et alors:
FLUSH PRIVILEGES;
Je ne recommanderais pas d'abandonner l'utilisateur root
.
Essayez d'abord ce code,
echo "CREATE USER 'root'@'localhost' IDENTIFIED BY 'root';" > your_init_file.sql
echo "GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;" >> your_init_file.sql
echo "FLUSH PRIVILEGES;" >> your_init_file.sql
et alors,
killall mysqld
mysqld_safe --init-file=$PWD/your_init_file.sql
puis appuyez sur Ctrl+Z
et tapez: bg
pour exécuter le processus du premier plan à l'arrière-plan, puis vérifiez votre accès en:
mysql -u root -proot
mysql> show grants;
Si vous n'exécutez que la commande mysql sous l'utilisateur root, l'accès vous sera accordé sans mot de passe, car l'authentification de socket est activée pour root @ localhost. .
Le seul moyen de définir un mot de passe consiste à basculer vers une authentification native telle que:
$ Sudo mysql
mysql> ALTER USER 'racine' @ 'localhost' IDENTIFIÉ AVEC mysql_native_password BY 'test';
J’ai adapté certains scripts de provisionnement que j’ai créés pour utiliser MariaDB et je me suis heurté à ce problème. Rassembler beaucoup d’informations ici un réponse de Gazzer vraiment zéro dans le numéro; tout se résume au paramètre auth_socket
/unix_socket
.
Ainsi, lorsque vous utilisez MariaDB 5.5 (sous Ubuntu 14.04) et MariaDB 10 sous (Ubuntu 16.04), vous connecter à MySQL et exécuter cette commande a tout effacé:
UPDATE mysql.user SET plugin='' WHERE User='root';
FLUSH PRIVILEGES;
Les autres réponses, y compris la réponse la plus votée par Loremhipsum dans ce billet - encouragent réellement les mauvaises pratiques en recommandant de supprimer un utilisateur, puis de les recréer. Pour moi, c'est une solution assez radicale. La meilleure solution/la plus simple consiste à annuler la valeur plugin
, à supprimer les privilèges et à poursuivre la vie.