How can I tunnel all of my network traffic through SSH?

Question

Whenever I'm using the internet from an insecure location (such as public wifi) I like to use an ssh tunnel (ssh -D port host) to ensure my traffic can't be sniffed. Unfortunately, there seem to be many applications which do not provide a way to specify a proxy (Flash is one major example).

It feels like there should be some way to use a tunnel for all network traffic from my computer, but I'm complete ignorant of how to do this. Any help would be greatly appreciated.

Solution 1

To do what you are wanting, I recommend sshuttle.

You use it like this:

./sshuttle -r username@sshserver 0.0.0.0/0 -vv

It will tunnel all your TCP traffic automatically for you. You can add the --dns argument to have it tunnel your DNS traffic as well. The remote server only needs to have Python installed.

If you only want to tunnel specific programs I would recommend proxychains.

Once it is installed, start your ssh socks proxy like this:

ssh -fNTD 127.0.0.1:<local port> username@sshserver

This will start a "SOCKS" proxy listening on <local port>.

Then edit /etc/proxychains.conf to point to the same port as <local port>:

socks5 127.0.0.1 <localport>

Finally start your program that you want proxy-ed like so:

proxychains <program name>

It should just work. However, a few programs will have trouble working with Proxy Chains. Also keep in mind, that with Firefox, you have to change additional items under about:config to force it to do DNS lookups through the proxy instead of bypassing it.

As an additional note, on web browsers. If they support socks proxies, you don't need to do anything additional to get them to use the above mentioned, ssh tunnel, just enter 127.0.0.1 for the SOCKS proxy server and the <local port> for the proxy port.

EDIT 3/29/16

Since this post is still seeing some upvotes, I thought I'd update it. Proxychains is still in most Linux repos and still works on Linux. However, the project is effectively abandoned and does not work on OSX. For either Linux or OSX, I highly recommend upgrading to a still-maintained fork: proxychains-ng: https://github.com/rofl0r/proxychains-ng

Besides working in both Linux and OSX, it is easy to compile, and also has much better support for DNS tunneling.

I should also mention another option, which is redsocks. It works similarly to proxychains(-ng) and is also likely in your dist repo: https://github.com/darkk/redsocks

EDIT 11/27/19 If you go the proxychains route, please use proxychains-ng. There are some serious bug fixes over the legacy version, like: https://github.com/rofl0r/proxychains-ng/issues/292

Solution 2

man ssh gives an example of exactly this. An ssh based vpn:

SSH-BASED VIRTUAL PRIVATE NETWORKS
     ssh contains support for Virtual Private Network (VPN) tunnelling using
     the tun(4) network pseudo-device, allowing two networks to be joined
     securely.  The sshd_config(5) configuration option PermitTunnel controls
     whether the server supports this, and at what level (layer 2 or 3 traf-
     fic).

     The following example would connect client network 10.0.50.0/24 with
     remote network 10.0.99.0/24, provided that the SSH server running on the
     gateway to the remote network, at 192.168.1.15, allows it:

       # ssh -f -w 0:1 192.168.1.15 true
       # ifconfig tun0 10.0.50.1 10.0.99.1 netmask 255.255.255.252

~~ snip ~~

     Since a SSH-based setup entails a fair amount of overhead, it may be more
     suited to temporary setups, such as for wireless VPNs.  More permanent
     VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8).

Once you have that new interface up, you'd just have to make it the default route, which is a different question.

Solution 3

Look for the "Tunnel" option in ssh. This creates a tunnel device that you can assign an IP address to, and then you change the default route to use that tunnel.

Solution 4

I've developed software that allows you to forward all TCP and optionally UDP through a SOCKS5 proxy, system-wide.

http://code.google.com/p/badvpn/wiki/tun2socks

It can even be installed on a router to forward all connections from computers on the LAN.

Solution 5

SSH-BASED VIRTUAL PRIVATE NETWORKS ssh contains support for Virtual Private Network (VPN) tunnelling using the tun(4) network pseudo-device, allowing two networks to be joined securely. The sshd_config(5) configuration option PermitTunnel controls whether the server supports this, and at what level (layer 2 or 3 traf‐ fic).

 The following example would connect client network 10.0.50.0/24 with
 remote network 10.0.99.0/24 using a point-to-point connection from
 10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway
 to the remote network, at 192.168.1.15, allows it.

 On the client:

       # ssh -f -w 0:1 192.168.1.15 true
       # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
       # route add 10.0.99.0/24 10.1.1.2

 On the server:

       # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
       # route add 10.0.50.0/24 10.1.1.1

 Client access may be more finely tuned via the /root/.ssh/authorized_keys
 file (see below) and the PermitRootLogin server option.  The following
 entry would permit connections on tun(4) device 1 from user “jane” and on
 tun device 2 from user “john”, if PermitRootLogin is set to
 “forced-commands-only”:

   tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
   tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

 Since an SSH-based setup entails a fair amount of overhead, it may be
 more suited to temporary setups, such as for wireless VPNs.  More perma‐
 nent VPNs are better provided by tools such as ipsecctl(8) and
 isakmpd(8).

View more solutions

Comments

[Admin]

Of course you can't tunnel literally ALL of your traffic through ssh, because that would mean tunneling ssh through itself, but we knew what you meant. :)

[Admin]

this is a good idea but you're only protected between your computer and your ssh endpoint. after that, your traffic is in the clear (unless otherwise protected, eg SSL). granted, it's much more likely to be over a wire, but still... you can't really trust wires you don't control.

[Admin]

But when you're out on the wide Internet, you have some safety in being just one of billions of packets, right? When you connect to a public Wi-Fi, you are one of maybe 3 connections, you can be identified personally, etc.

[quack quixote]

bad advice. "blowfish" is an SSH-1 cipher; it's fast, thought secure (as of 1999: unixhelp.ed.ac.uk/CGI/man-cgi?ssh+1 ), but still. you probably want ssh -2 -C -D [...] (force SSH2, use compression) and drop the -c. according to my system's man ssh the cipher list in SSH2 defaults to aes128-cbc,3des-cbc,blowfish-cbc,[etc]. my point is, if you request -c blowfish you might end up with SSH1, which is much less secure than SSH2.

[skjindal93]

True, but the Jeremy was under the impression that the connection was secure with just -D 8080, I merely stated it was better than what he was using. You make a valid point and that is why I mention the manual for more options.

[endolith]

Maybe you should change your answer, since it is helpful otherwise.

[Jeremy]

Forgot I asked this, don't use this site regularly. Thanks for the clarification... I had the strong impression that SSH was secure by default.

[LatinSuD]

WTF ain't SSH using encryption by default ??

[Lorenzo Von Matterhorn]

please add a source for your information. note: this is an old question.

[Beachhouse]

Good comment, but not at all related to what we're talking about here. Reverse ssh allows for a SERVER to request that a CLIENT route ONE port of traffic to it. More configuration would be needed to then route that traffic to the internet. You would also have to setup an SSH tunnel for each port. AND it has to be initiated from the server, not the client -- which why would you ever do that unless you had to?

[Nobody]

Could you explain a little more? The ifconfig command creates a new interfaces named tun0, right? Or is tun0 created by ssh and just further configured by ifconfig? Maybe add an example relevant to the question?

[aggregate1166877]

Note for newer Linux systems using sshuttle: at the time of writing there's a kernel bug that'll give you broken pipe. In that case, use: sshuttle -r root@host -x host 0/0

[frakman1]

Why is it that when sshuttle runs, whatismyip.com shows the correct remote location but I can't ping a device on that remote network from the terminal of the local machine even though if I manually ssh into the remote server, then I can ping that device successfully.

[shellster]

@frakman1 The SOCKS protocol uses TCP (It has a workaround for DNS and Version 5 in theory has ugly work-arounds for tunneling UDP). Those are the only protocols that it can tunnel (or at least without another solution performing additional traffic encapsulation and relaying inside of it). If you need Layer 2 traffic, you need to use a proper Layer 2 VPN solution like WireGuard, IPSEC, OpenVPN, etc.