Bug 1334

Summary:	Bind tunnels to given interface on the server
Product:	Portable OpenSSH	Reporter:	Gilles Pietri <contact+dev>
Component:	sshd	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED WONTFIX
Severity:	enhancement	CC:	contact+dev, djm
Priority:	P2
Version:	4.6p1
Hardware:	All
OS:	All

Description Gilles Pietri 2007-07-06 21:57:41 AEST

It is actually possible to bind any outgoing ssh connection using -b in order to choose which interface to use on the client if you have more than one.

Could we have the same behaviour for tunnels? Channel opening can happen on a multi-homed server, and I've seen no way to choose which IP ssh should use (on the _server_, the IP used for "outgoing" connection, not the bind_address for the interface used by clients to connect to it).

Let me be clearer here, let's say I'm on a client, and I have a server which has 2 ips 192.168.1.1 and 192.168.1.10. I want to open a dynamic tunnel (or a local forward, whatever) from this server using ssh -D 1080:192.168.1.10 (or any other syntax or config parameter), so as to open a dynamic tunnel that would actually use the 192.168.1.10 as interface for outgoing connection.

This mainly looks like adding a parameter somewhere and call bind() with it before actually open()ing the socket, but I'm not sure here, and it would require a change of the configuration parameters. I don't think SOCKS protocol itself allows for such a thing, and I would like not to have to use a separate SOCKS server that has this feature to do that (as this could also be used for -L tunnels, and well, because it's better if SSH supports it natively IMHO).

Any thought?

Comment 1 Damien Miller 2009-07-31 11:35:04 AEST

Hi,

Sorry for taking so long to reply.

Unfortunately, specifying a remote bind address for local forwards/dynamic forwards is not supported by the SSH protocol - there is no field in the the port-forwarding request message to specify it (cf. RFC4254 section 7.1 if you are curious)

So it is not possible to do this without an OpenSSH-only protocol extension, which is not really desirable.

Comment 2 Damien Miller 2009-10-06 15:02:37 AEDT

Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.