Bug 2017

From the documentation:
  If the port argument is ‘0’, the listen port will be dynamically allocated on the server and reported to the client at run time.  When used together with -O forward the allocated port will be printed to the standard output.

When using this functionality I found that if multiple remote ports were dynamically allocated then connections to any of those ports will forward back to the first forward requested.  Though not a severe problem this behavior can be extremely misleading.

On the local host (margarita):
jdunn@margarita~$ ssh www.tdt.com -R 0:localhost:22 -R 0:localhost:80
Allocated port 33029 for remote forward to localhost:22
Allocated port 33719 for remote forward to localhost:80

On the remote host (www):
jdunn@www:~$ nc localhost 33029
SSH-2.0-OpenSSH_5.9
^C
jdunn@www:~$ nc localhost 33719
SSH-2.0-OpenSSH_5.9
^C

Apparently both remote ports are being mapped to the same local port.  Looking through the code I found that 0 is being passed as the listen port to channel_connect_by_listen_address.  The for loop in that function then finds the first permitted_opens[i] with a listen port of 0.

I was hoping to provide a simple fix, but it appears to require changing the client-server protocol since the dynamically allocated port is not supplied in the server packet unpacked in client_request_forwarded_tcpip.  I suspect that the correct solution is just to replace the listen_port used in the communication with the dynamically allocated port.  The port number would also have to be updated in the permitted_opens list when the server allocated the remote port.

I was able to replicate this first in Fedora17, Debian Squeeze, and then checked the nightly snapshots of Portable OpenSSH where I found the same problem.