Hi list,
I'm running a relay on a CentOS VM
As I have lots of resources available, I wanted to duplicate that VM to bring more bandwidth to the Tor network --> cloned VM, changed IP and mac adresses, OS hostname, Tor nickname and restarted the Tor service
Surprise: the fingerprint of the clone is identical to the one of the source VM I have stopped my clone to avoid any issue, but I guess I must have missed something...
Any clue would be highly appreciated !!
rm -rv keys/
new keys -> new fingerprint -> new identity
On 17 Dec 2016, at 17:30, Patrick DERWAEL patrick@derwael.be wrote:
Hi list,
I'm running a relay on a CentOS VM
As I have lots of resources available, I wanted to duplicate that VM to bring more bandwidth to the Tor network --> cloned VM, changed IP and mac adresses, OS hostname, Tor nickname and restarted the Tor service
Surprise: the fingerprint of the clone is identical to the one of the source VM I have stopped my clone to avoid any issue, but I guess I must have missed something...
Any clue would be highly appreciated !!
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Patrick DERWAEL:
--> cloned VM, changed IP and mac adresses, OS hostname, Tor nickname and restarted the Tor service
Surprise: the fingerprint of the clone is identical to the one of the source VM
There is no surprise. You've probably just cloned DataDirectory which contains long-term relay private key and edited only torrc (nickname, ports, whatever). Try to clear DataDirectory out and restart tor - it should regenerate the keys.
-- Ivan Markin
Out of curiosity, I wonder how the Tor network handles this? Do the directory authorities drop one (or both) from the consensus?
anondroid:
Out of curiosity, I wonder how the Tor network handles this? Do the directory authorities drop one (or both) from the consensus?
There are no "two" relays for one fingerprint since relays are "addressed" (named) by their keys (fingerprints). If one starts another relay with the same key it will be treated by the authorities as new descriptor for this key, i.e. another one will be pushed out from consensus.
From another side, only two relays (read keys) are allowed per one IP
address. Thus other than two relays on given IP address will also be pushed out from consensus.
-- Ivan Markin
Issue solved, thank you guys !
2016-12-18 0:28 GMT+01:00 Ivan Markin twim@riseup.net:
anondroid:
Out of curiosity, I wonder how the Tor network handles this? Do the directory authorities drop one (or both) from the consensus?
There are no "two" relays for one fingerprint since relays are "addressed" (named) by their keys (fingerprints). If one starts another relay with the same key it will be treated by the authorities as new descriptor for this key, i.e. another one will be pushed out from consensus. From another side, only two relays (read keys) are allowed per one IP address. Thus other than two relays on given IP address will also be pushed out from consensus.
-- Ivan Markin _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 18 Dec. 2016, at 10:28, Ivan Markin twim@riseup.net wrote:
anondroid:
Out of curiosity, I wonder how the Tor network handles this? Do the directory authorities drop one (or both) from the consensus?
There are no "two" relays for one fingerprint since relays are "addressed" (named) by their keys (fingerprints). If one starts another relay with the same key it will be treated by the authorities as new descriptor for this key, i.e. another one will be pushed out from consensus.
The directory authorities generally believe the latest descriptor for a key, but they also do reachability checks on the IP address and port.
So this is likely to get both relays dropped from the consensus, or swap between them at arbitrary times depending on when they post descriptors.
And it increases the load on the directory authorities, so please don't deliberately set things up this way.
T
tor-relays@lists.torproject.org