Created the script file in the bin dir. Executing with sudo anon-auth-autogen results in a command not found. Executing at its file path runs it but runs into a showstopper:
user@host:~$ sudo bash /usr/bin/anon-auth-autogen
INFO: Created torconffile ‘/usr/local/etc/torrc.d/43_hidden_service_hs_autogen.conf’.
cat: /var/lib/tor/hidden_service/hostname: No such file or directory
ERROR: exit_code: 1 | BASH_COMMAND: onion_url=“$(cat “$onion_url_file”)”
Do contents of /usr/local/etc/torrc.d/43_hidden_service_hs_autogen.conf look sensible?
Does folder / file exist now?
sudo ls -la /var/lib/tor/hidden_service/
sudo ls -la /var/lib/tor/hidden_service/hostname
If both yes, I think I know why this is happening. After creating /usr/local/etc/torrc.d/43_hidden_service_hs_autogen.conf the script runs systemctl reload tor@default but this command is non-blocking and does not wait for the hidden service files to be created. systemctl restart tor@default would be blocking but also interrupt existing connections.
Now fixed by waiting 5 seconds (configurable). Not the cleanest solution but good enough.
Better sudo chmod +x /usr/bin/anon-auth-autogen. Then you can drop bash and it will use whatever interpreter which is used.
No
user@host:~$ sudo chmod +x /usr/bin/anon-auth-autogen
user@host:~$ sudo anon-auth-autogen
INFO: Created torconffile ‘/usr/local/etc/torrc.d/43_hidden_service_hs_autogen.conf’.
INFO: Reloading Tor.
INFO: Giving Tor 5 seconds to create hidden service file.
cat: /var/lib/tor/hidden_service/hostname: No such file or directory
ERROR: exit_code: 1 | BASH_COMMAND: onion_url=“$(cat “$onion_url_file”)”
user@host:~$ sudo ls -la /var/lib/tor/hidden_service/
ls: cannot access ‘/var/lib/tor/hidden_service/’: No such file or directory
user@host:~$ sudo ls -la /var/lib/tor/hidden_service/hostname
ls: cannot access ‘/var/lib/tor/hidden_service/hostname’: No such file or directory
Tor currently totally ignores that file I suppose - you can test by
adding any garbage there which would normally result in Tor to fail to
restart - except for that file which is fully ignored.
Requires using Whonix testers repository. Only that support “real”
torrc.d support.
Then please look at /etc/tor/torrc and all files that follow. (follow
whatever %include) See if all of that makes sense. Compare with git
master.
Otherwise Tor will just ignore any other files in torrc.d.
What package do you mean? Tor or autogen? The later still doesn’t how in Testers
HulaHoop via Whonix Forum:
What package do you mean?
anon-gw-anonymizer-config changes Tor config files to include all of
/usr/local/etc/torrc.d/.
%include /usr/local/etc/torrc.d/
As per:
Please check if these files look OK:
/etc/tor/torrc/etc/torrc.d/95_whonix.confTor or autogen? The later still doesn’t how in Testers
Expected.
OK good progress made:
user@host:~$ sudo anon-auth-autogen
INFO: Created torconffile ‘/usr/local/etc/torrc.d/43_hidden_service_hs_autogen.conf’.
INFO: Reloading Tor.
INFO: Giving Tor 5 seconds to create hidden service file.
INFO: Copied client_authorization_full_path ‘/var/lib/tor_autogen/hidden_service/1.auth’ to ‘/var/lib/tor_autogen/hidden_service/1.auth’.
INFO: You probably want to provide client ‘1’ with auth_private_file ‘/var/lib/tor_autogen/hidden_service/1.auth_private’ for hsname ‘hidden_service’ onion_url ‘verylongv3address.onion’.
Is there anything else I need to do or is the process complete? Perhaps the script should display a clearer message about what folder one needs to backup?
Once that is done, also a onion service generator for non-authenticated onion services could be considered if that looks worthwhile. Easy to provide a “reduced feature” “fork” of that script.
Testing required.
Can you copy file /var/lib/tor_autogen/hidden_service/1.auth_private to another VM and use it as per Onion Service Authentication Client Setup to actually connect to the onion service? Maybe this needs scripting as well?
This might require previous exercising with un-authenticated Onion Services.
Makes sense. Could you draft please the ideal output of the script (everything, not just backup)?
Maybe some messages such as INFO: Reloading Tor. are superfluous?
Output INFO: Created torconffile ‘/usr/local/etc/torrc.d/43_hidden_service_hs_autogen.conf’. probably makes sense in principle? Users should understand a bit what actually happened? Avoiding “black boxes”. Self-documentation as a goal. But perhaps the output could be better formatted?
Output INFO: Copied client_authorization_full_path ‘/var/lib/tor_autogen/hidden_service/1.auth’ to ‘/var/lib/tor_autogen/hidden_service/1.auth’. might be too verbose? I like to let my scripts explain what they’re doing.
Also worth considering: commands users can copy/paste for backup.
What files to backup is a good question. Which ones?
I guess with a backup of both folders:
/var/lib/tor_autogen and/var/lib/tornothing can be forgotten. But that includes Tor state files (Tor consensus and Tor entry guards).
Or better only backup these two folders
/var/lib/tor_autogen/hidden_service and/var/lib/tor/hidden_service?
(Note: hidden_service is a variable. It could be mumble_service or anything else. Useful for multiple Tor onion services. Can be set through variable hsname.)
Otherwise a “more selective” backup might makes copies of these three files:
/var/lib/tor/hidden_service/hs_ed25519_secret_key/var/lib/tor_autogen/hidden_service/1.auth_private/var/lib/tor_autogen/hidden_service/1.authOther files generated in the process do not need backup?
I think I’d run into the same permissions nightmare I saw above. Its worthwhile to script this too in the same program.
OK
I find it useful because otherwise I would think the script stalled or something wrong.
I agree. Those who have no idea probably don’t care about the messages and just want to see an “operation completed successfully”. Powerusers want to get an idea of what is going on in case they need to debug. IMO split the message output into a verbose and quiet mode if easily done.
I’d limit the scope to HS folders only with contents under them. I imagine users would be surprised if their current guard was changed when restoring an older backup of their service. Selective backup might be nice, but I see it as a niche usecase and not worth the trouble.
Nothing comes to mind.
Suggested backup/restore messages:
Your Onion Service conf and keys will be backed up to /home/user. Please transfer to a storage device outside the VM.
Your Onion Services are now restored
Suggestion:
Reload Tor to so Tor will load client_authorization_full_path. →
Reloading Tor will apply client_authorization_full_path.
Is this message suggesting auth cookie use? Or is it an error message guessing why a failure happened? Let’s make it a concrete statement to guide users on what exactly is wrong.
INFO: You probably want to provide client ‘$client’ with auth_private_file ‘$auth_private_file’ for hsname ‘$hsname’ onion_url ‘$onion_url’."
The rest looks good.
We need to master linux file permissions.
meld, kdiff3 or similar.What do we use as permissions diagnosis tool?
sudo find /var/lib/tor | sudo xargs stat -cstat -c "
access rights octal: '%a'
access rights human: '%A'
file type: '%F'
user name of owner: '%U'
group name of owner: '%G'
number of hard links: '%h'
quoted file name with dereference if symbolic link: '%N'"
Or perhaps simpler…
sudo find /var/lib/tor | sudo xargs stat -cstat -c "%a %A %F %U %G %h %N"
More readable output?
Redirect output to file one.txt.
sudo find /var/lib/tor | sudo xargs stat -cstat -c "%a %A %F %U %G %h %N" > one.txt
Redirect output to file two.txt.
sudo find /var/lib/tor | sudo xargs stat -cstat -c "%a %A %F %U %G %h %N" > two.txt
Compare.
meld one.txt two.txt
Dunno if I am missing something here. stat supports a lot things to output. Quote stat(1) — coreutils — Debian bookworm — Debian Manpages
The valid format sequences for files (without --file-system):
%a
access rights in octal (note ‘#’ and ‘0’ printf flags)
%A
access rights in human readable form
%b
number of blocks allocated (see %B)
…
Once we know the right permissions / manual commands, I can try to script that.
Makes sense.
For “super debug”, just run
sudo bash -x anon-auth-autogen
Indeed.
Info. Not error. Messages starting with INFO: aren’t errors. Errors should always start with ERROR: unless I mess that up in the source code but I didn’t manage to mess that up yet.
I don’t remember this exact message.
This is confusing indeed. Both Tor Project: manual and don’t use good names for these files.
Tor calls them
".auth_private" file".auth" fileMy interpretation:
".auth_private" file: private key - to be installed on client".auth" file: public key - to be installed on onion serviceI’d preferred if .auth was .auth_public but it’s not possible as per Tor manual. These file suffixes are hardcoded in Tor. Since I cannot simplify upstream names, I will use the same names in the script output to not invent new terminology to add further confusion.
Could you please English language interpret chapter Client Authorization from Tor Project: manual for me? This sentence:
Revoking a client can be done by removing their “.auth” file, however the revocation will be in effect only after the tor process gets restarted even if a SIGHUP takes place.
What means even if a SIGHUP takes place.?
Restart or reload required?
Reload (SIGHUP) not sufficient?
Yay. Things get more complicated. Quote Redirecting...
The keypair used for client authorization is created by a third party tool for which the public key needs to be transferred to the service operatorin a secure out-of-band way. The third party tool SHOULD add appropriate headers to the private key file to ensure that users won’t accidentally give out their private key.
Our current process is the server to set up the onion service and client authorization key files.
Tor Project’s idea seems to be vice versa. That clients should create their own ".auth_private" file (private key) and ".auth" file (public key). Retain their private key, install their private key in Tor’s data directory and then and send their public key to the onion service operator.
Tor Project way: That would have the advantage that 1 client could re-use their private key for multiple services. But is harder for clients.
Whonix way: onion service operators could impersonate clients but does that matter?
I guess arguments could be made for both use cases. Server created authorization files vs client created authorization files.
But not sure we want to follow or ignore this.
new output:
sudo anon-auth-autogen
INFO: Created torconffile ‘/usr/local/etc/torrc.d/43_hidden_service_hs_autogen.conf’.
INFO: Reloading Tor.
INFO: Giving Tor 5 seconds to create hidden service file.
INFO: Installed “.auth” file (public key) ‘/var/lib/tor_autogen/hidden_service/1.auth’ to ‘/var/lib/tor_autogen/hidden_service/1.auth’ to allow client ‘1’ to access hsname ‘hidden_service’ onion_url ‘gky7wbnxkl57vn6bmdoeck4pqsppa3bmjq6i7kkqw3pttkflg7uymjad.onion’.
INFO: Reloading Tor again to activate “.auth” (public key) file for client ‘1’.
INFO: You need to provide client ‘1’ with “.auth_private” file (private key) ‘/var/lib/tor_autogen/hidden_service/1.auth_private’.
INFO: Visitors that use Whonix could store ‘/var/lib/tor_autogen/hidden_service/1.auth_private’ in ‘/home/user/1.auth_private’ and then run ‘sudo sourcefile=/home/user/1.auth_private anon-server-to-client-install’.
anon-server-to-client-install Tor Authenticated Onion Service ".auth_private" file (private key) Server to Client Installer was also creaetd.
sudo anon-server-to-client-install
INFO: Installed “.auth_private” file (private key) ‘/home/user/1.auth_private’ to ‘/var/lib/tor/authdir/1.auth_private’.
INFO: Created torconffile ‘/usr/local/etc/torrc.d/43_clientonionauthdir.conf’.
INFO: Reloading Tor to activate “.auth_private” file (private key).
INFO: Success.
Not sure about the backup feature yet.
anon-auth-autogen is not yet idempotent.
Re-running anon-auth-autogen results in files
being overwritten, re-generated. What should be done if either file already exists? I guess not overwrite, notify user and error out?
Tor Onion Service Backup ToolTor Authenticated Onion Service Backup Toolanon-auth-autogen and/or anon-server-to-client-install?Features? Copy from /var/lib/tor/hidden_service to home folder? What if files in /var/lib/tor/hidden_service differ from contents in /home/user/onion-service-backup/hidden_service? Overwrite? Probably not. Error out?
What’s the main feature of this? Copying some things from /var/lib/tor to /home/user? And then users are supposed to copy yet again to somewhere else? Why they wouldn’t copy straight from /var/lib/tor?
Can ClientOnionAuthDir be set multiple times to different folders?
https://phabricator.whonix.org/T996
A release candidate for next Tuesday’s stable Tor Browser 9.5 has been announced on tor-qa. Some excerpts from the changelog:
- Bug 30237: Control port module improvements for v3 client authentication
(Might be impossible to make this work with onion-grater while still isolating VMs)
https://lists.torproject.org/pipermail/tor-dev/2020-June/014353.html
553 Unable to store creds for
Did you set ClientOnionAuthDir in torrc (to a directory with "private
enough" permissions)?
Rusty
Perhaps auto rename it to something else/random?
anon-server-to-client-install makes sense.
unnecessary IMO
Yes
Perhaps copy to the shared folder straight away? There has to be a sanity check to detect if it is mounted first. I feel like most functionality you are implementing would quickly lead to re-inventing the wheel in many ways that dedicated sync programs are designed to deal with these problems. Perhaps delegating this to something with a gui like Unison is a good idea. Or even including Unison with preconfigured origin and clone dirs preset would be easier .
Does not seem like it:
While it supports multiple auth files, there is no mention of Tor accepting mutliple dir paths for it.
Tor Browser Onion Client Authorization in Whonix works for me. Just now documented:
Onion Client Authorization