[Bug 2147] OpenSSH remote forwarding of dynamic ports doesn't work when you create more than one

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2147

--- Comment #3 from Ron Frederick <ronf at timeheart.net> ---
I appreciate you considering this for the next release.

I've been doing some more testing on this, and I think it may have been
a mistake for me to replace the hostname in the channel open message
with the actual listening address. By doing that, it makes it more
difficult for the client to match up against the right listener.

That said, the reason I didn't discover this in my testing is that the
current openssh client code doesn't actually try to match on the
hostname at all when matching which remote listener it is -- it only
matches on port! So, if you try to set up multiple listeners at once
from a client on the same server-side port (by setting
GatewayPorts=clientspecified in the server config and binding to
different addresses), the client always matches on the first listener
with that port, as seen in the following code snippet:

Channel *
channel_connect_by_listen_address(u_short listen_port, char *ctype,
char *rname)
{           
        int i;

        for (i = 0; i < num_permitted_opens; i++) {
                if (permitted_opens[i].host_to_connect != NULL &&
                    port_match(permitted_opens[i].listen_port,
listen_port)) {
                        return connect_to(
                            permitted_opens[i].host_to_connect,
                            permitted_opens[i].port_to_connect, ctype,
rname);
                }
        }
        error("WARNING: Server requests forwarding for unknown
listen_port %d",
            listen_port);
        return NULL;
}

Note that it checks here that a host_to_connect is set, but it doesn't
even pass in the listen_address to match against when this is called
from client_request_forwarded_tcpip() in clientloop.c. This means you
can't actually have two different listeners on the server side with the
same port listening on different addresses and forwarding to different
destinations.

My suggestion is to keep the portion of my change which fills in the
proper listening port instead of 0, but leaves the reported listening
address as the hostname/address which was requested. That way, a client
which does proper matching of both the listening host & port would
always be able to do so (since it got the actual licensing port back in
the global request's response when dynamic ports were requested). To
make this work right with OpenSSH as a client, though, additional
changes would be needed on the client side to extend the listener
matching to include both the host & port.

If you'd like me to submit a new patch for the server change here, let
me know. The client change is something we might want to handle in a
separate bug.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.