Re: [tor-relays] Tor not reading medium-term signing key.

[12xBTM <12xbtm@xxxxxxxxx>]

Okay, so fixing the permissions fixed the whole problem.
At least until it asks where the master_id_secret_key is again when it
needs a newer medium-term signing_secret_key.

I know why debian-tor and [user] are separate, I'm just saying that
having the [user] move debian-tor files around can make them [user]
files now. Particularly when moving them back online.

So, now that OfflineMasterKey is back up and running, what should be the
contents of my key folder during normal operation? And, what should be
the rough procedure for generating a new key, and putting things where
they need to be for Tor to get the new key in, the default, 30 days?

What is the purpose of master_id_public_key, master_id_secret_key, and
master_id_secret_key_encrypted?

Remember how tor --keygen was generating keys in [user]/.tor/keys? Yeah,
it stopped doing that, even though I didn't specific a datadirectory.
I'd say it was generating it inside /var/lib/tor/keys, but I can't be
certain. Because now I have two maybe-different sets of master keys, the
keys that probably never left /var/lib/tor/keys, which are
master_id_public_key, and master_id_secret_key, and the keys that came
from [user]/.tor/keys, which are master_id_public_key, and
master_id_secret_key_encrypted. Again, how do these fit into the normal
operation of /var/lib/tor/keys/ and key regeneration?

Thanks for you help so far with this.

On 4.1.16 18:29, s7r wrote:
> 
> 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.
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays