I have set up a SSH tunnel between two servers A and B. B has MySQL server, and this works:

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

While this doesn't:

mysql -h -P 3306 -u user -p

Although my.cnf has these lines:

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

Now about the tunnel. It connects the following:(A) localhost(9989) -> (B) localhost(3306) But when (on A, with ports forwarded) I do

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


And when I do

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


What might be the reason? What am I doing wrong?


There are three issues here.

1 - Forget about the SSH tunnel for now

You cannot bind MySQL to more than one specific IP. The first bind-address clause is overridden (therefore, ignored) by the second one. Your server only listens to

The reason why you can connect with -h localhost but not with -h is that in the first form, you do not actually connect through TCP/IP, but through a local socket.

Look in your my.cnf for a socket clause.

Remove one redundant bind-address clause. You may want to use bind-address=, which instructs MySQL daemon to listen to all network interfaces.

2 - Let's setup your SSH tunnel

The reason for you error ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 is not obvious to me. I suspect SSH tunnel is actually established only when it receives a connection request (in your case, when you run the mysql client). Since your server does not listen to (see previous paragraph), the SSH tunnel cannot be established, connection fails, and your client interprets it as a network failure.

3 - Why mysql -v -h localhost -P 9989 -u user userdb -p fails

Please post the output of

[edit : just added ...OR host LIKE 'localhost' below, as this might be relevant for troubleshooting purposes]

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

(replace 'user', after the LIKE clause, with the actual user name if necessary)

MySQL access control checks both the username/password (user) and the origin of the connection (host) to identify a user. You probably did not create a user 'user'@'localhost'.

N.B.: mysql.com being unreachable from my location at this time, I cannot link to the relevant manual pages.

  • Thank you so much for your detailed answer! Fixing the first issue made it work. – madfriend Jun 16 '12 at 9:08
  • You may have missed my last edit: "You may want to use bind-address=, which instructs MySQL daemon to listen to all network interfaces.". You are most welcome. – RandomSeed Jun 16 '12 at 9:13
  • What's the difference between localhost,, and a local socket? – user207421 Jun 16 '12 at 10:20
  • 3
    Local Sockets (a.k.a Unix Domain Sockets en.wikipedia.org/wiki/Unix_domain_socket) are one of the many possibilities for IPC (Inter-Process Communication - communication paths between two processes running on the same machine). It is comparable to shared memory. With mysql -hlocalhost, the client uses the socket. mysql -h127.0.0.1 explicitely instructs the client to use TCP/IP. Local Socket are more efficient because they bypass the network layer. – RandomSeed Jun 16 '12 at 11:01
  • Saved me with the bind-address fix! – Janis Peisenieks May 16 '13 at 8:14

I just encountered this very problem.

In my case MySQL server is configured with bind-address: I originally setup an SSH tunnel with a commonly mentioned -L 3306:localhost:3306 user@server string and from my computer connect with mysql -h

This does not work because MySQL no longer listens on or even "localhost"(aka, only

The correct tunnel string should be -L 3306: user@server. This will tell the remote tunnel end to connect to MySQL using the IP MySQL actually listens on.



--- SERVER SIDE ----

in target machine (that can be addresed by IP or a domain hosted) there is config file /etc/mysql/my.cnf having a line

bind-address    =

confirmed with console

netstat -tapn |  grep mysql
// tcp    0    0*    LISTEN      18469/mysqld

which means mysql server will respond only to request from the localhost

--- CLIENT SIDE ----

you have an account (eventualy a ssh-key) to log using cygwin,putty or a linux_shell

ssh user_name@host_name


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

which means hey ssh create a permanent connection from port 1000 on the machine that I type (client) to remote host_name:3306 .... means here the remote (host_name) and should not be replaced with localhost word because this will make the connection on unix (named) socket not by IP ... You'll get 'ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysql.sock' (2)' when trying co connect mysql

-f = go in background -N = no excution

both -f -N kind of nohoop - you can close console and tunnels persist


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

which means there is a permanent connection through shh protocol


mysql -h -P 1000 -u mysql_user -pmysql_pass

now your (client side) mysql client is conected to remote mysql server ... here is client machine

same for workbench, heidiSQL

how to kill ssh tunnels

ps fax | grep ssh
kill process_id

I did have the same proble ("Lost connection...") on Windows (while using ssh tunnel via Putty). I got 2 issues here:

  1. Wrong port was used, double check if you are setting it correctly
  2. I forgot enabling in Putty: Connection > SSH > Tunnels > Local ports accept connections from other hosts

In my case, a configuration in the SSH daemon was blocking the tunnel. AllowTcpForwarding should be enabled.

AllowTcpForwarding yes

A simple step worked for me... I'll share this, so maybe some of you can be spared a headache.


In my particular case, I have a Percona server running on Ubuntu, connected to MySQL Workbench (in a Windows VM) through SSH; the server ran fine for several days before spitting an error 10060 while processing a query.


I found in a forum from Acquia.com that in some cases the Workbench won't accept '' as host, so you must change it to 'localhost'. I did it, and it worked (oddly, the Workbench asked for the passwords again, even if they were already stored, but worked nevertheless).

Your Answer

