
Sshuttle - tunnel all your traffic through ssh - fs111
https://github.com/apenwarr/sshuttle
======
tlrobinson
NOT all your traffic. This only does TCP. Any DNS, UDP, and other non-TCP IP
traffic won't go through the tunnel!

I tried sshuttle awhile ago and abandoned it because of this. The only thing
worse than no security is a false sense of security.

~~~
fs111
I personally don't use it for security reasons, but to be able to listen to
last.fm easily through a vps in a country, where that is for free. (just one
example)

Security is never just a software you install, it also depends on you,
knowing, what you do.

~~~
tlrobinson
Sure there are other uses. I'm just making sure people know, because it's
being advertised as a VPN alternative, and this problem wasn't obvious to me
when I first looked at it.

------
bryanlarsen
+1 for a reference to slirp, which let you turn a dial-in connection to a Unix
terminal into a real internet connection back in the days when your University
would give you a terminal connection but not a PPP connection.

~~~
hollerith
I remember SLIRP -- and The Internet Adapter.

~~~
brianjesse
I used SlipKnot for that -- it converted a shell-dialup at University of
Oregon into a SLIP connection that I could use with Netscape 1.0

~~~
hollerith
SLIP being a "competitor" to PPP.

------
nprincigalli
Just a little nitpicking, when he talks about TunnelVision, he should have
said:

    
    
      And nobody never notified me of any security flaws in my key exchange,
    

Instead of:

    
    
      And nobody ever found any security flaws in my key exchange,
    

Yeah, hell is in the details...

Regarding SSHuttle itself, I really liked it! (coming from someone who does
all his browsing with ssh -D)

------
agj
The alternative that predates this is to this is to just tunnel ppp over ssh
using pppd:

    
    
        pppd updetach noauth pty "ssh root@example.com pppd nodetach notty noauth" ipparam 192.168.1.100:192.168.1.2
    

I used this for many years before switching to openvpn. This does require root
access on the host to execute pppd however.

------
ch0wn
I set up an OpenVPN server for this purpose. This solution is so much easier
and elegant, it's not even funny.

~~~
tomjen3
I tried to setup an openVPN server, but after chasing a rabbit hole of
instructions down the craziest URLs with obsolete or missing information I
finally gave up.

How did you get it to work?

~~~
mbesto
I did this on Linode:

<http://library.linode.com/networking/openvpn/>

Super easy to do even if you are a linux noob.

~~~
ch0wn
That's the same guide I used. Very comprehensive and easy to follow.

------
psn
[https://github.com/apenwarr/sshuttle/commit/33efa5ac62eaf9cf...](https://github.com/apenwarr/sshuttle/commit/33efa5ac62eaf9cf924de88d2dfde7547ed9e570)
is the point where I get confused.

In a normal tunnel setup, one tunnels at the IP layer, and dumps all IP
packets into the tunnel. At the far end of the tunnel, packets are sent
onwards based on the far end's routing table. Things like DNS "just work"
because everything happens at a layer below TCP and UDP. In this system, he's
making it work for each non-tcp using layer 4 protocol separately, leading to
weirdness like rewriting /etc/hosts.

For tcp, he's nating all traffic locally to a local server, which then
multiplexes all incoming traffic into the ssh connection. The remote side then
unmultiplexes the data. I don't fully understand how this avoids tcp over tcp.
Maybe I'm dumb. [edit: yeah, I'm dumb. the tcp connection is terminated at the
local server, the contents are pumped over the ssh connection, and the remote
side opens a new tcp connection]

I wrote this mostly because I read the readme and went "but how does it
work?".

~~~
apenwarr
sshuttle does not (currently) attempt to do anything other than TCP and DNS.
UDP ought to be possible (other than that UDP-over-TCP could have similar
problems to TCP-over-TCP, ie. that packets are never lost and this could
confuse a hypothetical UDP-based congestion control algorithm). ICMP is
probably not possible unless we run the server side as root.

The "--auto-hosts" option you linked to is _not_ the same as the "--dns"
option. auto-hosts doesn't capture DNS at all; instead it just adds to your
local /etc/hosts. I use this feature much more than --dns, actually, because
unlike --dns, it works great if you have multiple tunnels to different offices
open at once. (You get _all_ the hostnames from _all_ the offices.)

sshuttle was originally designed to VPN into an office and forward a couple of
subnets over. In that case, you often _don't_ want to use the remote DNS
server, you just want to know the remote hostnames, because _most_ of your DNS
lookups have nothing to do with the remote server. Hence --auto-nets and
--auto-hosts.

Nowadays it seems like sshuttle is mostly being used to counter things like
Firesheep, which means you want to forward _all_ your traffic to a remote
server. In that case --dns - which forwards _all_ your port 53 traffic over
the VPN - is preferable.

We could actually do all the other UDP ports the same way we do --dns. We just
don't, because I haven't needed it and nobody else has submitted a patch.

------
iuguy
How does this compare to OpenSSH VPN and Socks Support[1]?

[1] - <http://wiki.enigmacurry.com/OpenSSH>

~~~
SageRaven
Very much different. He explains it in the article quite clearly. No need to
manually configure clients to use the proxy, as it uses the client's firewall
to forward connections.

~~~
jrockway
But plain OpenVPN uses the normal IP routing machinery to send stuff over the
VPN, which is even easier.

~~~
mike-cardwell
To use OpenVPN you have to install extra software on the server and edit
configuration files and set up keys. Not sure how that is easier?

~~~
jrockway
The setup cost is higher, true, but the performance is better. TCP-over-TCP
does not work well.

~~~
mike-cardwell
I've heared the claim that TCP over TCP doesn't work well countless times.
I've been using OpenVPN in tcp mode for at least 5 years on a daily basis and
never noticed a problem. I've even done SIP over a TCP OpenVPN configuration
without a noticeable problem.

It makes sense to me that it _should_ perform badly, and it probably does for
uses cases with a lot of traffic, but for an average user on a laptop, a TCP
based VPN is fine.

~~~
apenwarr
What happens is you essentially get "infinite bufferbloat." When there's no
packet loss, you end up absolutely filling the transmit buffers at the entry
points to the tunnels. The result, as other people have mentioned, is
_extremely_ poor interactive performance when you're simultaneously
transferring large files.

TCP-over-TCP not "broken" in the sense that the sessions will randomly drop or
your kernel will crash or anything. It's just that doing it correctly is much
better.

Mind you, given the prevalence of bufferbloat (mostly caused by misdesigned
routers/DSL/cablemodems) nowadays, interactive performance _already_ largely
sucks when you're transferring large files. So you might not even notice a
difference.

Bufferbloat makes me sad :(

~~~
mike-cardwell
Yeah. I understand why it is claimed to be bad. But in all my years of using
it, I've never had a problem like that which you just described.

------
daemonize
Socat can do this: first read: <http://www.dest-unreach.org/socat/doc/socat-
tun.html> then read: [http://www.dest-unreach.org/socat/doc/socat-
openssltunnel.ht...](http://www.dest-unreach.org/socat/doc/socat-
openssltunnel.html)

~~~
kqr2
Does the TCP over TCP problem occur with socat tunnels?

------
bretthopper
It's always good when there's only 2 steps to get it working and they work
perfectly.

Using it over hotel wifi as I'm typing!

------
sandGorgon
Can I receive postbacks using this ?

Explanation - as usual, my company works on a shared LAN which goes through a
single internet connection. To test some applications, we have to be able to
receive postbacks (on our developer machines) through 3'rd party services. The
best way we found was to have an OpenVPN server running somewhere. Each
developer connects to the VPN server and receives a private IP-address. All
postbacks go to the VPN server and are then routed through nginx to the
correct developer machine (on the private IP address).

VPN is a pain to setup and configure - can something like this be used instead
? The question really is - how does nginx forward requests to the correct
developer machine.

~~~
HerraBRE
Have you looked at <http://pagekite.net/> ?

It's a generic "expose my local HTTP server to the Internet" tool, designed to
be really convenient and easy to set up (assuming you already have a local
HTTP server). If I understand you correctly, it may be exactly what you are
looking for.

It's FOSS so if you don't want to use the service (my startup!) you can roll
your own. :-) But if you're looking for convenience, the service is probably
hard to beat. Come chat on #pagekite on Freenode if you've got any questions!

~~~
sandGorgon
looks awesome - thanks !

I suppose we will sign up sooner or later - 10 Euro isnt too expensive.

~~~
HerraBRE
Cool! We're actually doing a pilot program right now to try and better
understand the needs of web developers who use PageKite, so be in touch if
you'd like to be part of that.

------
chopsueyar
How would one go about setting this up with a firmware rewritable consumer-
grade router?

Can I have a ww-drt install act as a client with Sshuttle and install a public
key to require no login?

~~~
wyuenho
You can have Python running on the DD-WRT box of course, which will probably
drastically slow down your router. You can also generate a public key for the
router and append it to a remote host's .ssh/authorized_keys file, but for
reason number 1 above, it's probably not a good idea. Now if you have a PC box
running Vyatta or pfSense, then you might be able to pull this off with
minimum impact.

~~~
chopsueyar
Any inexpensive and small form-factor recommendations for hardware for
pfSense?

------
davej
Brilliant. Before this I used `ssh -d` and tunnelled everything through the
port with proxifier.app but this is a much nicer (and free) solution!

------
sigil
Very cool. I wonder how hard it would be to port the muxer core to C, and run
it under tcpclient / tcpserver on either end of the ssh connection.

~~~
fs111
Click the little "fork" button and let us know, what you came up with :-)

~~~
sigil
Maybe I will. ;)

A few years back, I wrote a multiplexer / tunneler similar to Sshuttle in
Python for a "Go To My PC" style web service. We wanted to tunnel over ssh,
but had problems automating the client key generation and first-time
connection. So we went with SSL. That and the cross platform requirement (most
clients were running Windows) really took the fun out of it.

------
askedrelic
I've been running this for months now and really like it. Really simple to
setup and quite flexible.

------
tobylane
Anyone know of a portable Chrome that I can SSH into home with? Preferably
something I can leave on a shared computer, while only I have access to the
stunnel. Also, it may need to be able to use port 80, I don't know the filter
inside-out.

------
duckyflip
Would this circumvent the checks Hulu does for example by forcing Flash to
always connect directly. i.e using SOCKS Proxy will not work with Hulu but
using full VPN will, so how will sshuttle rate ?

~~~
aidenn0
Full VPN, but it doesn't work on windows.

Also, if you start streaming Hulu through a shell account, there is a good
chance that your shell account provider will notice and possibly get angry.

------
ccarpenterg
I'm a little confused. I'm outside USA and I want to browse some restricted
content for users located outside of the U.S. Can I do this using Sshttle and
a VPS?

~~~
spullara
All traffic will come from the machine that you are SSH'd into.

~~~
ceejayoz
Translation: Yes, if your VPS is in the US.

~~~
ccarpenterg
Yes, It's in the US. I'm not confused anymore.

~~~
leon_
you don't need shuttle

> ssh -D localhost:8888 <you@yourvps.com>

then enter localhost:8888 as your socks proxy in your web browser.

------
apenwarr
Previously on HN: <http://news.ycombinator.com/item?id=1313083>

------
afhof
<http://bodhizazen.net/Tutorials/VPN-Over-SSH/>

~~~
jerf
Please actually read the linked articles before replying, and signal some
recognition of the fact you have done so in your reply. If you wish to argue
that the arguments put forth in the sshuttle README are somehow invalid and
that what you linked is still better, please do so, but at the moment it looks
like you haven't even read them.

------
chopsueyar
_From the github.com page_

This is how you use it:

    
    
        git clone git://github.com/apenwarr/sshuttle on your client machine. You'll need root or sudo access, and python needs to be installed.
    
        ./sshuttle -r username@sshserver 0.0.0.0/0 -vv
    

(You may be prompted for one or more passwords; first, the local password to
become root using either sudo or su, and then the remote ssh password. Or you
might have sudo and ssh set up to not require passwords, in which case you
won't be prompted at all.)

That's it! Now your local machine can access the remote network as if you were
right there. And if your "client" machine is a router, everyone on your local
network can make connections to your remote network.

You don't need to install sshuttle on the remote server; the remote server
just needs to have python available. sshuttle will automatically upload and
run its source code to the remote python interpreter.

This creates a transparent proxy server on your local machine for all IP
addresses that match 0.0.0.0/0. (You can use more specific IP addresses if you
want; use any number of IP addresses or subnets to change which addresses get
proxied. Using 0.0.0.0/0 proxies everything, which is interesting if you don't
trust the people on your local network.)

Any TCP session you initiate to one of the proxied IP addresses will be
captured by sshuttle and sent over an ssh session to the remote copy of
sshuttle, which will then regenerate the connection on that end, and funnel
the data back and forth through ssh.

Fun, right? A poor man's instant VPN, and you don't even have to have admin
access on the server.

