See message http://www.mindrot.org/pipermail/openssh-unix-dev/2005-March/022829.html and its follow ups
Created attachment 858 [details] my patch
Created attachment 879 [details] Unpacked patch Please attach future patches in uncompressed format.
Comment on attachment 879 [details] Unpacked patch Some comments: >diff -u openssh-4.0p1/channels.c patch/channels.c >--- openssh-4.0p1/channels.c 2005-03-01 11:24:33.000000000 +0100 >+++ patch/channels.c 2005-03-15 16:44:12.000000000 +0100 >@@ -2289,6 +2289,18 @@ > close(sock); > continue; > } >+ /* If the specified port was 0, get the actual port number */ >+ if (*listen_port == 0) { >+ struct sockaddr_in realport; >+ socklen_t realportsz = (socklen_t)sizeof(realport); >+ if (getsockname(sock, (struct sockaddr *)&realport, &realportsz) < 0) { >+ error("getsockname: %.100s", strerror(errno)); >+ close(sock); >+ continue; >+ } >+ *listen_port = (u_short)ntohs(realport.sin_port); This will only work for AF_INET sockets - it won't work for IPv6. >@@ -2383,8 +2395,27 @@ > packet_put_int(listen_port); > packet_send(); > packet_write_wait(); >- /* Assume that server accepts the request */ >- success = 1; >+ >+ if (listen_port != 0) >+ /* Assume that server accepts the request */ >+ success = 1; >+ else { >+ type = packet_read(); This is incorrect: you shouldn't assume that the next packet is going to be a reply to your request. It may be something completely unexpected, like an IGNORE packet or the start of a rekey. You should use the dispatch.c functions to catch the reply and associate it (by seqno) back to your request.
Created attachment 1255 [details] Updated patch for 4.6p1 I've updated the patch to apply to 4.6p1 and have attempted to address the first issue raised in Comment #3. Fixing the other issue is currently beyond my shaky understanding of the code. I note that ssh accepts an argument of the form '-R 0:host:port', which is fine for the purposes of this enhancement but should otherwise be considered a bug. I blame the && on line 1258 of readconf.c. Also, a2port returns 0 on error, which isn't sensible if 0 is a valid port number. A proper fix would need to address this.
Created attachment 1595 [details] implement -R0:... forwarding for client and server This patch implements -R0:... forwarding for client and server The client support is pretty lame: it just prints the allocated port using logit(). Ideally it would make it possible to stuff it into the environment somehow, but I think the obvious solution of eval `ssh -R0:... yourhost` is too dangerous an idiom to support.
Created attachment 1596 [details] revised revised patch (relative to CVS -current as of 5 minutes ago) I have just adjusted a2port() to properly discriminate between explicitly zero and invalid port numbers and this required some tweaking of this diff.
patch has been applied - this will be in OpenSSH-5.2
Close bugs fixed/reviewed for openssh-5.2 release