Skip to content

Installing and controlling a Tor relay on Linux via command line only

Tor say they are always looking for more people to run nodes for their network, yet oddly enough they don’t provide really simple/straightforward instructions to get a relay working without their GUI, which would be the method of choice for server owners. It is however not too complicated, and here’s a tutorial that should give enough details for people not willing to think at every step. I used Ubuntu 11.10, for other distributions I guess the main differences will be in the way to deal with the package manager.

Dealing with package manager stuff

The first step is to configure the package manager to use Tor’s repository, because distribution repositories are, as you know, always outdated. On this part, the Tor project documentation (for Ubuntu and Debian) is good enough (NB: here is the page for Fedora / CentOS / SUSE). Basically:
nano /etc/apt/sources.list
and at the bottom, add (for Ubuntu 11.10):
deb oneiric main
You can now proceed to installation:
apt-get install tor tor-geoipdb

Editing the configuration file (torrc)

Installing Tor this way also starts it, but the default configuration is not to relay any traffic. We now need to configure is as a relay. The configuration file to edit is usually, as mentioned there, /etc/tor/torrc:
nano /etc/tor/torrc
In this file, the settings you’ll want to look at are:

  • uncomment Log notice file /var/log/tor/notices.log if you want to avoid a notice in ARM (see below for what ARM is)
  • uncomment ControlPort 9051 so that ARM can be used to control and monitor Tor
  • uncomment ORPort and (optionally but recommended, I guess) change its value to some random available port. That’s the port that will be used by other nodes to connect to yours
  • optionally uncomment Nickname and give a name to your node
  • set RelayBandwidthRate and RelayBandwidthBurst. Those are the maximum bandwidth that can be used by Tor constantly and in burst, respectively. For instance:
    RelayBandwidthRate 5000 KB  # Throttle traffic to 100KB/s (800Kbps)
    RelayBandwidthBurst 7000 KB # But allow bursts up to 200KB/s (1600Kbps)

    Beware those values are in Bytes, not bits.

  • if you have a traffic quota (and don’t want to blow it), you’ll want to configure AccountingMax and AccountingStart
  • optionally, you can put your name and (spam protected) e-mail, or even your GPG fingerprint, in ContactInfo. According to the comments it can be used to contact you in case your node goes wild or something.
  • optionally, you can also configure DirPort to mirror directory information on this port.
  • finally, the most important part: choose whether you want to be just a relay or an exit node. To be just a relay, set:
    ExitPolicy reject *:*
    To be an exit node, you can either leave at is, or replace the default exit policy (in order to do the later, do read the instructions carefully). Note that being an exit can bring you trouble because there’s always a risk of abuse, so at least do check your country’s law, the law of your host’s country, and your host’s TOS. But I guess you’re already aware of that anyway.

Additionally, if you want to remotely use your node to enter the Tor network to surf yourself, well, I suppose it can be configured using SocksPort, SocksListenAddress, SocksPolicy accept and SocksPolicy reject, but I haven’t figured out how to do that yet :/

ARM: a terminal-friendly GUI

Last step, let’s install a nice piece of helper software called ARM (for “anonymizing relay monitor”), which is basically a nice console-based GUI to monitor and have some control over Tor. On Ubuntu 11.10 it’s as simple as:
apt-get install tor-arm

In order to use ARM, you’ll have to enable Tor control port first. You already entered it in the configuration file (if you followed the guide properly, at least), so we just need to apply the configuration:
/etc/init.d/tor reload

Now you can just type arm to launch ARM and view some neat information about your node, like the traffic graph, inbound and outbound nodes, etc.

Bonus: what’s a stable node, what’s a guard node?

A little bonus, because that’s something that puzzled me for a while: on some Tor node listings, you can see that servers have flags, notably some servers are flagged as “guard” and some are flagged as “stable”. If you’re curious about what it means, here it is, right from the specification:

"Guard" -- A router is a possible 'Guard' if its Weighted Fractional
Uptime is at least the median for "familiar" active routers, and if
its bandwidth is at least median or at least 250KB/s.

	To calculate weighted fractional uptime, compute the fraction
	of time that the router is up in any given day, weighting so that
	downtime and uptime in the past counts less.

	A node is 'familiar' if 1/8 of all active nodes have appeared more
	recently than it, OR it has been around for a few weeks.

"Stable" -- A router is 'Stable' if it is active, and either its Weighted
MTBF is at least the median for known active routers or its Weighted MTBF
corresponds to at least 7 days. Routers are never called Stable if they are
running a version of Tor known to drop circuits stupidly.  (
through are stupid this way.)

	To calculate weighted MTBF, compute the weighted mean of the lengths
	of all intervals when the router was observed to be up, weighting
	intervals by $\alpha^n$, where $n$ is the amount of time that has
	passed since the interval ended, and $\alpha$ is chosen so that
	measurements over approximately one month old no longer influence the
	weighted MTBF much.

	[XXXX what happens when we have less than 4 days of MTBF info.]

Sources (other than those already mentioned in the text):

Posted in cryptography, privacy, servers, Tor.

7 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. patheticcockroach says

    Quick update: I just saw in the stats someone arriving here looking for “tor relay running but not enough traffic”. Well, you just need to let your node run for a while: as the network finds it more and more stable, your traffic will increase. I think it will take a few days, maybe a week, before you actually max out your available bandwidth (you might want to check out your node flags in ARM: once you get the “Stable” flag then you’re in real business ;))

  2. Wildstar says

    When I try to start ARM I get this:
    [Errno 13] Permission denied: ‘/var/run/tor/control.authcookie’

    Any ideas?

    • patheticcockroach says

      Sorry, never had this one. I suppose you could try, just this once, running ARM as root and see how it goes. Now that I think of it, I think I always run ARM as root. They say it’s bad, but well, I don’t really do it often anyway.
      Maybe you could also chmod 777 /var/run/tor/control.authcookie

      • RedCore says

        thanks, chmod 777 /var/run/tor/control.authcookie fixed my problem

  3. patheticcockroach says

    To the person who wanted to post about tor-arm: sorry the anti-spam plugin (Stop Spammer Registrations Plugin) is so bugged that it didn’t even record your IP so I can’t whitelist you. However it seems that you were caught by said anti-spam plugin, which means you managed to pass the CAPTCHA in the first place (right?). I now disabled the Stop Spammer Registrations Plugin so you should be able to post.

    Otherwise you can just send your comment to my e-mail ( – I’m sure you can figure what to replace “domainname” with 😉 ) and I’ll post it on your behalf. I’ll see if I can find a replacement CAPTCHA which provides an audio version…

  4. dj8f says

    # /etc/init.d/tor reload
    [….] Reloading tor configuration (via systemctl): tor.servicetor.service is not active, cannot reload.

    What could that be?

    • patheticcockroach says

      Hm, never had that one. Looks like the service isn’t running (or even properly installed?). So maybe try /etc/init.d/tor restart instead?

Some HTML is OK

or, reply to this post via trackback.

Please solve the CAPTCHA below in order to fight spamWordPress CAPTCHA