ssh-copy-id -p $SSH_PORT user@server
This example config uses the iptables-persistent package, and by default allows world access to a random SSH port 23942 and ports 80,443 which we use for Tor. Think about limiting SSH to an IP (range) you can connect from, or use portknocking. Also, this config is optimized for high bandwidth relays: in order to avoid the conntrack module, it allows all UDP in.
sudo apt install iptables-persistent cd /etc/iptables wget -O iptables.v4 https://raw.githubusercontent.com/torservers/server-config-templates/master/iptables.test.rules # you need to at least customize SSH port in it now or you will lock yourself out... # for ipv6, add rules in /etc/iptables/iptables.v6 service iptables-persistent start
# configure hostname hostname yourservername.xyz vi /etc/hostname # also use yourservername.xyz vi /etc/hosts # update to yourservername.xyz yourservername # disable debian default that pulls in recommended packages: cd /etc/apt/apt.conf.d wget https://raw.githubusercontent.com/torservers/server-config-templates/master/06norecommends apt update && apt full-upgrade apt install sudo git less htop nload screen \ ntp apticron vnstat logcheck logcheck-database lsb-release apt remove --purge portmap sed -i -e 's/^# DIFF_ONLY/DIFF_ONLY/' /etc/apticron/apticron.conf # make apticron send diffs only vnstat -u -i eth0 # setup vnstat for correct interface cd /etc mv aliases aliases.dist wget https://raw.githubusercontent.com/torservers/server-config-templates/master/aliases sed -i 'firstname.lastname@example.orgemail@example.com/' /etc/aliases newaliases
We upgrade from all available package sources, let it reboot if necessary, and send mail on errors. A reasonable configuration could be to limit upgrades to the security sources. (see comments in 50unattended-upgrades)
apt install unattended-upgrades update-notifier-common wget -p -O /etc/apt/apt.conf.d/50unattended-upgrades https://raw.githubusercontent.com/torservers/server-config-templates/master/50unattended-upgrades cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades # enable
# codename of current distribution DIST=`lsb_release -sc` # add tor sources echo "deb http://deb.torproject.org/torproject.org $DIST main" > /etc/apt/sources.list.d/torproject.list # only add experimental if you're on tor IRC/familiar with it echo "deb http://deb.torproject.org/torproject.org tor-experimental-0.3.3.x-$DIST main" >> /etc/apt/sources.list.d/torproject.list gpg --keyserver keys.gnupg.net --recv 886DDD89 # if down use eg. keyserver.ubuntu.com gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add - sudo apt update sudo apt install deb.torproject.org-keyring
apt install tor tor-geoipdb service tor stop cd /etc/tor rm * wget https://raw.githubusercontent.com/torservers/server-config-templates/master/torrc wget https://raw.githubusercontent.com/torservers/server-config-templates/master/tor-exit-notice.html # customize # for multi-process installations, use tor-instance-create
We have simplified our setup and are currently not using a standalone webserver on our relay servers.
You can generate local graphs and render them as images with vnstati. You could serve these images with a webserver. We don't use this any longer.
apt install vnstati # create empty files in root-owned /var/www and change owner to www-data cd /var/www touch vnstat.png vnstat_d.png vnstat_m.png vnstat.xml chown www-data:www-data vnstat*.* # set up cron job crontab -u www-data -e
*/10 * * * * /usr/bin/vnstati -vs -o /var/www/vnstat.png -i eth0 >/dev/null 2>&1 ;fi */10 * * * * /usr/bin/vnstati -d -o /var/www/vnstat_d.png -i eth0 >/dev/null 2>&1 ;fi 1 3 * * * /usr/bin/vnstati -m -o /var/www/vnstat_m.png -i eth0 >/dev/null 2>&1 ;fi 1 3 * * * /usr/bin/vnstat --xml > /var/www/vnstat.xml 2>/dev/null ;fi
apt install unbound vi /etc/resolv.conf # insert top: nameserver 127.0.0.1
Install munin-node and allow remote access from our webserver that runs munin to gather statistics at 126.96.36.199 ( https://www.torservers.net/munin/ ). munin-node is the “client side component”. You might also be interested in the munin "server side component" configuration.
apt install -y munin-node ln -s /usr/share/munin/plugins/netstat /etc/munin/plugins/netstat rm /etc/munin/plugins/http_loadtime rm /etc/munin/plugins/ntp_* rm /etc/munin/plugins/postfix_* rm /etc/munin/plugins/exim_* sed "s/allow \\^127\\\.0\\\.0\\\.1\\$/allow ^81\\\.7\\\.13\\\.16$/" -i /etc/munin/munin-node.conf /etc/init.d/munin-node restart
You might also be interested in this tor-relay thread regarding high speed relay tweaks: How to Run High Capacity Tor Relays
In general, as with all optimizations: you should only apply those that are necessary for you.
Currently, Tor does not scale on multicore CPUs. If the CPU supports AES-NI crypto extensions (most modern CPUs do), one Tor process is able to handle around 400 Mbps of throughput – without AES-NI, around 100 Mbps. If your connection supports more, you will need to run multiple Tor processes. For this, on current Debian/Ubuntu releases, Tor comes with a helper to manage multiple instances.
Note that running more than two tor processes per IP address will result in those other nodes not being used on the network. You'll see the following message in your logs:
[notice] Heartbeat: It seems like we are not in the cached consensus.
tor-instance-create <name> # torrc for new instance is in /etc/tor/instances/<name>/torrc systemctl enable tor@<name> # create symlinks for auto-launch of the new instance systemctl start tor@<name>
Done! You should not manually configure DataDirectory or PidFile in the torrc like before.
Please only tweak kernel settings when necessary! Don't change all at once, pick the ones that make sense and try them one by one over several weeks. Monitor changes carefully.
cd /etc mv sysctl.conf sysctl.conf.dist wget https://raw.githubusercontent.com/torservers/server-config-templates/master/sysctl.conf # go through the settings once again! some only useful with large memory and CPU # better tweaking probably possible; magic involved sysctl -p
Set MaxBandwidth to line maximum, eg. for GBit:
sed "s/MaxBandwidth 100/MaxBandwidth 1000/g" -i /etc/vnstat.conf /etc/init.d/vnstat restart # don't reload; will stop vnstat from updating its db...
Might be useful in some cases. Only optimize when you need to!
# remove "exit" from rc.local, then echo 'ifconfig eth0 txqueuelen 20000' >> /etc/rc.local # Play with it. For GBit I've found values between 8000 and 16000 to be very useful, but it is hardware dependent
Recent Intel CPUs and upcoming AMDs support a native AES crypto acceleration extension called AES-NI. It is well worth enabling and will save a lot of CPU cycles.
Many motherboards ship with AES-NI disabled. You can check if it is enabled:
# cat /proc/cpuinfo | grep aes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 x2apic popcnt aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
OpenSSL 1.0.1 and later directly support AES-NI. You should not use older versions of OpenSSL.