error - Conexión MySQL sobre túnel SSH

workbench server public key has changed (6)

Acabo de encontrar este mismo problema.

En mi caso, el servidor MySQL está configurado con bind-address: 192.168.4.4 . Originalmente configuré un túnel SSH con una cadena de -L 3306:localhost:3306 user@server comúnmente mencionada y desde mi computadora me conecto con mysql -h 127.0.0.1 .

Esto no funciona porque MySQL ya no escucha en 0.0.0.0 o incluso "localhost" (también conocido como 127.0.0.1), solo 192.168.4.4 .

La cadena de túnel correcta debe ser -L 3306:192.168.4.4:3306 user@server . Esto le dirá al extremo remoto del túnel que se conecte a MySQL usando el IP MySQL que realmente escucha.

He configurado un túnel SSH entre dos servidores A y B. B tiene un servidor MySQL, y esto funciona:

mysql -h localhost -P 3306 -u user -p

Si bien esto no:

mysql -h 127.0.0.1 -P 3306 -u user -p

Aunque my.cnf tiene estas líneas:

bind-address = 127.0.0.1 # Next addr differs slightly, but anyway bind-address = 99.99.99.99

Ahora sobre el túnel. Conecta lo siguiente: (A) localhost(9989) -> (B) localhost(3306) Pero cuando (en A , con puertos reenviados) lo hago

mysql -v -h 127.0.0.1 -P 9989 -u user userdb -p

Me sale ERROR 2013 (HY000): Lost connection to MySQL server at ''reading initial communication packet'', system error: 0

Y cuando lo hago

mysql -v -h localhost -P 9989 -u user userdb -p

Me sale ERROR 1045 (28000): Access denied for user ''user''@''localhost'' (using password: YES)

¿Cuál podría ser la razón? ¿Qué estoy haciendo mal?

En mi caso, una configuración en el daemon SSH estaba bloqueando el túnel. AllowTcpForwarding debe estar habilitado.

AllowTcpForwarding yes

Hay tres problemas aquí.

1 - Olvídate del túnel SSH por ahora

No puede vincular MySQL a más de una IP específica. La primera cláusula bind-address se reemplaza (por lo tanto, se ignora) por la segunda. Su servidor solo escucha 99.99.99.99 .

La razón por la que puede conectarse con -h localhost pero no con -h 127.0.0.1 es que en la primera forma, no se conecta a través de TCP / IP, sino a través de un socket local.

Busca en tu my.cnf una cláusula socket .

Eliminar una cláusula redundante bind-address vinculación. Es posible que desee utilizar bind-address=0.0.0.0 , que instruye al daemon de MySQL para que escuche todas las interfaces de red.

2 - Vamos a configurar tu túnel SSH

El motivo de su error ERROR 2013 (HY000): Lost connection to MySQL server at ''reading initial communication packet'', system error: 0 no es obvio para mí. Sospecho que el túnel SSH se establece realmente solo cuando recibe una solicitud de conexión (en su caso, cuando ejecuta el cliente mysql ). Como su servidor no escucha 127.0.0.1 (vea el párrafo anterior), el túnel SSH no puede establecerse, la conexión falla y su cliente lo interpreta como una falla de red.

3 - Por qué mysql -v -h localhost -P 9989 -u user userdb -p falla

Por favor, publique la salida de

[Editar: acaba de agregar ...OR host LIKE ''localhost'' continuación, ya que esto podría ser relevante para la resolución de problemas]

mysql > SELECT user, host FROM mysql.user WHERE user LIKE ''user'' OR host LIKE ''localhost'';

(reemplace ''user'' , después de la cláusula LIKE , con el nombre de usuario real si es necesario)

El control de acceso de MySQL comprueba tanto el nombre de usuario / contraseña ( user ) como el origen de la conexión ( host ) para identificar a un usuario. Probablemente no haya creado un usuario ''user''@''localhost'' .

NB: mysql.com es inalcanzable desde mi ubicación en este momento, no puedo enlazar a las páginas de manual relevantes.

TUNELAMIENTO SSH PASO A PASO

--- LADO DEL SERVIDOR ----

en la máquina de destino (que puede ser direccionada por IP o un dominio alojado) hay un archivo de configuración /etc/mysql/my.cnf que tiene una línea

bind-address = 127.0.0.1

confirmado con consola

netstat -tapn | grep mysql // tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 18469/mysqld

lo que significa que el servidor mysql responderá solo a la solicitud del localhost

--- LADO DEL CLIENTE ----

usted tiene una cuenta (eventualmente una ssh-key) para iniciar sesión usando cygwin, putty o linux_shell

ssh user_name@host_name

crear SSH TUNNEL

ssh -f -N -L 1000:127.0.0.1:3306 user_name@host_name

lo que significa que hey ssh crea una conexión permanente desde el puerto 1000 en la máquina que escribo (cliente) a host_name remoto: 3306 .... 127.0.0.1 significa aquí el control remoto (host_name) y no debe ser reemplazado con localhost word porque esto hacer la conexión en unix (named) socket no por IP ... Obtendrá ''ERROR 2002 (HY000): No se puede conectar al servidor MySQL local a través del socket'' /var/run/mysql.sock ''(2)'' al intentar co conectar mysql

-f = entrar en segundo plano -N = no ejecución

tanto -f -N tipo de nohoop- puedes cerrar la consola y los túneles persisten

--- LADO DEL SERVIDOR ---

netstat -tapn | grep ssh // tcp 0 0 server_ip:22 clint_ip:port ESTABLISHED 24915/sshd: user_name

lo que significa que hay una conexión permanente a través del protocolo shh

--- LADO DEL CLIENTE ---

mysql -h 127.0.0.1 -P 1000 -u mysql_user -pmysql_pass

ahora su cliente mysql (del lado del cliente) está conectado al servidor remoto mysql ... aquí 127.0.0.1 es una máquina cliente

lo mismo para workbench, heidiSQL

cómo matar túneles ssh

ps fax | grep ssh kill process_id

Tuve el mismo problema ( "Lost connection..." ) en Windows (mientras usaba el túnel ssh vía Putty). Tengo 2 problemas aquí:

Se usó un puerto incorrecto, comprueba si lo estás configurando correctamente
Olvidé habilitar en Putty: Connection > SSH > Tunnels > Local ports accept connections from other hosts

Un simple paso funcionó para mí ... Lo compartiré, así que tal vez algunos de ustedes se ahorren un dolor de cabeza.

MI CONFIGURACIÓN

En mi caso particular, tengo un servidor Percona funcionando en Ubuntu, conectado a MySQL Workbench (en una VM Windows) a través de SSH; el servidor funcionó bien durante varios días antes de escupir un error 10060 mientras procesaba una consulta.

LO QUE ME FUNCIONA

Encontré en un foro de Acquia.com que en algunos casos Workbench no aceptará ''127.0.0.1'' como host, por lo que debe cambiarlo a ''localhost''. Lo hice, y funcionó (curiosamente, el Workbench pidió las contraseñas nuevamente, incluso si ya estaban almacenadas, pero funcionaron de todos modos).