wiki:doc/SshPortForwardedTor

  • Copyright (c) 2005 tyranix

Using Tor on a remote machine through ssh

Note: These instructions should work for any unix-like system. I happen to be running this setup with a local Debian client and a remote OpenBSD machine.

Using SSH port forwarding, you can set it up so that you can connect to a Tor client on a remote machine through SSH.

I started using this method because I have a remote system that I SSH into. While it's not directly tied to this page, it shows you why you may want to run a Tor client on a remote machine.

Remember, in this example port 8118 is typically Privoxy which in earlier examples chain through to tor on port 9050.

Existing SSH setup

  • System irchost is a remote machine in your local LAN, assume an IP 10.0.0.4.
  • System browserhost is the client machine you are currently using.

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

On browserhost, generate an SSH public/private key pair

Generate an SSH protocol 2 key.

Paranoid setup. 1024 is fine, but what's a few cycles here or there?

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

and be sure to give it a good passphrase.

This will create a files ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa. You must ONLY transfer ~/.ssh/id_rsa.pub to any machine you want to connect to. The machines you want to login to just need your public key. You should store ~/.ssh/id_rsa on machines you trust and you want to connect with to other remote hosts.

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.

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

Note, your usernames on browserhost and irchost do not have to match. In my case, they do not.

It is best practice to make everything related to ssh for user on irchost is readable only by that user:

user@browserhost % chmod 0700 ~/.ssh
user@browserhost % chmod 0600 ~/.ssh/id_rsa ~/.ssh/id_rsa.pub ~/.ssh/known_hosts
diffuser@irchost % chmod 0700 ~/.ssh
diffuser@irchost % chmod 0600 ~/.ssh/authorized_keys ~/.ssh/known_hosts

On browserhost, try to login to irchost

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

Optional: On irchost, disable password logins

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.

Once you know that you can login through public key authentication, you can disable password authentication in /etc/ssh/sshd_config.

Make sure this is either commented out (default is `yes') or uncommented with yes:

#PubkeyAuthentication yes

Now you can turn off tunneled plain text passwords:

PasswordAuthentication no

You can also turn off S/KEY (one time password) authentication:

ChallengeResponseAuthentication no

Kerberos GSSAPI authentication is off by default

#KerberosAuthentication no
#GSSAPIAuthentication no

Logging in from browserhost to irchost without pubkey authentication

With the above changes, if you try to login to a system with the wrong public key, it will deny access:

The item(s) in parentheses indicate which authentication methods are accepted.

Permission denied (publickey).

It is important to note that while the usernames do not have to match, you must have the right username. Because these public keys are stored on a per-user basis, if you enter the wrong username, SSH will not be able to authenticate you. It must look at $USER/.ssh/authorized_keys.

Setup on irchost

Visit OpenbsdChrootedTor for instructions on how to setup a chrooted Tor client for OpenBSD. I'll later write a howto on systraced Tor and finally a chrooted, systraced Tor. If you're more paranoid than that, 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 data into the Tor network.

The problem is, it's only useful for that machine. In my case, "that machine" is my IRC machine, irchost. Since I generally browse the web on browserhost, I want to use irchost as a gateway to the Tor network. This also means I'm only running Tor on one computer which means one less potential exploit for browserhost.

Running a web browser on browserhost that uses irchost's Tor client

There are many reasons why you would want to have this setup. You could be connecting from a Microsoft client where you don't want to run the risk of having a Tor client local.

In my case, I use an ssh connection into irchost to run a screen session where one window runs Irssi. Using this setup, I can disconnect/reboot/power off my client machine browserhost and it will irchost keeps my connection up. I don't want the security hazard of running Tor on browserhost, so I want to connect to the Tor client on irchost.

This may sound bad for Tor, but it's not a critique against Tor. It's best to segregate all network services that you can so the damage is localized.

Tell SSH to connect to a remote port

I'm sure it will take you a while to complete the above because it took me a while to write it. Once you are done with that, the actual forwarding is very easy.

Here's the basic idea: I tell SSH to setup a port on my machine browserhost such that when I send data to it, SSH transparently transfers this data to another machine:

user@browserhost % ssh -2 -l username -L 6677:127.0.0.1:8118 irchost

I'm on browserhost where I want to run Mozilla using Tor. I don't want to run Tor on browserhost because it's already running on irchost.

On browserhost, SSH sets up a localhost:6677 listening for connections.

When I connect to localhost:6677, SSH forwards the data to irchost.

irchost in turn sends the data to it's localhost:8118 where Privoxy is running. Privoxy in turn cleans the HTTP traffic and sends it through the Tor network.

Using the SSH tunnel

While it may sound complicated, it's very easy to use:

In one window, type:

user@browserhost % ssh -2 -l diffuser -L 6677:127.0.0.1:8118 irchost

and then in another window, type

user@browserhost % export http_proxy=http://127.0.0.1:6677/
user@browserhost % lynx http://www.junkbuster.com/cgi-bin/privacy

My lynx program on browserhost is now connecting to irchost (which sends data to privoxy then to Tor) so that my IP displayed is a Tor node.

Last modified 4 years ago Last modified on Dec 25, 2012, 11:28:14 AM