In this thread I propose an “Onion workaround” near the bottom of the page. It does not work.

My latest experiment is formed like this:

$ sudo tee -a /etc/tor/torrc <<< 'mapaddress 192.168.1.25 hsdtecd4h2b5z732pvkg2yw3746epap4qusgvjjze6nhmfcdpz2suiad.onion'
$ cat >> ~/.ssh/config <<eof
host nogafam-onion
     UserKnownHostsFile    /dev/null
     StrictHostKeyChecking no
     hostname     192.168.1.25
     ForwardX11   no
     ProxyCommand connect -4 -S 127.0.0.1:9050 %h %p
     IdentityFile /home/$(whoami)/.ssh/id_rsa_nogafam
eof

Doing a git push results in:

ssh: Could not resolve hostname nogafam-onion: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I suspect SSH objects to a hostname that is supplied as an IP address.

But apart from that, what should the first 3 octals of the IP address? Should it match the LAN subnet that I am on? I hope not, because my LAN subnet changes from day to day depending on where I connect. Or should it reflect the VirtualAddrNetwork in /etc/tor/torrc?

Note that I do not restart tor when I mess with the mapaddress… I just send mapaddress 1.2.3.4=yadayada.onion to the tor control port which should have realtime effect.

I tried both using a subnet that matches the LAN I am on, and also tried one that matches the VirtualAddrNetwork. Both result in the same error.

So I thought maybe the hostname needs to be the onion address. But check this out… running this on the CLI:

$ tor-resolve hsdtecd4h2b5z732pvkg2yw3746epap4qusgvjjze6nhmfcdpz2suiad.onion 127.0.0.1:9050

Results in an IPv6! WTF? I do not expect Tor to use IPv6 for internal mapping. Most especially when I used mapaddress to micro-manage the mapping.

update

Gitea proxy webhooks may be what’s missing. Along these lines:

https://github.com/go-gitea/gitea/issues/22335

This is probably the key to getting this working – https://github.com/RightToPrivacy/Gitea-Onion