Tor-tunnel

Tornet on a remote machine via ssh

Using ssh port forwarding, we can connect to a Tor proxy on a remote machine - rather than running tor locally, say inside of TorBrowserBundle ("TBB").

   Here we use both a http-proxy as well as a remote tornet-proxy for anon web-surfing secured by ssh

Motivation: This method clearly is tedious to set up (more so than an ssh tunnel), difficult to maintain, introduces many possible points of failure, introduces a shitload of new passwords in danger of being forgotten, adds complexity, is hard to understand and operate. Privoxy is bound to break a number of websites. So why do it? Some will reject the notion of the tor-ssh-tunnel and just stick with the TorBrowserBundle having almost the same benefits. For some others, the extra workload might seem OK, for example if they already have fully deployed and available a remote host to ssh into. Also, users on a MS-windows PC might not want to run Tor locally as to not run into any shenanigan by the vendor or attacker.

These instructions should work for any UNIX-like system and Linux in particular. This HOW-TO was tested with a local Debian-Linux plus a remote openBSD-UNIX host.

Note: Here, listening on port number 8118 is typically Privoxy, which is a proxy like Squid is one. (8118 Might in other, unrelated, separate setups chain through to tor on port 9050)

the ssh setup presumed here

• System irchost is a remote machine in your local LAN, assume an IP 10.0.0.4 on which to possibly conduct IRC
• System browserhost is the client machine you are currently using while sitting physically in front of it.

This will be setup so that only public key access is granted. This means that anyone who wants to connect to irchost must have a private key on the client machine that corresponds to a public key stored on irchost. Since it is currently computationally infeasible to generate a private key given the public key (albeit easy to do it the other way around), this is one of the best methods for connecting to an SSH machine. If you login to a compromised ssh server and use password authentication, they can view your password because it is still a plain text password but it is tunneled between the client and server. With public key authentication, the server asks you to prove that you have the private key corresponding to a public key it knows about. It will not ask you for the private key. A compromised server cannot use your login information to further compromise more machines even if you use the same public key at other locations. Not only does each connecting client need to have a private key corresponding to a public key stored on irchost, but you can also add a password for the private key. People who hate to have gazillions of passwords will not do that of course.

on browserhost, generate an SSH public/private key pair

Generate an SSH protocol 2 key.

user@browserhost % ssh-keygen -b 4096 -t rsa -C browserhost

with or without a passphrase (up to you, mate!). This will create a files ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa.

Only do transfer ~/.ssh/id_rsa.pub to any machine you want to connect to, and keep the other of the 2 files created by ssh-keygen as a secret locally. The machines you want to login to just need your public key. You should store ~/.ssh/id_rsa , which is the secret ssh key, on machines you trust (say, your own laptop compy rather than a machine in an internet-café). Then, with said laptop you might want to connect to other remote hosts, e.g. a rental VM at Linode or whereever. You end up with sth. like this:

File: ~/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1y...(you get the idea)...PnRqKxUcw== browserhost

on browserhost, transfer the public key to irchost

Since irchost needs to know when a valid private/public key combination tries to connect, it must store the public keys.This is the setup if this is your first key. When you store multiple public keys (because you want to allow multiple private keys to connect), just concatenate the keys into the file ~/.ssh/authorized_keys.

  scp -2 ~/.ssh/id_rsa.pub diffuser@irchost:~/.ssh/authorized_keys

Your usernames on browserhost and irchost do not have to be the same ones, because anyone can ssh into any host posing as anybody. It is good practice to make everything related to ssh for user on irchost readable by that particular user only:

                   chmod 0700 ~/.sshuser@browserhost 
                   chmod 0600 ~/.ssh/id_rsa ~/.ssh/id_rsa.pub ~/.ssh/known_hosts

and as diffuser@irchost issue:

                   chmod 0700 ~/.sshdiffuser@irchost 
                   chmod 0600 ~/.ssh/authorized_keys ~/.ssh/known_hosts

on browserhost ssh into irchost

Try logging into irchost via ssh . By default, public key authentication will be tried first and it will fall back to passwords if that fails.

disable password login on irchost (optional)

Before you do this, make sure you can login to root (either directly or with another account via su) and your other user accounts. If the machine is not physically close to you, it will be a pain to access when not setup properly. There is potential for locking yourself out of your own server even when you kept the password. Once you ascertained that you can login through public key authentication, you can disable password authentication in /etc/ssh/sshd_config in order to keep out adversaries. Make sure the relevant option is either commented out (default is 'yes') or uncommented with 'yes':

File: /etc/ssh/sshd_config

#PubkeyAuthentication          yes # is active ("yes") by default or turn it on explicitly by removing the # character
PasswordAuthentication          no # Now you can turn off plain text passwords - in favour of our new "pubkeys"
ChallengeResponseAuthentication no # You can also turn off S/KEY (one time password) authentication
#KerberosAuthentication         no # Kerberos GSSAPI authentication is off by default
#GSSAPIAuthentication           no

ssh from browserhost into irchost with an authorized key

With the above changes - we conducted the so-called "key management" - if we ssh into a system with the wrong public key file in place then the dreaded remote sshd will deny access; the item(s) in parentheses indicate which authentication methods are accepted:

    Permission denied (publickey)

Note that while the usernames do not have to be the same word on both ends, you must have the correct username for the particular target machine. These public keys are stored on a per-user basis. If you enter the wrong username, the sshd will not be able to authenticate you against $USER/.ssh/authorized_keys and may not give you 2 secondy chance in the shape of a password prompt.

setup on irchost

Visit OpenbsdChrootedTor for instructions on how to setup a chrooted Tor client for OpenBSD. If you're kinda paranoid, you should probably resort to auditing all of the Tor code (and your OS etc). After following those instructions, you will have a Tor client listening on localhost:9050 for connections to forward to Tor, and localhost:8118 for connections to Privoxy which sanitizes HTTP traffic and sends cleaned data into the Tor network. This cleanliness is for the IRC machine called irchost. Assuming one generally browses the web on browserhost, one wants to use irchost as a gateway to the Tor network, running Tor on one computer only. So, less potential of exploits against browserhost, one might reckon.

websurfing on browserhost using Tor on irchost

Several reasons could be quoted for why one might want to have this setup:

1. One could be connecting from a Microsoft client where one does not want to run the risk of having a Tor client local.
2. We could use an ssh connection into irchost to run a screen session (screen here being a program like XTerm or KDE Konsole) where one window runs Irssi. Using this setup, one can disconnect/reboot/power off the client machine browserhost but irchost will keep the connection alive.
3. We don't want the security hazard of running Tor on browserhost, so we want to connect to a Tor which is running on irchost instead. Here we segregate some network services that so a potential damage will hopefully be localized.
4. Depending on the particular threat model at hand, this setup may be preferrable or not.

Tell SSH to connect to a remote port

The actual forwarding has this basic idea: tell ssh to set up a port on machine browserhost such that when we send data to it, ssh transparently forwards this data to some other machine:

     ssh -2 -l username -L 6677:127.0.0.1:8118 irchost

On browserhost we want to run a Firefox using Tor. We do not run Tor on browserhost because it's already running on irchost and would otherwise slow down the websurfing even more than it already does.

On browserhost, ssh also known as localhost:6677 is listening for connections. When we connect to localhost:6677, ssh forwards the data to irchost who in turn sends the data to it's localhost:8118 where Privoxy is running. Privoxy cleans the HTTP traffic of anti-privacy stuff and sends cleaned data through the Tor network.

actually using the finished ssh tunnel

While it is hugely complicated, it is quick to use: In one bash window, type:

 ssh -2 -l diffuser -L 6677:127.0.0.1:8118 irchost                   

and then in another window, type

 export http_proxy=http://127.0.0.1:6677/user@browserhost            

 firefox      https://linuxreviews.org/Tor-tunnel#actually_using_the_finished_ssh_tunnel      

Here, the FireFox on browserhost is now connecting to irchost, which sends data to privoxy, then to Tor such that our own IP-address displayed is a Tor node, the so-called exitNode.

see also

• ssh conn hints

source: torproject rewrite of a 2005 article with updated info & crap cut.