As helping few folks to reach their machines with Tor HS, this reveal for me some mistakes average user will encounter because well it’s not that intuitive for beginners.
(And I’m also the average one, just make it working later for them.)
First hiccup on the way is:
tee: /usr/share/keyrings/deb.torproject.org-keyring.gpg: Permission denied
this one is because users by default will prefix the command with sudo but do not know that unless it’s sudo -i or -s (for switching to root shell so the beginning is with # and not the $ sudo command) - the sudo privilege is applied only for the first command, can’t be chained for the next one.
Described here as well.
Later with the part for the ClientSide authorization will bring for many the:
[warn] Directory /var/lib/tor/onion_auth cannot be read: Permission denied
Because this creation of the path and files must be done within shell having sudo privileges so people will figure out and do that eventually (usually sudo -s).
But the dir and files ending up with wrong permission leading possibly to some attempts to fix this so find out the permission with all kinds of state.
After all most common mistake is fixing all of path but not the /tor dir itself, rather the content tor/*.
That is, I think, because it’s most common fix accessible online but applied just too late & copy paste.
So make sure the path and the files for ClientOnionAuthDir are belonging to the debian-tor:
sudo -s
chown -R debian-tor /var/lib/tor
verify: ls -la /var/lib - should see ‘debian-tor’ for the tor dir, same for ls -la /var/lib/tor/*
systemctl restart tor
(leave sudo with ‘exit’ / Ctrl+D)
and eventually check the logs:
grep "Tor" /var/log/syslog
Should work now.
No ambiguous ‘Connection closed by UNKNOWN port 65535’ for ssh attempt because the Tor will fail and the proxy isn’t available.
At least fix few attempts to make it work with this.
If having some mistake, please point me out to it.
Thank you.