[Bug 2189] New: Client fails to consider hostname when matching rfwd channel opens
bugzilla-daemon at mindrot.org
bugzilla-daemon at mindrot.org
Thu Dec 19 12:14:31 EST 2013
https://bugzilla.mindrot.org/show_bug.cgi?id=2189
Bug ID: 2189
Summary: Client fails to consider hostname when matching rfwd
channel opens
Product: Portable OpenSSH
Version: -current
Hardware: Other
OS: All
Status: NEW
Severity: minor
Priority: P5
Component: ssh
Assignee: unassigned-bugs at mindrot.org
Reporter: djm at mindrot.org
>From bug 2147:
> 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.
--
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching the reporter of the bug.
More information about the openssh-bugs
mailing list