openssh bugs - Dec 2016 - [Bug 2649] New: Problem with reverse tunnel between SSH client 5.5p1 and SSH server > 6.4p1

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

            Bug ID: 2649
           Summary: Problem with reverse tunnel between SSH client 5.5p1
                    and SSH server > 6.4p1
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: debacle at debian.org

I suffer from some change between OpenSSH 6.4 and 6.5, probably
https://bugzilla.mindrot.org/attachment.cgi?id=2344 (fix for bug
https://bugzilla.mindrot.org/show_bug.cgi?id=2147).

I have an OpenSSH client 1:5.5p1-6+squeeze3 on Debian 6 (Squeeze)
building a reverse tunnel with dynamic port to a Jessie server:

$ /usr/bin/ssh -t -t -R *:0:localhost:443 user at server somecommand

If the server runs OpenSSH up to version 6.4p1-2 ("forwardports" from
snaphot.d.o), everything is fine. With any OpenSSH server from 6.5p1-6
to 7.3p1-3, the tunnel gets established, but no data can be
transmitted over it. On any activity, the client side shows:

WARNING: Server requests forwarding for unknown listen_port 54321
debug1: failure forwarded-tcpip

When the client specifies the port (= no dynamic port):

$ /usr/bin/ssh -t -t -R *:54321:localhost:443 user at server somecommand

everything works fine, independent of the OpenSSH server version.

Reverting part of the change above solves the problem:

--- openssh-7.3p1.orig/channels.c
+++ openssh-7.3p1/channels.c
@@ -1458,7 +1458,7 @@ port_open_helper(Channel *c, char *rtype
                 } else {
                         /* listen address, port */
                         packet_put_cstring(c->path);
-                        packet_put_int(local_port);
+                        packet_put_int(c->listening_port);
                 }
                 if (strcmp(rtype,  
"forwarded-streamlocal at openssh.com") == 0) {
                         /* reserved for future owner/mode info */

This is also Debian bug #846379 (https://bugs.debian.org/846379)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

debacle at debian.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |debacle at debian.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
This is the commit in question:
https://anongit.mindrot.org/openssh.git/commit/?id=4def184e9b6c36be6d965a9705632fc4c0c2a8af

I'm not sure there is much we can do here: I believe that the client is
expecting the wrong value. The client was fixed to expect the correct
value after 5.5p1:

https://anongit.mindrot.org/openssh.git/commit/?id=68afb8c5f242ec74f48fd86137122399435dd757

-- 
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.

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

--- Comment #2 from debacle at debian.org ---
Dear Damien, unfortunately I have a lot of clients out there, and some
are hard (almost impossible) to upgrade. And to upgrade them they need
the SSH tunnel connection in the first place :~) Because they all
connect to the same server, I'm a little bit in a mess.

My suggestion would be a kind of optional behaviour on the server side.
Maybe a config variable "reverse_tunnel_wildcard_behaviour" or
whatever.

 - no configuration/default: new protocol behaviour
 - set to "vintage": old (pre 5.5p1) behaviour
 - set to "try my best": use new or old behaviour depending on client
version

I'm an SSH ignorant and do not even know whether the SSH server knows
about the SSH client version, so the third behaviour is purely wishful
thinking on my side. In theory, an incompatible change of protocol
(even if it is a bug fix) should reflect somehow in a "protocol
version", but I'm not sure, whether this is the case here?

Do you know, whether/how I can get the client and/or protocol version
in channels.c and port_open_helper()? TIA!

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