Open Radar

 
Summary:

SSH is often used to establish tunnels over a secure channel, for example to allow a local client to connect to a piece of server software whose port is filtered for direct access on the server. One common example of this is using SSH tunnels to connect to servers on which the MySQL database server is running, but only bound to 127.0.0.1 on the server.

Note that, at present, neither MySQL server nor client support IPv6. ::1 is not a valid alternative to 127.0.0.1 as far as it is concerned.


Steps to Reproduce:

Assuming mysqld is bound to 127.0.0.1:3306 on the server, execute one of the following on the (Mac OS X) client, assuming 'server-name.example.com' is accessible 

ssh -v -L 13306:127.0.0.1:3306 server-name.example.com

ssh -v -L 127.0.0.1:13306:127.0.0.1:3306 server-name.example.com

(after adding an entry to /etc/hosts reading “127.0.0.1 localhost-v4”):

ssh -v -L localhost-v4:13306:127.0.0.1:3306 server-name.example.com



Expected results:

In all of these cases, the local forwarder should be bound to 127.0.0.1 on TCP port 13306.



Actual results:

In the first case, the socket is bound to ::1, not 127.0.0.1.

In the second case, an error is reported and no socket is bound. The error is:

channel_setup_fwd_listener: getaddrinfo(127.0.0.1): nodename nor servname provided, or not known
Could not request local forwarding.

In the third case, again, an error is reported and no socket is bound. The error is similarly:

channel_setup_fwd_listener: getaddrinfo(127.0.0.1): nodename nor servname provided, or not known
Could not request local forwarding.


Regression:

Unknown.


Notes:

OpenSSH_5.1p1 (the same version as used on Mac OS X 10.5.8) on Ubuntu Linux does not suffer from this problem: in the first case, sockets are opened for both 127.0.0.1 and ::1; in the second and third, sockets are opened for both 127.0.0.1.

The issue appears to be that the local forwarding socket is established with the same address family as the outgoing SSH protocol socket.

For IPv6-aware client applications, this is obviously not a problem, but for those which do not support IPv6, it renders SSH tunnelling useless where the target host is only accessible via IPv6.