Autoriser l'accès générique (%) sur la base de données MySQL, obtenir l'erreur «accès refusé pour« <utilisateur> »@« localhost »»


16

J'ai créé une base de données et un utilisateur, et j'ai autorisé l'accès via les éléments suivants:

create user 'someuser'@'%' identified by 'password';
grant all privileges on somedb.* to 'someuser' with grant option;

cependant, lorsque j'essaie de me connecter à MySQL, j'obtiens l'erreur suivante:

$ mysql -u someuser -p
> Enter Password:
> ERROR 1045 (28000): Access denied for user 'someuser'@'localhost' (using password: YES)

Si "%" est le caractère générique, cela n'activerait-il pas également localhost? Cependant, si je ne spécifie pas que je veux utiliser un mot de passe, je peux me connecter très bien à la base de données, ce qui n'a aucun sens car je spécifie un mot de passe lorsque j'ai créé l'utilisateur.

Réponses:


16

Essayez de vous connecter avec mysql -u someuser -p -h 127.0.0.1.

Si vous pouvez vous connecter sans mot de passe, soit vous avez enregistré les informations d'identification dans un fichier .my.cnf, soit vous avez créé un compte qui autorise l'accès sans mot de passe.


Ce commentaire de la documentation mysql peut également être lié.

http://dev.mysql.com/doc/refman/5.1/en/access-denied.html

Si vous ne pouvez pas comprendre pourquoi vous avez refusé l'accès, supprimez de la table utilisateur toutes les entrées qui ont des valeurs d'hôte contenant des caractères génériques (entrées qui contiennent des caractères '%' ou '_'). Une erreur très courante consiste à insérer une nouvelle entrée avec Host = '%' et User = 'some_user', pensant que cela vous permet de spécifier localhost pour se connecter à partir de la même machine. La raison pour laquelle cela ne fonctionne pas est que les privilèges par défaut incluent une entrée avec Host = 'localhost' et User = ''. Étant donné que cette entrée a une valeur d'hôte «localhost» qui est plus spécifique que «%», elle est utilisée de préférence à la nouvelle entrée lors de la connexion à partir de localhost! La procédure correcte consiste à insérer une deuxième entrée avec Host = 'localhost' et User = 'some_user',


+1, y compris la définition de l'hôte et la référence ~ / .my.cnf
Andy

7

Je suis sûr que vous avez besoin des éléments suivants:

accorder tous les privilèges sur somedb. * à 'someuser' @ '%' avec l'option d'octroi;

Votre déclaration GRANT n'a pas de déclaration de nom d'hôte.


Un emplacement doit être spécifié:GRANT ALL ON somedb.* TO 'someuser'@'10.1.10.1';
mardi

6

Si vous ne parvenez pas à vous connecter à mysql en utilisant someuser @ '%' où '%' est le caractère générique pour le nom d'hôte, alors assurez-vous que vous n'avez pas d'entrée '' @localhost dans votre table utilisateur. Confirmez en utilisant l'instruction SQL suivante:

    mysql> SELECT * FROM user WHERE user='' AND host='localhost';

Si '' @localhost existe, supprimez-le en émettant l'instruction SQL suivante:

    mysql> DELETE FROM user WHERE user='' AND host='localhost';

puis enfin

    FLUSH PRIVILEGES;

Someuser @ '%' va maintenant se connecter à la base de données.


L'octroi de privilèges «nom d'utilisateur» @ «localhost» n'entraînera pas le non-fonctionnement des octrois sur le même utilisateur à partir d'un emplacement différent.
mardi

en quoi est-ce pertinent? Qu'est-ce que l'utilisateur '' chez 'localhost' cause?
Steve Buzonas

1
@SteveBuzonas C'est absolument pertinent. Il fournit un exemple de code pour la réponse publiée par Zoredache. Localhost est plus spécifique que '%', donc si vous essayez de vous connecter via localhost avec un utilisateur qui n'a accès qu'à '%', l'entrée localhost est plus spécifique, donc mysql tente de se connecter à localhost, mais attend un nom d'utilisateur vide et mot de passe vide. Étant donné que ce ne sont pas les informations d'identification fournies, vous obtenez l'erreur d'accès refusé. En supprimant ces entrées, il permet aux utilisateurs d'accéder à «%».
bstakes

@bstakes le comportement par défaut du client mysql est d'utiliser votre nom d'utilisateur shell si vous n'en spécifiez pas un. la question a un utilisateur dans l'exemple et dans le message d'erreur. j'étais curieux de voir comment un utilisateur '' entrerait en conflit avec un utilisateur nommé. '' est un caractère générique?
Steve Buzonas

@SteveBuzonas '' fonctionne comme un caractère générique par rapport à localhost. À partir des documents MySQL et indiqué dans une réponse ci-dessus faisant référence à la valeur par défaut que vous avez mentionnée: "Parce que cette entrée a une valeur d'hôte 'localhost' qui est plus spécifique que '%', elle est utilisée de préférence à la nouvelle entrée lors de la connexion à partir de localhost ! La procédure correcte consiste à insérer une deuxième entrée avec Host = 'localhost' et User = 'some_user', ou à supprimer l'entrée avec Host = 'localhost' et User = ''. "
bstakes

4

Ma compréhension, et je suis prêt à être corrigé à ce sujet, est que MySQL traite localhost séparément à%. c'est-à-dire que localhost n'est pas inclus dans le caractère générique.


Les exemples fournis dans dev.mysql.com/doc/refman/5.1/en/connection-access.html me portent à croire que cela peut ne pas être exact. Avez-vous des références autrement?
Warner

Ma compréhension de ce problème est basée sur d'autres signalant le même problème, à la fois sur papier et verbalement, et le résolvant en créant 2 utilisateurs, en utilisant "%" et "localhost". Cependant, je ne me souviens pas l'avoir vu officiellement documenté.
John Gardeniers

1
Cela semble être correct sur Ubuntu 12.04 LTS au moins
Dex

Ce qui m'est arrivé, c'est que je l'avais fait user@%et cela n'a pas fonctionné jusqu'à ce que j'inclue user@localhost. Ensuite, j'ai vu la réponse stackoverflow.com/a/29421084/4850646 et j'ai réalisé que j'avais un utilisateur anonyme avec host localhost. J'ai supprimé tous les utilisateurs anonymes et j'ai pu y accéder localhostpour cet utilisateur, même après avoir supprimé user@localhost (et laissé uniquement user@%). Il semble que parce qu'il localhostest plus spécifique que %, il essaie d'abord l' localhostutilisateur, même s'il s'agit d'un utilisateur anonyme!
Lucas Basquerotto

0

Avez-vous exécuté flush privileges;après avoir créé l'utilisateur? Si vous ne le faites pas, les modifications apportées aux utilisateurs / autorisations ne prendront qu'après le redémarrage du serveur.

Ensuite, vérifiez que vous n'avez pas d'entrée '%' @ 'localhost'.


4
l'utilisation de «créer un utilisateur» et «accorder» vide automatiquement les privilèges. Vous ne devriez avoir besoin de vider les privilèges que si vous manipulez directement la base de données mysql.
Zoredache
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.