Created attachment 1613 [details] patch for OpenSSH current The attached patch extends the mux listener to accept SOCKS4/5 requests in addition to the native mux commands. The rationale behind is that creating tunnels attached to TCP ports is a security hazard in multi-user machines where there is no way to control who connects through the tunnels. On the other hand, The mux UNIX domain socket binds to the file system and regular permissions can be used for access control. I have also created a small Perl script "snc", similar to netcat, that uses this new feature. In the end, if this patch gets accepted, my idea is to extend my Perl module Net::OpenSSH to use it. Under the hood, the code I have added just looks at the first byte coming from the mux connection. When it is a mux command, it corresponds to the first byte for the packet length encoded as a 32bits integer in network order and so, it is 0 (packet length is limited to 256KB). When it is a SOCKS connection the first byte is 4 or 5 so we can easyly distinguish both protocols. I know it is somewhat hacky, but the alternatives I see are: 1) to use a dedicated socket for the SOCKS proxy 2) to extend the mux "protocol" with new commands offering equivalent functionality. I don't like (1) because, IMO, it would unnecessarily complicate ssh usage. I don't like (2) because adapting a SOCKS client to use a UNIX socket instead of a TCP one, should be much easier than implementing a new protocol.
Created attachment 1614 [details] prove of concept, perl script
Created attachment 1615 [details] patch for dsocks-1.6 patch for dsocks-1.6 (http://www.monkey.org/~dugsong/dsocks/) that adds support for connecting to the SOCKS server through an UNIX domain socket. For instance, with these patches applied to dsocks and ssh, I can run: $ ssh -M -S /tmp/mux 172.20.3.12 -N -f $ LD_PRELOAD=/root/my-dsocks-1.6/libdsocks.so.1.0 \ DSOCKS_PROXY=/tmp/mux \ DSOCKS_NAMESERVER=172.20.4.17 \ lynx www.openbsd.org And browse the web without opening a local listening port on my computer for the SOCKS proxy.
Discussion about this feature taking place in openssh-unix-dev@mindrot.org On Mar 11, 2009, at 1:21 PM, Jim Knoble wrote: > > Circa 2009-03-11 10:27 dixit Ben Lindstrom: > > > > : I'm concerned that people will become confused since -M -S combo has > > : been resevered for multiple ssh terminal sessions over a single > > : tunnel. I'd rather see it more clear like: > > : > > : ssh -D -M -S /tmp/mux 172.20.3.12 -N -f if you want multiple > > tunnels > > : + SOCK support > > : ssh -D -S /tmp/mux .. if you just want SOCKS support instead of a > > PORT > > : > > : Which means an error needs to be throw on > > : > > : ssh -Dxxx -S xxxx > > > > The above means that you can't separate permissions for the mux socket > > and the SOCKS socket. > > > > Better to create a dedicated SOCKS socket, no? > > > > ssh -D /tmp/ssh-socks-socket ... > > > > That is, '-D' may accept either an IP address or a filesystem path. > > Reserve '-S' for use with multiplexing sockets. This way, one can: > > > > ssh -D /tmp/ssh-socks-socket -M -S /tmp/ssh-mux-socket ... > > > > and allow more than one user to use the SOCKS connection while keeping > > the mux socket more private. > > > > This also makes the '-D' syntax consistent and sensible. > > That works for me. I just found the mutation and corruption of -M -S to be a bit dodgy when we already have a -D that is clearly tagged as being a socks4/5 server functionality flag. - Ben
Created attachment 1616 [details] use UNIX domain sockets instead of INET for tunnel listeners, proof of concept Following the discussion on openssh-unix-dev@mindrot.org, the new patch attached uses a different UNIX socket instead of reusing the multiplexer one. Now, it is possible to run... $ ssh -D/tmp/foo my.host.com -N and also... $ ssh -L/tmp/bar:remote.host.com:22 -N For instance, now, this works: $ ssh -L/tmp/listener:mandeo:22 10.0.2.2 -N -f $ ssh -o ProxyCommand="socat STDIO UNIX-CONNECT:/tmp/listener" mandeo A "port" is parsed as a UNIX path when it contains some slash. Unfortunately, slashes already had a meaning on tunnel specifications as they were used with IPv6 addresses. I had to remove that feature in order to implement mine... I know this is a bad idea, but this is just a prove of concept so, forgive me! I can see two solutions for that: 1) use a different set of flags: $ ssh -E/tmp/foo ... # instead of -D $ ssh -K/tmp/bar:my.host.com:22 ... # instead of -L it still doesn't play well with IPv6 addresses as parsing (and writing) things like... $ ssh -K/tmp/bar:::1/22 correctly can be quite tricky. 2) use some kind of special quoting $ ssh -D'</tmp/foo>' ... I like it, but has the inconvenient of <> needing quoting for the shell. {} and () are also processed by the shell. {} is probably the less problematic as it will not be modified by the shell unless some comma is found inside, something unusual for file names. Personally, I would go for -D{/tmp/foo}
Circa 2009-03-12 11:22 dixit Salvador Fandino: : > From: Jim Knoble <jmknoble@pobox.com> : > Sent: Wednesday, March 11, 2009 7:21:54 PM : > : > ssh -D /tmp/ssh-socks-socket ... : : I have attached a new patch to the request at... : : https://bugzilla.mindrot.org/show_bug.cgi?id=1572 : : doing just that. : : There is a problem with it and is that slashes already have an special : meaning on tunnel specifications , they are used with IPv6 addresses. The syntax you're speaking of is (from ssh(1)): IPv6 addresses can be specified with an alternative syntax: [bind_address/]port/host/hostport or by enclosing the address in square brackets. There's a key difference between that syntax and the Unix-domain socket path: The leading slash of an absolute path. That is: # Listen on IPv6 address ::1 on port 2222, forward across the # ssh link to address ::1, port 22 ssh -L ::1/2222/::1/22 # Listen on a Unix domain socket at /tmp/my-ssh-forward-sock, and # forward across the ssh link to address 127.0.0.1, port 22 ssh -L /tmp/my-ssh-forward-sock:127.0.0.1:22 # Listen on a Unix domain socket at /tmp/my-ssh-forward-sock, and # forward across the ssh link to address ::1, port 22 # TODO: Does this work: -L [::1]:2222:[::1]:22 ssh -L /tmp/my-ssh-forward-sock:[::1]:22 # Syntax error (too many ':') ssh -L /::1/2222/::1/22 In words: If the first character of the argument to -L is '/', it's a filesystem path, and ':' is required to be the sub-argument separator. Remote IPv6 addresses must be enclosed in square brackets. Otherwise, the syntax is the same as before. 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 # Listen on the remote address ::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 [::1]:2222:/tmp/my-service-sock # Syntax error (probably produces either "tmp: host not found" or # "my-service-sock: unknown port") ssh -R ::1/2222/tmp/my-service-sock 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. Anything i missed, for -L or -R?
Date: Thu, 12 Mar 2009 17:51:27 -0700 From: William Ahern <william[snip]25thandClement[snip]com> To: [snip] openssh-unix-dev@mindrot.org Subject: Re: [PATCH] accept SOCKS request over the mux socket Message-ID: <20090313005127.GA12637@wilbur.25thandClement.com> 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.)
On 2009-03-12 19:51, William Ahern wrote: : 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] This is interesting. Salvo had proposed using curly braces '{' and '}' for this, which may be necessary, as IPv6 addresses are curently allowed to be inside square brackets '[' and ']'. Haven't looked at the code, though. : Or perhaps: : : -R[unix://some/relative/path/remote-foo]:[unix:///tmp/local-bar] Aha. Thanks, William, for pointing out what I missed: the possibility of relative paths for the remote end. This is very interesting, and obviously URI-style specifiers are relatively commonplace these days. I would get rid of the '//' after the ':', as it is supposed to denote a host, but with Unix domain sockets, the host is implied to be one of the hosts at either end of the SSH connection. Thus: -R[unix:some/relative/path/remote-foo]:[unix:/tmp/local-bar] should be sufficient. I don't mind the extra typing associated with the square brackets and the URI-style specifier, as i suspect this usage wouldn't be terribly commonplace anyway. It also allows square brackets to be used without conflicting with the optional square brackets around IPv6 addresses. I'm in favor of this.
Is this patch necessary now that we support stdio forwarding over the mux socket now? A client could speak the SOCKS protocol on one side and the mux protocol on the other...