Noticias 

Comprobación de la conexión Mysql

Cuando intente conectar a un servidor MySQL, el servidor aceptará o rechazará la conexión basándose en su identidad y si usted puede identificar su identidad proporcionando la clave correcta. Si no es así, el servidor le denegará el acceso completamente. En caso contrario, el servidor acepta la conexión, y entra en el Estado 2, y espera peticiones.
Su identidad se basa en dos elementos de información:
  • El nombre de máquina cliente (o ip) desde donde usted se conecta
  • Su nombre de usuario MySQL
La comprobación de la identidad se realiza utilizando las tres columnas de la tabla user (Host, User, yPassword). El servidor sólo acepta la conexión si las columnas Host y User de alguna de las tablas user es coincidente con el nombre de máquina y usuario del cliente, y además el cliente proporciona la clave especificada en ese registro.
Los valores de Host en la tabla user pueden ser especificados de las siguientes maneras:
  • Un valor de Host debe ser un nombre de máquina o un número IP, o ‘localhost’ para indicar la máquina local.

  • Puede utilizar los caracteres comodín ‘%’ y ‘_’ en los valores de las columnas Host. Estos tienen el mismo significado que en las operaciones de búsqueda de patrones realizadas mediante el operador LIKE. Por ejemplo, un valor de Host igual a ‘%’ retorna cualquier nombre de máquina, así como un valor de ‘%.mysql.com’retorna cualquier nombre de máquina en el dominio mysql.com.

  • Para valores de Host especificados como números IP, puede especificar una máscara de red indicando cuantos bits de la dirección utilizar para el número de red. Por ejemplo:
    mysql> GRANT ALL PRIVILEGES ON db.*
    -> TO david@'192.58.197.0/255.255.255.0';
    Esto permite a david conectarse desde cualquier cliente que tenga un número IP client_ip para el que la siguiente condición sea cierta:
    client_ip & netmask = host_ip
    
    Es decir, para la sentencia GRANT recientemente mostrada: That is, for the GRANT statement just shown:
    client_ip & 255.255.255.0 = 192.58.197.0
    
    Los números IP que satisfagan esta condición y pueden conectar al servidor MySQL son lo que están en el rango desde 192.58.197.0 hasta 192.58.197.255.
  • Nota: La máscara de red solo puede ser utilizada para decirle al servidor que use 8, 16, 24 o 32 bits para la dirección, por ejemplo:
    192.0.0.0/255.0.0.0 (cualquier dirección de la red clase A 192)
    192.168.0.0/255.255.0.0 (cualquier dirección de la red clase B 192.168)
    192.168.1.0/255.255.255.0 (cualquier dirección de la red clase C 192.168.1)
    192.168.1.1 (solo esta IP específica)
    La siguiente máscara de red (28 bits) no funcionará:
    192.168.0.1/255.255.255.240
  • Un valor vacío de Host en un registro de la tabla db significa que los privilegios de dicho registro deben ser combinados con aquellos que se encuentren en el registro de la tabla host que concuerde con el nombre del cliente. Los privilegios se combinan utilizando operaciones AND (intersección), no OR (union). Puede encontrar más información sobre la tabla host en Sección 5.6.6, “Control de acceso, nivel 2: comprobación de solicitudes”.
    Un valor de Host en blanco en las otras tablas grant lo mismo que ‘%’.
Debido a que puede usar comodines en los valores IP de la columna Host (por ejemplo, ‘144.155.166.%’ para conseguir cualquier IP en una subred), alguien podría intentar explotar esta capacidad poniéndole a su cliente el nombre 144.155.166.cualquierhost.com. Para evitar estos intentos, MySQL no permite que los comodines sean utilizados para los nombres de cliente que empiezan con dígitos y un punto. Así que si tiene un cliente con nombre similar a 1.2.cualquierhost.com, su nombre nunca concordará con la columna Host de las tablas grant. Un comodín de IP solo puede concordar con números IP, no nombres de cliente.
En la columna User, los caracteres comodín no están permitidos, pero puede especificar un valor en blanco, que será válido para cualquier nombre. Si el registro de la tabla user que concuerda con una conexión entrante tiene un valor vacio, el usuario es considerado anónimo, sin nombre de usuario, no un usuario con el nombre que el cliente especificó realmente. Esto significa que el nombre de usuario vacío es utilizado para todas las comprobaciones de acceso posteriores durante la duración de la conexión (es decir, durante el Estado 2).
La columna Password puede estar vacía. Esto no es un comodín que permite que cualquier clave sea permitida. Significa que el usuario debe conectarse sin especificar una clave.
Los valores que no están vacíos de Password en la tabla user representan claves cifradas. MySQL no almacena las claves en forma de texto llano para que cualquiera pueda verlo. En vez de esto, la clave suministrada por un usuario que se está intentando conetar es cifrada (utilizando la función PASSWORD()). La clave cifrada se utiliza entonces durante el proceso de conexión en el momento de comprobar si es correcta. (Esto se realiza sin que la clave cifrada viaje nunca sobre la conexión.) Desde el punto de vista de MySQL, la clave cifrada es la clave REAL, así que no debería darse acceso a ella a nadie. En concreto, no de acceso de lectura a las tablas de la base de datos mysql a usuarios no-administrativos.
MySQL 5.0 utiliza el método de autenticación más fuerte (implementado primeramente en MySQL 4.1) y que tiene una mejor protección de la clave durante el proceso de conexión que versiones previas. Es seguro aún cuando los paquetes TCP/IP fuesen interceptados o la base de datos mysql capturada. El cifrado de claves es comentado en mayor profundida en Sección 5.6.9, “Hashing de contraseñas en MySQL 4.1”.
Los siguientes ejemplos nos enseñan como se aplicarían a las conexiones entrantes diferentes combinaciones de los valores de las columnas Host y User de la tabla user.
Cliente Valor UsuarioValor Conexiones que concuerdan con la entrada Entry
‘thomas.loc.gov’ ‘fred’ fred, conectando desde thomas.loc.gov
‘thomas.loc.gov’ Cualquier usuario, conectando desde thomas.loc.gov
‘%’ ‘fred’ fred, conectando desde cualquier cliente
‘%’ Cualquier usuario conectando desde cualquier cliente
‘%.loc.gov’ ‘fred’ fred, conectando desde cualquier cliente en el dominioloc.gov
‘x.y.%’ ‘fred’ fred, conectando desde x.y.net, x.y.com, x.y.edu, etc. (esto, probablemente, no es útil)
‘144.155.166.177’ ‘fred’ fred, conectando desde el cliente con dirección IP144.155.166.177
‘144.155.166.%’ ‘fred’ fred, conectando desde cualquier cliente en la subred de clase C 144.155.166
‘144.155.166.0/255.255.255.0’ ‘fred’ Idéntico al ejemplo anterior
Es posible que el nobre del cliente y del usuario de una conexión entrante concuerde con más de un registro en la tabla user. El conjunto de ejemplos precedentes demuestra esto: Algunas de las entradas mostradas concuerdan con una conexión de fred desde thomas.loc.gov.
Cuando hay la posibilidad de múltiples concordancias, el servidor debe determinar cual de ellas utilizar. El problema se resuelve de la siguiente manera:
  • Siempre que el servidor lee la tabla user a memoria, ordena los registros.
  • Cuando un cliente intenta conectar, el servidor mira a través de los registros en el orden establecido.
  • El servidor utiliza el primer registro que concuerda con el nombre y usuario del cliente.
Para ver como esto ocurre, supongamos que la tabla user es como esta:
+-----------+----------+-
| Host | User | …
+-----------+----------+-
| % | jeffrey |
| % | root | …… | localhost | root | …
---------+----------+-
| localhost | | … +-
-
Cuando el servidor lee la tabla, ordena las entradas con los valores de Host más específicos primero. Los nombres de cliente y números de IP son los más específicos. El comodín ‘%’ significa “cualquier cliente” y es menos específico. Registros con el mismo valor de Host se ordenan con el valor de User más específico (un valor de User en blanco significa “cualquier usuario” y es menos específico). En la tabla user recién mostrada, el resultado después de ordenar sería el siguiente:
+-----------+----------+-
| Host | User | …
+-----------+----------+-
... | localhost | |
| localhost | root | …… ... | % | jeffrey | … ...
-----+----------+-
| % | root | … ... +-----
-
Cuando un cliente intenta conectar, el servidor mira los registros ordenados y utiliza la primera concordancia. Para una conexión desde localhost por jeffrey, dos de las entradas de la tabla concuerdan: la primera con los valores ‘localhost’ y ” de Host y User respectivamente, y el registro con los valores ‘%’ y ‘jeffrey’. El registro con valor ‘localhost’ aparece primero en la tabla ordenada, así que es el que el servidor utiliza.
Aquí hay otro ejemplo. Supongamos que la tabla user tiene el siguiente aspecto:
+----------------+----------+-
| Host | User | …
+----------------+----------+-
| thomas.loc.gov | |
| % | jeffrey | ……
--------------+----------+-
+- -
La tabla ordenada sería:
+----------------+----------+-
| Host | User | …
+----------------+----------+-
| % | jeffrey |
| thomas.loc.gov | | ……
--------------+----------+-
+- -
Una conexión de jeffrey desde thomas.loc.gov concuerda con el primer registro, mientras que una conexión de jeffrey desde whitehouse.gov concuerda con el segundo.
Es una confusión común el pensar que, para un nombre de usuario dado, todos los registros que nombran explícitamente con a ese usuario son utilizadas primero cuando el servidor intenta encontrar una concordancia para una conexión. Esto es sencillamente falso. El ejemplo anterior ilustra esto, donde una conexión de jeffreydesde thomas.loc.gov no concuerda primero con el registro que contiene ‘jeffrey’ como valor en la columnaUser, sino que ha concordado con el registro que no contiene nombre de usuario. Como resultado, jeffrey es tratado como un usuario anónimo aunque ha especificado un nombre de usuario al conectarse.
Si puede conectar al servidor, pero sus privilegios no son los que espera, probablemente está siendo identificado como algún otro usuario. Para averiguar qué cuenta de usuario utilizó el servidor para identificarle, use la funciónCURRENT_USER(). Devuelve un valor en formato user_name@host_name que indica los valores de User y Hostdel registro concordante en la tabla user. Suponga que jeffrey conecta y ejecuta la siguiente sentencia:
mysql> SELECT CURRENT_USER();
+----------------+
+----------------+
| CURRENT_USER() | | @localhost |
+----------------+
El resultado mostrado indica que el registro que concuerda en la tabla user tiene un valor vacío en la columnaUser. En otras palabras, el servidor trata a jeffrey como a un usuario anónimo.

Otra cosa que puede hacer para localizar problemas de autentificación es imprimir por pantalla la tabla user y ordenarla a mano para ver donde está la primera concordancia. Consulte Sección 12.9.3, “Funciones de información”.
Fuente:enlace

Related posts