Hacker News Reader

Comment by ryanschneider | Hacker News Reader

Wow a little googling on this subject led me to sshuttle, which I've never heard of before but looks awesome, will try it out on Monday:

http://sshuttle.readthedocs.io/en/stable/usage.html

Basically "vpn over ssh" (not really, but close enough).

View on HN

"Wow a little googling on this subject led me to sshuttle, which I've never heard of before but looks awesome"

sshuttle is indeed awesome - a viable VPN that requires nothing on the endpoint but a functioning ssh login (and python on the remote host).

So any host, anywhere, with no configuration (and no permission required by the operators) that you can ssh into ... is now a VPN endpoint for you.

Sibling comments in this thread are pointing out that ssh has this functionality already and that is true, but some configuration and maintenance (and understanding) is required. Not so with sshuttle.

ALSO:

We (rsync.net) sponsored the reworking of the ipfw target for sshuttle so that it now works properly on FreeBSD with the --dns option, etc. We also sponsored proper UDP tunneling for sshuttle on FreeBSD but I am not sure those patches are in a -release version of FreeBSD yet ...

You need to use FreeBSD 11.0 (not 11.1) and you need to:

  git clone https://github.com/sshuttle/sshuttle.git
  cd sshuttle  ;  git checkout c746d6f7db3efbad6caddea76bdf916c46cf5c6e

... and that will get you a working sshuttle on FreeBSD with --dns support.

I mention this every time VPNs come up... It's just so much better than any of the other VPN clients if you are only interested in TCP, I've been using it for over 6 years.

The key difference between it and VPN protocols for anyone trying to compare is: TCP only, and TCP decompile/recompile with SSH in the middle. This has many advantages: speed (TCP over TCP is megga sucky obviously), server setup (basically none, you just need non-root access to an ssh server with python).

It really is as simple as making an SSH connection on the command line and you can route all your TCP traffic immediately.

It also has some really nice fine grained subnet routing features... On some strange occasions when I have needed it i have merged multiple remote subnets into the same virtual one one my machine by selecting ranges. It also has an auto discovery feature built in if you just want to route the specific IPs that exist on the other side.

sshuttle is also in a number of package managers now, it's in apt at least.

Its great, but. It won't work on unrooted Android devices, and I doubt it will work on unrooted iOS devices. Not sure about ChromeOS.

What's the difference between that and https://github.com/darkk/redsocks ?

Edit: why the downvote? I thought I asked a legit question...?

You can skip sshuttle's magic and do exactly the same thing manually with "ssh -D" + "iptables -j REDIRECT" + redsocks, but that's a lot moving parts.

From the HN guidelines:

Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

I use sshuttle frequently, usually as a quick censorship bypass tool for specific sites.

sshuttle also claims to have avoided the "TCP over TCP" problem.

https://stackoverflow.com/questions/41427123/how-does-sshutt...

sshuttle is basically magic to me. Wherever someone with no idea about their threat model has deployed firewalls (ala every major business I've ever worked at) sshuttle is usually the key to being productive for me.

The stuff magic to me is the tools that speak both HTTPS + SSH or some other protocol, showing some normal site to anyone but those in the know.

I've never had to use them since as you say few are that hardcore in their lockdowns, but it's nice to know they exist.

I use SSLH for my poor man's VPN, I use redsocks but I guess I could use sshuttle. SSLH is really nice, easy to setup, easy on your resources.

In case you don't know, ssh has built-in VPN support which may be enough for lots of use cases.

Both of the comments about VPN support within SSH seem to be heavily downvoted with no reason why. As far as I can see, their points are correct:

> OpenSSH has built-in TUN/TAP support using -w<local-tun-number>:<remote-tun-number>. Here, a layer 3/point-to-point/ TUN tunnel is described. It is also possible to create a layer 2/ethernet/TAP tunnel.[0]

Just with invalid terminology (s/ssh/OpenSSH) and the likelihood of the added slowdown mentioned in the article.

[0] https://wiki.archlinux.org/index.php/VPN_over_SSH

This is one of those Arch wiki pages that I find lacking, so I personally always refer to the man pages:

man 1 ssh:

     -w local_tun[:remote_tun]
             Requests tunnel device forwarding with the specified tun(4)
             devices between the client (local_tun) and the server
             (remote_tun).

             The devices may be specified by numerical ID or the keyword
             ``any'', which uses the next available tunnel device.  If
             remote_tun is not specified, it defaults to ``any''.  See also
             the Tunnel and TunnelDevice directives in ssh_config(5).  If the
             Tunnel directive is unset, it is set to the default tunnel mode,
             which is ``point-to-point''.

man 5 ssh_config:

     Tunnel  Request tun(4) device forwarding between the client and the
             server.  The argument must be yes, point-to-point (layer 3),
             ethernet (layer 2), or no (the default).  Specifying yes requests
             the default tunnel mode, which is point-to-point.

     TunnelDevice
             Specifies the tun(4) devices to open on the client (local_tun)
             and the server (remote_tun).

             The argument must be local_tun[:remote_tun].  The devices may be
             specified by numerical ID or the keyword any, which uses the next
             available tunnel device.  If remote_tun is not specified, it
             defaults to any.  The default is any:any.

man 5 sshd_config:

     PermitTunnel
             Specifies whether tun(4) device forwarding is allowed.  The argu-
             ment must be yes, point-to-point (layer 3), ethernet (layer 2),
             or no.  Specifying yes permits both point-to-point and ethernet.
             The default is no.

             Independent of this setting, the permissions of the selected
             tun(4) device must allow access to the user.

I've found that sshuttle with the --dns option still leaks dns queries occasionally so I set my web browser and curl to use SOCKS and run sshuttle to try to catch anything else.

If you pass --dns it tunnels that as well.

Handy when you want to do something private on a machine you don't have a VPN setup on.

Doesn't support UDP on macOS though.

It doesn't support UDP in general AFAIK, i'm a frequent user of shuttle and find it indispensable, but if you need UDP it does fail, but then most VPN protocols only support a subset of IP layer protocols, e.g multicast doesn't generally work on any of them.

sshuttle hasn't had an actual release in 5 years according to the github project.

If you're using a windows client I recommend bitvise tunnelier.

I suspect you are looking at the original repo. It has since been forked and has a few contributors now https://github.com/sshuttle/sshuttle

Wow, this does look amazing!

A shame it's a bit more involved to get working with Windows, it's a pain to have to start a Linux VM to be able to use it :(

If you use Windows and need to access in a browser some web services over ssh, then just run ssh -D and configure your browser to use PAC JavaScript file that redirects relevant host names to the ssh proxy.

This is almost what I do today, only difference is that I use a proxy switcher plugin in Firefox, rather than using a PAC file.

What about using cygwin instead of a Linux VM? I didn't have the time to try specifically this, bit normally you can reach really far with Cygwin. Plus, no need for root access, and the installation is natively "portable" (everything sits inside a single directory).

i came to this thread to recommend sshuttle. it's indispensable and very well-performing, imo.

I hadn't heard of it before, but it is beyond cool. I just installed it, ran the command, reconnected to my network and now it works. Amazing!

Ssh has builtin vpn.

Reply on news.ycombinator.com