openssh unix dev - Apr 2006 - tcpip-forward with port 0 and 'want reply'

RFC 4254 says, in regards to the "tcpip-forward" request message:

	Section 7.1

	...

	If a client passes 0 as port number to bind and has 'want reply' as
	TRUE, then the server allocates the next available unprivileged port
	number and replies with the following message; otherwise, there is
	no response-specific data.
	
	byte	SSH_MSG_REQUEST_SUCCESS
	uint32	port that was bound on the server

However, it doesn't seem like OpenSSH supports this. If you request a port
of zero, the code never 1) returns or 2) listens for the allocated port,
even though 'want reply' is _always_ TRUE.

So I'm left wondering, what happens if you request multiple forwardings w/
port 0 with different hostnames? Seems like there's a silent collision; not
sure if it blows up.

I'm no longer surprised nobody has added domain socket support yet. FWIW,
the route I've take so far is replacing all the host/port pairs with a
SocketName structure, and added the streamloceal-forward at openssh.com and
forward-streamlocal at openssh.com messages.

In the process I've run into trouble w/ ForwardPermissions. I suspect
there's a bug in the SSH 2.0 support since it doesn't keep track of
listening hostnames, only the port. Again, there's a silent collision and
either the permissions are too strict or too loose.

- Bill

On Wed, 19 Apr 2006, William Ahern wrote:
> However, it doesn't seem like OpenSSH supports this. If you request a
port
> of zero, the code never 1) returns or 2) listens for the allocated port,
> even though 'want reply' is _always_ TRUE.
No, we don't support this presently. There is a patch in bugzilla but
the last time I looked it required a bit more work.
> In the process I've run into trouble w/ ForwardPermissions. I suspect
> there's a bug in the SSH 2.0 support since it doesn't keep track of
> listening hostnames, only the port. Again, there's a silent collision
and
> either the permissions are too strict or too loose.
Yes, permitopen doesn't support specification of a bind_address 
presently. It should "fail closed" on ambiguous matches though, so why
do you say the permissions are too loose?

-d