Happy to hear you resolved the problem :-) Side-note wrt your setup : You're storing the keys on the disk, and while they're removed immediately after, that potentially leaves them on the physical storage. Since you're already passing them through ssh, consider just having ssh do the stdin bit : cat ~/.cryptoPass | ssh user@host "sudo -u tor e4crypt add_key -S $(cat ~/.cryptoSalt) /var/lib/tor" The salt will end up in the sudo log (/var/log/secure, usually) but the password will never hit the disk. No scp needed, and no files to rm afterwards. Tom Op 21/08/16 om 17:44 schreef Toralf Förster: > On 08/21/2016 03:23 PM, Tom van der Woerdt wrote: >> Did this work prior to adding encryption, or could that be a red >> herring? > > It was the attempt to encrypt the Tor directory using the ext4 method > - GRSecurity is fine (works since 2 years like a charm). > But I mistakenly encrypted it as user "root" - whereas user "tor" was > the right one. > > I described my steps in [1] under "setup". > I'm pretty convinced that this is an easy method to ensure an attacker > even with physical access to a server (eg. while changing a defect > hard disk) can't achieve the secret key. > > > [1] https://www.zwiebeltoralf.de/torserver.html > _______________________________________________ > tor-relays mailing list > tor-relays@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays