Hi,
The attached patch extends the mux listener to accept SOCKS 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.
Cheers,
- Salva
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-muxsocks-1.patch
Type: text/x-patch
Size: 3669 bytes
Desc: not available
Url :
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090304/11d9d6ba/attachment.bin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: snc
Url:
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090304/11d9d6ba/attachment.ksh