https://bugzilla.mindrot.org/show_bug.cgi?id=2147
--- Comment #3 from Ron Frederick <[email protected]> --- 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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
