|
|
[[TOC]]
|
|
|
|
|
|
* 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. |
|
|
\ No newline at end of file |