[PATCH] accept SOCKS request over the mux socket

[William Ahern]

On Thu, Mar 12, 2009 at 05:31:35PM -0500, Jim Knoble wrote:
<snip> 
> Are there plans to implement domain sockets for '-R'?  If so:
> 
>     # Listen on the remote address ::1 on port 2222, forward back across
>     # the ssh link to address ::1, port 22
> 
>     ssh -R ::1/2222/::1/22
> 
>     # Listen on the remote address 127.0.0.1 on port 2222, forward back
>     # across the ssh link to the socket at /tmp/my-service-sock on the
>     # host ssh is running on
> 
>     ssh -R 127.0.0.1:2222:/tmp/my-service-sock

First of all, you have to modify the wire protocol to request remote domain
socket forwarding. When I did it, it was relatively simple. But...

Second of all, there are security issues with domain sockets. One of the
pains of domain sockets in general is you can't simply set SO_REUSEADDR. To
make them practical, you have to (at least provide the option to) unlink()
the path. Otherwise broken connections and other regular happenstances will
make live miserable to make use of the capability. And for all but the most
convoluted solutions, there are still races and other uncertainties.

<snip>
> In words, if '/' is used as the subargument separator, then Unix domain
> sockets cannot be specified.  If ':' is used, remote IPv6 addresses
> must be specified in square brackets, and if the first character of the
> "local" host specification is '/', then it's a Unix domain socket.
> 
> If you want Unix domain sockets to be used with -L or -R on the remote
> end as well, that works the same as above, only with -L and -R reversed.
> To forward between Unix domain sockets on both ends, you get:
> 
>     ssh -L /tmp/ssh-forward-sock:/tmp/my-service-sock
> 
> (I.e., only 2 subarguments, separated by ':').  Same for -R.  Obviously,
> sshd would have to be patched to support that.
> 

The way I implemented it was I re-wrote the the -L and -R parser to be more
generic, using a small state machine rather than ad-hoc string parsing. The
most straight-forward syntax would be to require domain paths to be between
braces; then there's no conflict (unless your path contains brances, but you
can escape those), and you don't even necessarily need to require absolute
paths, because the brace syntax can bootstrap you into a new syntax domain.
For instance:

	-R[/tmp/remote-foo]:[/tmp/local-bar]

Or perhaps:

	-R[unix://some/relative/path/remote-foo]:[unix:///tmp/local-bar]

(I'm unfamiliar with the sftp spec, but I bet there's a useful syntax there,
too.)