-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 1/5/2016 12:13 AM, 12xBTM wrote:
Now I'm getting permission denied, still out-dated key, and missing master_id_secret_key errors, which are unsurprisingly fatal.
Jan 04 22:41:33.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied Jan 04 22:41:33.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load the permanent master identity key. Jan 04 22:41:33.000 [warn] We needed to load a secret key from /var/lib/tor/keys/ed25519_master_id_secret_key, but couldn't find it. Did you forget to copy it over when you copied the rest of the signing key material? Jan 04 22:41:33.000 [warn] Can't load master identity key; OfflineMasterKey is set. Jan 04 22:41:33.000 [err] Error initializing keys; exiting
Which is funny, because the [user] has permission over signing_secret_key, and the ed25519_master_id_secret_key is totally in /var/lib/tor/keys/.
Yes but for security reasons we usually run Tor as a different user than [user]. In Debian for example it's debian-tor in FreeBSD is tor_
So: # chown -R debian-tor:debian-tor /var/lib/tor/keys/*
if you are using debian, if not substitute debian-tor with the user running Tor on your system.
Retry the steps in my previous email with this additional step finally and see what happens.
At this point, I just disabled OfflineMasterKeys because there's just not enough information available for me to go about this. If you know of a way to completely regenerate signing keys, master keys, and whatever other keys I need besides the one for my fingerprint, that'd be nice, because I'm fairly certain things are completely screwed up now since Tor can't find or access the the signing_secret_key or master_id_secret_key. I'll be sure to implement that key regeneration in a week or so when I can correct the keys on this node, until then, I'll leave this exit node off until I'm sure it's using valid keys, because there's no point in having a faulty exit node.
secret_id_key, secret_onion_key, and secret_onion_key_ntor weren't touched (I think). So it's the others keys I need to fix.
I'll try this OfflineMasterKeys thing when more operational information is released about it. Because, not only do I not know what I'm doing, I don't even know what it does at this point. --keygen on the master key and writing it automatically to a [user] directory made it property of [user] instead of debian-tor. Also, what is master_id_secret_key_encrypted used for if Tor says it can't use an encrypted master_id_secret_key?
I'm absolutely a linux noob, and I know that's not helping.
Why do you use offline master key in this case and not simply allow Tor to work with the defaults? Usually the offline master key functionality is for those who have time to attend to the relays and periodically renew keys and also know how to do it.
OfflineMasterKey needs no more information than it already provides: tells Tor never try to generate or load master id secret key.
Hint: when you run # tor --keygen in console the command is run as [user] and files are stored in home/[user]/.tor/keys and are owned by [user].
The Tor instance runs under debian-tor, so debian-tor needs access to /var/lib/tor . Of course [user] also has access in /var/lib/tor because it's above debian-tor most probably in your setup. But when you move the signing cert and medium term signing key from /home/[user]/.tor/keys to /var/lib/tor/keys they are still owned by [user] and debian-tor (Tor instance) can't access them.