🔒 Accessing git Servers Over Another Port When 22 is Blocked and Cloning Hangs Waiting for Connection#

It’s been awhile since I’ve setup my last work system a year back, so this past month I’ve gone through the usual pains of preparing a new machine. One of those pains was realizing some network segments at one of the libraries I am a regular at have port 22 blocked at an internal boundary. Without falling into discussions about how useful such a thing is from a defensive security point of view, I wanted to share a trick not many folks know of. It turns out that, precisely for those situations, all renowned Git hosting providers offer access to their Git service via an alternative port: 443.


git clone Hanging#

The initial issue arose when I was working locally on a repository I had cloned already and then needed to clone another personal one, let’s assume for the sake of brevity it was jdsalaro/jdsalaro.com.

1$ git clone git@github.com:jdsalaro/jdsalaro.com.git
2Cloning into 'jdsalaro.com'...

As I waited for a couple of seconds I observed git just hanged there without doing much; obviously something was amiss. My usual attempt at debugging didn’t yield much that was of interest as can be seen below:

313:12:27.776079 git.c:465               trace: built-in: git clone git@github.com:jdsalaro/jdsalaro.com.git
4Cloning into 'jdsalaro.com'...
513:12:27.781106 run-command.c:657       trace: run_command: unset GIT_DIR; GIT_PROTOCOL=version=2 ssh -o SendEnv=GIT_PROTOCOL git@github.com 'git-upload-pack '\''jdsalaro/jdsalaro.com.git'\'''

Similarly, ssh failed to establish a connection to the server at all for both github.com and gitlab.com; bitbucket.org, cloud.gitea.com and codeberg.org would have failed as well.

1$ ssh -T git@github.com
4$ ssh -T git@gitlab.com

Nevertheless, ssh’s debug output was much more useful in this case:

 1$ ssh -T git@github.com -vvv
 2OpenSSH_9.6p1, LibreSSL 3.3.6
 3debug1: Reading configuration data /Users/[...]/.ssh/config
 4debug1: Reading configuration data /etc/ssh/ssh_config
 5debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
 6debug1: /etc/ssh/ssh_config line 54: Applying options for *
 7debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/Users/[...]/.ssh/known_hosts'
 8debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/Users/[...]/.ssh/known_hosts2'
 9debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
10debug3: channel_clear_timeouts: clearing
11debug1: Connecting to github.com port 22.

It Wasn’t a Me Problem#

The connection wasn’t even being established, but internet connectivity wasn’t an issue:

1curl example.com | grep title
2  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
3                                 Dload  Upload   Total   Spent    Left  Speed
4100  1256  100  1256    0     0   6372      0 --:--:-- --:--:-- --:--:--  6408
5    <title>Example Domain</title>

And the corresponding providers were available over HTTPS and weren’t reporting an outage:

1$ nc github.com 443

The network connection looked alright on the wire, should I say waves?, as well:

For port 443 the whole TCP/IP spiel was taking place as expected: SYN followed by SYNACK, ACK and data being transferred. At that point it became obvious that someone had made the decision in the past days to start restricting outbound connections to port 22:

1$ nc github.com 22 

A quick Wireshark capture showed as much; outbound TCP handshakes to port 22 weren’t taking place:

The Solution#

As mentioned in my brief introduction for this post, most Git hosting providers will also offer their service over HTTPS [1][2][3].

Addressing the issue described here is just a matter of configuring the respective hostnames to their respective alternatives:

 1$ cat ~/.ssh/config
 3Host github.com
 4  Hostname ssh.github.com
 5  Port 443
 6  User git
 7  PreferredAuthentications publickey
 8  IdentityFile ~/.ssh/github
10Host gitlab.com
11  Hostname altssh.gitlab.com
12  Port 443
13  User git
14  PreferredAuthentications publickey
15  IdentityFile ~/.ssh/gitlab

Et voilà, we’re back online:

$ ssh -T git@github.com

Hi jdsalaro! You've successfully authenticated, but GitHub does not provide shell access.

$ ssh -T git@gitlab.com

Welcome to GitLab, @jdsalaro!

Final Words#

Hope y’all found this brief debugging session interesting, it’s a bit over-engineered in order to make it interesting and blog-worthy, but is not too far detached from how I’d approach similar problems in reality.

Stay in touch by entering your email below and receive updates whenever I post something new:

As always, thank you for reading and remember that feedback is welcome and appreciated; you may contact me via email or social media. Let me know if there's anything else you'd like to know, something you'd like to have corrected, translated, added or clarified further.