- tor-relays - lists.torproject.org

Tor exit nodes attacking SSH?
by Steven Chamberlain 09 Aug '17

09 Aug '17

Hi, I often run my SSH sessions via Tor using tsocks. But today I see: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a. Further investigation shows that this happens for any destination IP address, even where there's no SSH service running: $ tsocks ssh -vC root(a)8.8.8.8 OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 debug1: Reading configuration data /home/steven/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 8.8.8.8 [8.8.8.8] port 22. debug1: Connection established. debug1: identity file /home/steven/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_rsa-cert type -1 debug1: identity file /home/steven/.ssh/id_dsa type 2 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/steven/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 debug1: Remote protocol version 2.0, remote software version dropbear_2015.67 debug1: no match: dropbear_2015.67 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-sha2-256 zlib(a)openssh.com debug1: kex: client->server aes128-ctr hmac-sha2-256 zlib(a)openssh.com debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a The authenticity of host '8.8.8.8 (8.8.8.8)' can't be established. RSA key fingerprint is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a. Are you sure you want to continue connecting (yes/no)? : I could be wrong, but I think this "dropbear" service is most likely something malicious, running on one or more Tor exit nodes, attempting to collect passwords of people logging in this way. If a user ignored the error (or trusts the fingerprint without verifying), their password, and further activity on the shell could all be captured by the attacker. Since Tor makes my client connections anonymous, and the dropbear is seen even for hosts that don't provide an SSH service, makes me think this attack is indiscriminate, not targetted only at me or my servers. The first time you connect to some machine, be careful to verify the fingerprint through independent means. Pay attention to notices like this of changed key fingerprints. And if you haven't already, disable PasswordAuthentication to something that cannot be intercepted (like authorization of private RSA/ECDSA keys). Regards, -- Steven Chamberlain steven(a)pyro.eu.org

7 8

obfs4proxy for FreeBSD and OpenBSD
by George 09 Aug '17

09 Aug '17

We just did a blog post on obfs4proxy for FreeBSD and OpenBSD on the TDP blog: https://torbsd.github.io/blog.html#welcome-obfs4 Feedback welcome, offline or via GitHub. In the near future, we'll submit to the respective ports systems. g -- 5F77 765E 40D6 5340 A0F5 3401 4997 FF11 A86F 44E2

1 0

Re: [tor-relays] Fwd: Your TOR relay
by Dennis Emory Hannon 08 Aug '17

08 Aug '17

No attitude or hurt feelings. What's different from my servers compared to others? Probably nothing at all..this is just a hobby of mine. One would think if I wanted to collect information I would just run an exit node myself since I have the resources. For those that want an alternative no logging DNS: 172.98.193.42 162.248.241.94 For those that don't, No worries at all, we'll be here if you change your mind. :D Cheers! -Dennis https://www.linkedin.com/in/dennis-hannon-52236019/ +1 (585) 735-5996

4 3

Tor 0.3.0.10 not listed as a recommended version
by Ralph Seichter 08 Aug '17

08 Aug '17

Hello, after updating to Tor 0.3.0.10, I see the following warning on my nodes: This version of Tor (0.3.0.10) is newer than any recommended version in its series, according to the directory authorities. Could one of the devs please update the relevant data? Thanks. -Ralph

5 11

ORSN DNS servers vs OpenNic
by Chuck McAndrew 08 Aug '17

08 Aug '17

What are the best DNS servers to use for Privacy? I have been using OpenNic Project servers which don't do logging, but recently found out about the Open Root Server Network (ORSN) and have been considering using them as well. Does anyone have any thoughts, positive or negative, about either of these? Are there better public DNS servers to use? Thanks Chuck -- *The Right-To-Know Law provides that most e-mail communications, to or from Lebanon Public Libraries employees regarding the business of the library, are government records available to the public upon request. Therefore, this e-mail communication may be subject to public disclosure. *

10 13

Re: [tor-relays] Fwd: Your TOR relay
by Dennis Emory Hannon 08 Aug '17

08 Aug '17

Tom, That's a completely false statement. Some folks would rather choose an alternate root caching server as opposed to their ISP's DNS. In fact, no logging and anonymity is the sole intention of the servers mentioned. You're crying wolf here. If you don't want to use it, don't. Simple as that. I'm a software engineer for a financial intuition here. I have nothing to gain. It actually COSTS me money to run. -Dennis

2 1

Go home GeoIP, you're drunk.
by Ralph Seichter 07 Aug '17

07 Aug '17

I moved a Tor relay to new hardware, keeping the keys. Both old and new server are located in Germany and provided by the same hosting company. After the latest Atlas update, I was surprised to see that the IPv4 address is listed as belonging to an AS in Ukraine. A little more digging returned Guangzhou, China, as the supposed location based on the server's IPv6 address. Is there anything I can/should do about this (I doubt it)? Will this affect my Tor node consensus weight? As it is not an exit node, I am hoping it won't matter much. -Ralph

7 9

HOW-TO: Simple DNS resolver for tor exit operators
by Dennis Emory Hannon 07 Aug '17

07 Aug '17

Hello friends, I decided to make a quick starter guide to introduce using a local resolver for tor-exit node operators. I'd like to solicit some of your feedback on things that should be added or improved upon. Hopefully this will be a living document - My goal is to help lower the amount of TOR exit relays using 3rd party DNS providers for client DNS lookups. While it doesn't address all security concerns, it's a necessary step to improving anonymity of TOR's users. Let me know what you think. Guide is meant for debian/linux users http://backplanedns.org/TOR_exit_dns_resolver_howto.htm -Dennis

6 6

Tor relay operators at SHA2017 ?
by Schroedinger 07 Aug '17

07 Aug '17

Hi relay operators, if anyone at SHA2017 is interested in meeting up, perhaps we could set up a self-organized session for Tor relay operators.

4 5

Re: [tor-relays] Tor relay operators at SHA2017 ?
by Alexander Dietrich 07 Aug '17

07 Aug '17

There is a self-organized session now: https://wiki.sha2017.org/w/Session:Tor_Relay_Operators_Meetup Cheers, Alexander Sent from my toasterOn Aug 5, 2017 5:46 PM, Alexander Færøy <ahf(a)0x90.dk> wrote: > > On 1 August 2017 at 21:24, Schroedinger <schroedingers_cat(a)riseup.net> wrote: > > if anyone at SHA2017 is interested in meeting up, perhaps we could set > > up a self-organized session for Tor relay operators. > > I'm here as well. I'll happily meet and talk about Tor! > > Cheers, > Alex. > > -- > Alexander Færøy > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Fwd: Your TOR relay
by Tom van der Woerdt 07 Aug '17

07 Aug '17

:-( If you got this mail as well, please don't fall for it. You'd be exposing Tor users' browsing data. Tom -------- Doorgestuurd bericht -------- Onderwerp: Your TOR relay Datum: Sun, 6 Aug 2017 21:19:32 -0400 Van: Dennis Hannon <dennis.hannon(a)backplanellc.com> Aan: Dennis Hannon <dennis.hannon(a)backplanellc.com> Hello, I came across your TOR relay on atlas. I run a few relays myself along with a bunch of DNS resolvers which are a part of the Open Root Server network (ORSN.org) - aimed to fight internet censorship and circumvent government surveillance programs (ie. prism). I hope you may be interested in using our anonymous open DNS resolvers on your node. http://BackplaneDNS.org Resolver - 172.98.193.42 Resolver - 162.248.241.94 ------------------------------------------------------ Hostmaster@: Mr. Dennis Emory Hannon Phone: +1 (585) 735-5996 E-Mail: info(a)backplanedns.org abuse(a)backplanedns.org

1 0

prop224 warning
by Logforme 03 Aug '17

03 Aug '17

Saw a new thing in my tor log today: Aug 01 11:07:27.000 [warn] Established prop224 intro point on circuit 799774346 According to google, prop224 is a new hidden service protocol? https://trac.torproject.org/projects/tor/ticket/12424 Which sounds like a great thing. But why do I get a warning about it? My relay: https://atlas.torproject.org/#details/855BC2DABE24C861CD887DB9B2E950424B49F…

2 2

freebsd-ports; tor, obfs4, browser & socks
by Vinícius Zavam 02 Aug '17

02 Aug '17

hello everyone, I'm writing to inform that our efforts to keep sharp with Tor support on FreeBSD are still alive. although we (TDP, https://torbsd.github.io) would like to call more people to help testing these ports we changed and created. the signed source code is available at https://github.com/torbsd/freebsd-ports/releases/tag/tdp sorry for the superficial bump, cross-posting and not much detailed email. kr, -- Vinícius Zavam keybase.io/egypcio/key.asc

1 0

MyFamily consensus byte savings
by grarpamp 02 Aug '17

02 Aug '17

Consensus could save ~500kB (3%) by clients automatically swapping MyFamily from config plaintext format to bitmap selection from DA provided list of recently seen node FP's before publishing descriptor.

2 1

Want to help test 'Sandbox 1'? (Linux only)
by nusenu 02 Aug '17

02 Aug '17

Hi, I'm aiming to enable tor's 'Sandbox' feature by default on Debian based relays starting with the next release of ansible-relayor [1]. Before doing so I'd like to collect some feedback from tor relay operators willing to test this feature. If you - run tor 0.3.0.x >= 0.3.0.8 - are on Linux - willing to report proplems it would be greate if you could add the following line to your torrc configuration file: Sandbox 1 Ideally you have also a system monitoring in place that tells you whether this config change has any impact (i.e. on CPU or bandwidth). [1] https://github.com/nusenu/ansible-relayor -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

5 6

Util helping maintain MyFamily
by Ryru 02 Aug '17

02 Aug '17

Hello Everyone I wrote a bash script helping maintaining the MyFamily string in torrc. The idea is to have one single file with all relay nicknames and there fingerprints and generate the MyFamily string uniquely for every node in the family. You will find a copy here: https://github.com/ryru/myfam If you like a bit more background check out: https://blog.addere.ch/2017/07/13/myfam-a-utility-helping-you-maintaining-y… Hope this helps anyone! cheers pascal

2 1

Debian9 install gpg repository problem
by Petrusko 01 Aug '17

01 Aug '17

Hey! I've set up quickly a Debian9 on a Windows Virtualbox. When trying to follow the guide here "Option two: Tor on Ubuntu or Debian" https://www.torproject.org/docs/debian.html.en#ubuntu The first command line result is (root account used) : # gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 gpg: failed to start the dirmngr '/usr/bin/dirmngr': Aucun fichier ou dossier de ce type gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: Aucun fichier ou dossier de ce type gpg: keyserver receive failed: Pas de dirmngr -- Petrusko C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

2 2

[warn] assign_to_cpuworker failed. Ignoring.
by Ybslik 01 Aug '17

01 Aug '17

Hi All, Me - 9D60A484CFBDB5B890FB5B18941494734584BA17 Have just had this occur to me - Copy of my torrc log Jul 31 14:37:34.000 [notice] Heartbeat: Tor's uptime is 32 days 23:28 hours, with 1287 circuits open. I've sent 901.91 GB and received 900.57 GB. Jul 31 14:37:34.000 [notice] Average packaged cell fullness: 70.114%. TLS write overhead: 2% Jul 31 14:37:34.000 [notice] Circuit handshake stats since last time: 3487/3487 TAP, 60593/60593 NTor. Jul 31 14:37:34.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 900860 v4 connections; and received 3504 v1 connections, 254 v2 connections, 7 v3 connections, and 1142913 v4 connections. Jul 31 20:37:34.000 [notice] Heartbeat: Tor's uptime is 33 days 5:28 hours, with _41089_ circuits open. I've sent 909.67 GB and received 907.90 GB. Jul 31 20:37:34.000 [notice] Average packaged cell fullness: 72.276%. TLS write overhead: 2% Jul 31 20:37:34.000 [notice] Circuit handshake stats since last time: 3465/3465 TAP, 666475/666475 NTor. Jul 31 20:37:34.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 908239 v4 connections; and received 3548 v1 connections, 254 v2 connections, 7 v3 connections, and 1155164 v4 connections. Jul 31 20:41:57.000 [warn] assign_to_cpuworker failed. Ignoring. Jul 31 20:41:57.000 [warn] assign_to_cpuworker failed. Ignoring. Jul 31 20:41:57.000 [warn] assign_to_cpuworker failed. Ignoring. Jul 31 20:41:57.000 [warn] assign_to_cpuworker failed. Ignoring. Jul 31 20:41:57.000 [warn] assign_to_cpuworker failed. Ignoring. Jul 31 20:41:57.000 [warn] assign_to_cpuworker failed. Ignoring. Jul 31 21:49:55.000 [warn] assign_to_cpuworker failed. Ignoring. Jul 31 21:49:55.000 [warn] assign_to_cpuworker failed. Ignoring. I've highlighted the number of circuits in red......never had that many before..... Is there anything I should be doing, Only been up 70 days or so, Thanks I am a novice at everything, especially with Ubuntu and moving around the system Ybslik (Steve Bishop)

2 1

Best configuration for high speed exit relay with limited bandwith (1Tb)
by King Queen 01 Aug '17

01 Aug '17

hi, I have a relatively new VPS on CockBox running a Tor exit node. It's the $10/month one https://box.cock.li/ which means it has very fast network (Gigabit I think) but I can only use 1TB per month. I've done some reading round of previous posts on here over the year, and as a result I have variously tried / toyed with RelayBandwidthRate (set at 150KBps so it averages ~800gb/month) and with AccountingMax (15GB with AccountingStart day 00:00) But I don't know what's best for the network. Is it best to have a very fast exit relay for a small portion of the day (so AccountingMax set but no RelayBandwidthRate), a not-so-fast exit relay for more of the day (so AccountingMax set at 15Gb and RelayBandwidthRate at 250KBps) or a slower-still exit relay for all the day (RelayBandwidthRate 150KBps and no AccountingMax?) What is of the most benefit to the Tor network? Also: I read somewhere that Tor should un-hibernate at a random point each day and not directly at 00:00 as set in AccountingStart, but that doesn't appear to be what happens. It just sets off at midnight. To combat any deleterious effect that lots of people doing this might have on the Tor network, if I do use AccountingMax, should I set AccountingStart to a random time in the day? Thanks - your guidance would be very much appreciated. Doug

2 1

network traffic gap of >=20% between inbount and outbound traffic vanished after 20th of July
by Toralf Förster 31 Jul '17

31 Jul '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I do wonder, what's causing this. As seen in the attachment since the last week incoming load matrches outgoing load. In the last 2-3 years I had always up to 20-25% more in- than outgoing traffic w/o any real clue, why. - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWX4y0BccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTk/LAP9y568uomJ0yF0SEr0a+YUJzRAw wq7knHtTbxinOvdu/wD/TKrwRZznAwCKT1YIlFd4Ac+Pllz7vmtw7orY7EQ9M4M= =pM2Y -----END PGP SIGNATURE-----

2 2

100K circuit request per minute for hours killed my relay
by Felix 31 Jul '17

31 Jul '17

Hi everybody I observed two circuit bursts around July 19th. On a poor server Tor crashed, on a strong it didn't. The logs below are from the crashed one. I'm on FreeBSD. To my mind the circuit burst exhausts the nmbclusters (not memory, Inact tells). Strong servers have more. How long is more enough ? On FreeBSD nmbclusters is a boot tunable. The strong server took 140k circuits for several hours. Is it worth thinking about a Tor setting like MaxCircuitsPerTime ? MaxAdvertisedBandwidth won't help directly. 1) Normal operation kern.openfiles: 5516 Mem: 36M Active, 1288M Inact, 455M Wired, 1452K Cache, 425M Buf, 191M Free Swap: 3072M Total, 3072M Free USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND _tor 87 0 309M 283M RUN 125.7H 50.00% tor{tor} _tor 22 0 309M 283M uwait 167:32 3.96% tor{tor} 2) Last minute before crash: kern.openfiles: 5467 Mem: 296M Active, 935M Inact, 692M Wired, 21M Cache, 425M Buf, 27M Free Swap: 3072M Total, 1592K Used, 3070M Free USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND _tor 85 0 465M 438M RUN 126.8H 43.99% tor{tor} _tor 33 0 465M 438M uwait 186:39 15.97% tor{tor} 3) Crashed: kern.openfiles: 5455 Mem: 295M Active, 936M Inact, 699M Wired, 21M Cache, 425M Buf, 21M Free Swap: 3072M Total, 1592K Used, 3070M Free kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached sysctl kern.ipc.nmbclusters 126138 Heartbeat: Tor's uptime is 15 days 16:00 hours, with 1611 circuits Heartbeat: Tor's uptime is 15 days 17:00 hours, with 40471 circuits Heartbeat: Tor's uptime is 15 days 18:00 hours, with 88052 circuits Heartbeat: Tor's uptime is 15 days 19:00 hours, with 78444 circuits [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. -- Cheers, Felix

3 2

100K circuit request per minute for hours killed my relay
by Pascal Terjan 31 Jul '17

31 Jul '17

Last night for 4h30 (until VPS provider shut it down) one of my middle relays seems to have got in a bad state where it was using 100% CPU continuously It was not using much bandwidth, about 4MB/s, but reading the logs it seems it was getting a lot of circuit requests (70K/minute initially, 100K at the end). Is there anything I can do about it? Jul 20 19:41:20.000 [notice] Heartbeat: Tor's uptime is 157 days 18:00 hours, with 4642 circuits open. I've sent 13916.64 GB and received 13502.43 GB. Jul 20 19:41:20.000 [notice] Average packaged cell fullness: 98.154% Jul 20 19:41:20.000 [notice] TLS write overhead: 2% Jul 20 19:41:20.000 [notice] Circuit handshake stats since last time: 8823/8823 TAP, 112411/112806 NTor. Jul 21 00:52:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [398 similar message(s) suppressed in last 60 seconds] Jul 21 00:53:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [46893 similar message(s) suppressed in last 60 seconds] Jul 21 00:54:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [66339 similar message(s) suppressed in last 60 seconds] Jul 21 00:55:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restrict ed exit policy. [69939 similar message(s) suppressed in last 60 seconds] Jul 21 00:56:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restrict ed exit policy. [73055 similar message(s) suppressed in last 60 seconds] [...] Jul 21 04:19:08.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [101856 similar message(s) suppressed in last 60 seconds] Jul 21 04:20:08.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [97494 similar message(s) suppressed in last 60 seconds]

8 11

Tor relay operators at DEF CON
by Joel Cretan 30 Jul '17

30 Jul '17

Hi relay operators, If anyone at DEF CON is interested in meeting up, perhaps we could set up a meeting time, maybe in/around the Crypto and Privacy Village. Of course we're all interested in anonymity, so no pressure to speak up. But if enough people tell me they're interested, I'll try to organize something. Hope to meet some of you. Joel

4 9

badexit 29378422C99074D06331D5700E47451610B0D20D
by eric gisse 30 Jul '17

30 Jul '17

it looks like i've found an exit node mitm-ing ssh, or at least giving it a shot. https://atlas.torproject.org/#details/29378422C99074D06331D5700E47451610B0D… that exit policy looks more like a wishlist than anything else, at this point. notice all 3 sites have different clear wire ssh keys (obviously) but all the same when connecting over tor. what a coincidence! module code: https://github.com/jowrjowr/exitmap/blob/master/src/modules/sshmitm.py # ./bin/exitmap sshmitm -e 29378422C99074D06331D5700E47451610B0D20D 2017-07-29 16:52:36,797 exitmap [INFO] Attempting to invoke Tor process in directory "/tmp/exitmap_tor_datadir-root". This might take a while. 2017-07-29 16:52:36,798 exitmap [INFO] No first hop given. Using randomly determined first hops for circuits. 2017-07-29 16:52:37,369 util [INFO] Tor Bootstrapped 0%: Starting 2017-07-29 16:52:41,942 util [INFO] Tor Bootstrapped 80%: Connecting to the Tor network 2017-07-29 16:52:41,943 exitmap [INFO] Successfully started Tor process (PID=31779). 2017-07-29 16:52:42,117 exitmap [INFO] Running module 'sshmitm'. 2017-07-29 16:52:42,269 modules.sshmitm [INFO] obtaining ssh key information for destinations 2017-07-29 16:52:42,269 modules.sshmitm [INFO] getting key for github.com 2017-07-29 16:52:42,643 modules.sshmitm [INFO] getting key for gitlab.com 2017-07-29 16:52:42,889 modules.sshmitm [INFO] getting key for bitbucket.com 2017-07-29 16:52:58,807 relayselector [INFO] 216 relays have non-empty exit policy but no exit flag. 2017-07-29 16:52:58,816 relayselector [INFO] 1 out of 1000 exit relays meet all filter conditions. 2017-07-29 16:52:59,080 exitmap [INFO] Scan is estimated to take around 0:00:03. 2017-07-29 16:52:59,080 exitmap [INFO] Beginning to trigger 1 circuit creation(s). 2017-07-29 16:53:02,018 exitmap [INFO] Done triggering circuit creations after 0:00:02.937566. 2017-07-29 16:53:04,169 modules.sshmitm [CRITICAL] tor ssh key mismatch for github.com:22 (192.30.253.112) over exit relay 29378422C99074D06331D5700E47451610B0D20D clear wire value: AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==, over tor value: AAAAB3NzaC1yc2EAAAADAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT 2017-07-29 16:53:05,573 modules.sshmitm [CRITICAL] tor ssh key name mismatch for gitlab.com:22 (52.167.219.168) over exit relay 29378422C99074D06331D5700E47451610B0D20D clear wire value: ssh-ed25519, over tor value: ssh-rsa 2017-07-29 16:53:05,574 modules.sshmitm [CRITICAL] tor ssh key mismatch for gitlab.com:22 (52.167.219.168) over exit relay 29378422C99074D06331D5700E47451610B0D20D clear wire value: AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf, over tor value: AAAAB3NzaC1yc2EAAAADAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT 2017-07-29 16:53:06,957 modules.sshmitm [CRITICAL] tor ssh key mismatch for bitbucket.com:22 (104.192.143.8) over exit relay 29378422C99074D06331D5700E47451610B0D20D clear wire value: AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==, over tor value: AAAAB3NzaC1yc2EAAAADAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT 2017-07-29 16:53:06,959 eventhandler [INFO] Ran 1 module(s) in 0:00:30.168619 and 0/1 circuits failed (0.00%).

2 2

Unable to get Tor exit relay to run - Ubuntu 16.04
by King Queen 28 Jul '17

28 Jul '17

I'd really appreciate some clueful suggestions or help please - thank you. I'm not new to Tor; I have an existing relay I run, https://atlas.torproject.org/#details/ECC3599DDCFE44C3F28AE0C9DC5DE92847D36… , but I am unable to get a new Tor relay up and running on an entirely different VPS. I am running on Ubuntu 16.04 Server on a VPS on https://box.cock.li/ . On first attempt I couldn't get a Tor relay running, so I started again from scratch, getting the VPS administrator to reprovision the VPS from scratch, to no avail. I SSHed in as root, created a user and made it a sudoer, added public key etc. and disabled root admin. Then I SSHed in as the user, installed ntp and ufw, added ports 80 and 443 to ufw, added the Tor respository and key as per https://www.torproject.org/docs/debian.html.en#ubuntu. I installed tor, deb.torproject.org-keyring and arm, and edited torrc such that it reads: SOCKSPort 0 RunAsDaemon 1 ORPort 443 Nickname kingqueencock ContactInfo ROT13 <xvatdhrra(a)ybirf.qvpxvauvfna.hf> DirPort 80 # what port to advertise for directory connections DirPortFrontPage /etc/tor/tor-exit-notice.html MyFamily ECC3599DDCFE44C3F28AE0C9DC5DE92847D3602B then the "alternative Reduced-Reduced ExitPolicy" from https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy then sudo service tor restart. For all I can gather, Tor isn't running. There are no files in /var/tor/log. ps aux | grep tor returns nothing other than the grep command. arm shows the "Welcome to the Tor network!" initial relay configuration screen, as does sudo -u debian-tor arm. sudo service tor status ● tor.service - Anonymizing overlay network for TCP (multi-instance-master) Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2017-07-27 19:36:41 UTC; 3s ago Process: 9781 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 9781 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 512) CGroup: /system.slice/tor.service Jul 27 19:36:41 localhost systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance-master)... Jul 27 19:36:41 localhost systemd[1]: Started Anonymizing overlay network for TCP (multi-instance-master). root@localhost:/var/log/tor# ls -al total 8 drwxr-s--- 2 debian-tor adm 4096 Jul 27 19:29 . drwxr-xr-x 7 root root 4096 Jul 27 19:29 .. The odd thing is if I reboot my VPS by sudo shutdown -r now and do ps aux | grep tor there is tor running as a root user. root 435 0.0 0.5 44760 5716 ? Ss 19:40 0:00 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config I don't know where that has come from, or if it's a problem. I have had a poke around in init.d and systemd but I am not an expert in those. I am beginning to wonder or suspect the Ubuntu installation image on the VPS may not be entirely clean... If I try to run arm as root, the "new relay" configuration wizard appears and when I quit the tor process isn't running. I'm stuck. Any help very gratefully received. Cheers Doug

3 6