Tornet on a remote machine via ssh
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.
the ssh setup presumed here
- System irchost is a remote machine in your local LAN, assume an IP
10.0.0.4on 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
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:
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':
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:
- One could be connecting from a Microsoft client where one does not want to run the risk of having a Tor client local.
- 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.
- 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.
- 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
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.
- ssh conn hints
source: torproject rewrite of a 2005 article with updated info & crap cut.