Permitir el acceso comodín (%) en MySQL db, obteniendo el error "acceso denegado para '<usuario>' @ 'localhost'"

16

Creé una base de datos y un usuario, y permití el acceso a través de lo siguiente:

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

sin embargo, cuando intento conectarme a MySQL me sale el siguiente error:

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

Si "%" es el comodín, ¿no habilitaría también localhost? Sin embargo, si no especifico que quiero usar una contraseña, entonces puedo conectarme bien a la base de datos, lo cual no tiene sentido porque estoy especificando una contraseña cuando creé el usuario.

mysql

— Wayne Molina
fuente

16

Intenta conectarte con mysql -u someuser -p -h 127.0.0.1.

Si puede conectarse sin una contraseña, ha guardado las credenciales en un archivo .my.cnf o ha creado una cuenta que permite el acceso sin contraseña.

Este comentario de los documentos de mysql también puede estar relacionado.

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

Si no puede entender por qué se le niega el acceso, elimine de la tabla de usuario todas las entradas que tengan valores de Host que contengan comodines (entradas que contengan caracteres '%' o '_'). Un error muy común es insertar una nueva entrada con Host = '%' y User = 'some_user', pensando que esto le permite especificar localhost para conectarse desde la misma máquina. La razón por la que esto no funciona es que los privilegios predeterminados incluyen una entrada con Host = 'localhost' y User = ''. Debido a que esa entrada tiene un valor de Host 'localhost' que es más específico que '%', se usa con preferencia a la nueva entrada cuando se conecta desde localhost. El procedimiento correcto es insertar una segunda entrada con Host = 'localhost' y User = 'some_user',

— Zoredache
fuente

+1 incluyendo definición de host y referencia ~ / .my.cnf

— Andy

7

Estoy bastante seguro de que necesitas lo siguiente:

otorgue todos los privilegios en somedb. * a 'someuser' @ '%' con la opción de concesión;

Su declaración GRANT carece de una declaración de nombre de host.

— Mono asinine
fuente

Se debe especificar una ubicación:GRANT ALL ON somedb.* TO 'someuser'@'10.1.10.1';

— tacotuesday

6

Si no puede conectarse a mysql usando someuser @ '%' donde '%' es el comodín para el nombre de host, asegúrese de no tener la entrada '' @localhost en su tabla de usuario. Confirme con la siguiente instrucción SQL:

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

Si '' @localhost existe, elimínelo emitiendo la siguiente instrucción SQL:

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

entonces por último

    FLUSH PRIVILEGES;

Ahora someuser @ '%' se conectará a la base de datos.

— Alphonse Ogulla
fuente

Otorgar privilegios de 'nombre de usuario' @ 'localhost' no hará que las concesiones en el mismo usuario desde una ubicación diferente no funcionen.

— Tacotuesday

¿Cómo es esto relevante? ¿Qué causa el usuario '' en 'localhost'?

— Steve Buzonas

1

@SteveBuzonas Esto es absolutamente relevante. Proporciona un ejemplo de código para la respuesta que publicó Zoredache. Localhost es más específico que '%', por lo que si intenta conectarse a través de localhost con un usuario que solo tiene acceso en '%', la entrada localhost es más específica, por lo que mysql intenta iniciar sesión en localhost, pero espera un nombre de usuario vacío y contraseña vacía Como esas no son las credenciales proporcionadas, obtiene el error de acceso denegado. Al eliminar estas entradas, permite el acceso de los usuarios a '%'.

— bstakes

@bstakes el comportamiento predeterminado del cliente mysql es usar su nombre de usuario de shell si no especifica uno. la pregunta tiene un usuario en el ejemplo y en el mensaje de error. Tenía curiosidad de cómo un '' usuario entraría en conflicto con un usuario nombrado. es "un comodín?

— Steve Buzonas

@SteveBuzonas '' funciona como un comodín con respecto al localhost. De los documentos de MySQL y se muestra en una respuesta anterior que hace referencia al valor predeterminado que mencionó: "Debido a que esa entrada tiene un valor de Host 'localhost' que es más específico que '%', se usa con preferencia a la nueva entrada cuando se conecta desde localhost ! El procedimiento correcto es insertar una segunda entrada con Host = 'localhost' y User = 'some_user', o eliminar la entrada con Host = 'localhost' y User = '' ".

— bstakes

4

Mi comprensión, y estoy preparado para ser corregido en esto, es que MySQL trata localhost por separado a%. es decir, localhost no está incluido en el comodín.

— John Gardeniers
fuente

Los ejemplos proporcionados en dev.mysql.com/doc/refman/5.1/en/connection-access.html me hacen creer que esto puede no ser exacto. ¿Tienes referencias de lo contrario?

— Warner

Mi comprensión de este asunto se basa en que otros informan el mismo problema, tanto en forma impresa como verbal, y lo resuelven creando 2 usuarios, usando "%" y "localhost". Sin embargo, no recuerdo haberlo visto documentado oficialmente.

— John Gardeniers

1

Esto parece ser correcto en Ubuntu 12.04 LTS al menos

— Dex

Lo que me sucedió es que tenía user@%y no funcionó hasta que lo incluí user@localhost. Luego vi la respuesta stackoverflow.com/a/29421084/4850646 y me di cuenta de que tenía un usuario anónimo con host localhost. Eliminé todos los usuarios anónimos y pude acceder desde localhostese usuario, incluso después de eliminar user@localhost (y dejar solo user@%). Parece que debido a que localhostes más específico que %, primero trata al localhostusuario, ¡ incluso si es un usuario anónimo!

— Lucas Basquerotto

0

¿Has corrido flush privileges;después de crear el usuario? Si no lo hace, los cambios en los usuarios / permisos no se realizarán hasta después de reiniciar el servidor.

Luego, verifique que no tenga una entrada '%' @ 'localhost'.

— cáliz
fuente

44

usando 'crear usuario' y 'otorgar' automáticamente elimina los privilegios. Solo debería necesitar eliminar los privilegios si está manipulando directamente la base de datos mysql.

— Zoredache