Mailing List Archive

[Bug 1572] accept SOCKS requests over the mux socket in master mode
https://bugzilla.mindrot.org/show_bug.cgi?id=1572





--- Comment #1 from Salvador Fandiño <sfandino@yahoo.com> 2009-03-11 20:13:55 ---
Created an attachment (id=1614)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=1614)
prove of concept, perl script

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
[Bug 1572] accept SOCKS requests over the mux socket in master mode [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=1572





--- Comment #2 from Salvador Fandiño <sfandino@yahoo.com> 2009-03-11 20:16:41 ---
Created an attachment (id=1615)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=1615)
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.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
[Bug 1572] accept SOCKS requests over the mux socket in master mode [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=1572





--- Comment #3 from Salvador Fandiño <sfandino@yahoo.com> 2009-03-13 02:27:48 ---
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

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
[Bug 1572] accept SOCKS requests over the mux socket in master mode [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=1572





--- Comment #4 from Salvador Fandiño <sfandino@yahoo.com> 2009-03-13 03:12:15 ---
Created an attachment (id=1616)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=1616)
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}

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
[Bug 1572] accept SOCKS requests over the mux socket in master mode [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=1572


Jim Knoble <jmknoble@pobox.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |jmknoble@pobox.com




--- Comment #5 from Jim Knoble <jmknoble@pobox.com> 2009-03-13 09:34:35 ---
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?

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 1572] accept SOCKS requests over the mux socket in master mode [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=1572





--- Comment #6 from Jim Knoble <jmknoble@pobox.com> 2009-03-13 16:41:56 ---
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.)

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 1572] accept SOCKS requests over the mux socket in master mode [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=1572





--- Comment #7 from Jim Knoble <jmknoble@pobox.com> 2009-03-13 17:01:31 ---
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.

--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs