How to clone gitlab repo over tor using ssh?

Question

Error message

After having added the ssh key of a user of a GitLab server and repository that is hosted over tor, a test was performed that tried to clone a private repository (to which the testing user is added) over tor. The cloning was attempted with command:

torsocks git clone git@some_onion_domain.onion:root/test.git

Which returns error:

Cloning into 'test'... 1620581859 ERROR torsocks[50856]: Connection refused to Tor SOCKS (in socks5_recv_connect_reply() at socks5.c:543) ssh: connect to host some_onion_domain.onion port 22: Connection refused fatal: Could not read from remote repository.

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

GitLab SSH Cloning Verification

However, to verify the ssh access is available to the test user, the cloning was verified without tor using command:

git clone git@127.0.0.1:root/test.git

Which successfully returned:

Cloning into 'test'... remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done.

Server side hypothesis

• My first guess is that it is a server-side issue that has to do with the lack of https, in following setting in the /etc/gitlab/gitlab.rb file:

external_url 'http://127.0.0.1'​

However setting external_url 'https://127.0.0.1 requires an https certificate, e.g. from Let's encrypt, which seem to not be provided for onion domains.

Client-side hypothesis

• My second guess would be that it is a client-side issue related to some SOCKS setting is incorrect at the test user side that runs the torsocks command, similar to an issue w.r.t. the SOCKS 5 protocol that seems to be described here.

Question

Hence I would like to ask:

How can I resolve the connect to host some_onion_domain.onion port 22: Connection refused error when users try to clone the repo over tor?

Answer 1

One can set the ssh port of the GitLab instance to 9001, e.g. with:

sudo docker run --detach \
  --hostname gitlab.example.com \
  --publish 443:443 --publish 80:80 --publish 22:9001 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab \
  --volume $GITLAB_HOME/logs:/var/log/gitlab \
  --volume $GITLAB_HOME/data:/var/opt/gitlab \
  gitlab/gitlab-ee:latest

Next, add port 9001 and port 22 to the ssh configuration in /etc/ssh/sshd_config by adding:

Port 9001
Port 22

then restart the ssh service with: systemctl restart ssh.

It is essential that one adds a public ssh key to the GitLab server for each computer you want to download the repo from, even if one wants to clone a public repository. You can make a new GitLab account for each computer, or add multiple public ssh keys to a single GitLab account. These instructions explain how to do that, tl;dr

ssh-keygen -t ed25519
<enter>
<enter>
<enter>
systemctl restart ssh
xclip -sel clip < ~/.ssh/id_ed25519.pub

Ps. if xclip does not work, one can manually copy the ssh key with: cat ~/.ssh/id_ed25519.pub.

Then open a browser and go to https://gitlab.com/-/profile/keys so for your own tor GitLab server that would be: someoniondomain.onion/-/profile/keys, and copy paste that key in there.

That is it, now one can clone the repository over tor with:

torify -p 22 git clone ssh://git@someoniondomain.onion:9001/root/public.git

Note

As a side note, in the question I happened to have tested git clone git@127.0.0.1:root/test.git however, instead of using 127.0.0.1 I should have used either the output of hostname -I or the public ip address of the device that hosts the GitLab server. Furthermore, I should have verified whether the GitLab server was accessible through ssh by testing:

ssh -T git@youronionserver.onion

Which should return Congratulations... It would not have done so if I had tested that, indicating the problem was in the ssh access to the GitLab server (or the ssh connection to the device). I could have determined whether the ssh problem was with the device or the ssh server by testing if I could log into the device with: ssh deviceusername@device_ip, which would have been successfull indicating, the ssh problem with at the GitLab server.