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.

  • 14
    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. :) – CarlF Oct 29 '09 at 4:09
  • 1
    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. – quack quixote Oct 29 '09 at 5:51
  • 6
    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. – endolith Nov 2 '09 at 16:14
up vote 54 down vote accepted

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 -fND 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>.

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

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.

  • 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? – Nobody Feb 18 '17 at 17:07

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.

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.

Just wanted to clear up that (ssh -D port host) is not a 100% secure way for traffic not to be sniffed. Adding (ssh -D -c blowfish port host) would be a better choice because you are atleast adding encryption to your session. There are more options you could add but it is easy enough to just type "man ssh" in your terminal or Google for a complete listing.

The option I think that you are looking for is setting up a VPN (Virtual Private Network)

Have a look at this article to get an understanding of the diffrence between the two (SSH vs. VPN) or a good summarized version, before you tackle setting up your own VPN. If you do decide to go the VPN route I recommend OpenVPN, its free and lots of documentation and support.

  • 6
    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. – quack quixote Oct 29 '09 at 5:58
  • 2
    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. – ricbax Oct 29 '09 at 6:26
  • Maybe you should change your answer, since it is helpful otherwise. – endolith Nov 2 '09 at 16:16
  • 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. – user Dec 18 '10 at 4:10
  • 8
    WTF ain't SSH using encryption by default ?? – LatinSuD Jul 18 '11 at 10:31

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).
  • 1
    please add a source for your information. note: this is an old question. – Lorenzo Von Matterhorn Mar 12 '13 at 23:22

Use these examples:

  • Forward port 80 from a remote host to 8888 on your localhost

    ssh -fnN -L8888:localhost:80 user@server

    Use this to access services on a remote host that are only available there

  • Forward port 80 from yourlocalhost to 8888 on a remote host

    ssh -fnN -R8888:localhost:80 user@server

    Use this to allow ther users to access your services: webserver, or whatever.

Cheers! :)

  • 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? – Beachhouse May 21 '13 at 12:30

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.