If you find yourself on a network that blocks SSH (port 22), but you want to push some code to your favorite hosted git repository, you can probably do it. Github, Gitlab, and Bitbucket all provide an alternative git server so that you can connect over HTTPS (port 443), which such networks can’t really afford to block.

Good news: you can use an alternative SSH configuration to connect without adding different remotes to your local repository. Bad news: every tutorial I read suggests changing your global/per-user SSH configuration settings, usually in $HOME/.ssh/config. How likely do you think you’ll remember to change this back when you return to a nicer network? Exactly.

I think like a programmer. I prefer to configure systems as narrowly as possible: at the user level instead of system-wide; for an individual session instead of at the user level; for an individual request instead of for the entire session. You get the idea. I know that I can tell ssh which configuration file to use for each request. I would like to do that for git.

I can almost do this, otherwise I wouldn’t write this article.

Using git with an alternate SSH configuration

I created an alternative SSH configuration file, then taught git how to use that configuration file when connecting to SSH. This way, I don’t have to change the configuration for all SSH sessions by my user, but only the ones to the git hosting services’ servers.

Step by Step Instructions

  1. Look up the HTTPS connection information from your git repository hosting service. I had to search for while, but I found that information for gitlab.com and you’ll find it in the references below.
  2. Test that you can connect to their alternate server with ssh -T -p 443 $server_name. For Gitlab, I use altssh.gitlab.com as the server name. If you can’t connect, then I imagine you have a bigger problem and these instructions won’t help you.
  3. Create an alternative SSH configuration file at $HOME/.ssh/config-blocked-ssh to use in situations like this.
  4. Paste into config-blocked-ssh the connection information from your git repository hosting service. (See the References section.)
  5. Now try to connect with ssh -T @server_name. With luck, your git repository hosting service will tell you that you connected, even if they don’t give you shell access.
  6. In a terminal session, tell git to use a different SSH command with GIT_SSH_COMMAND="ssh -F $HOME/.ssh/config-blocked-ssh".
  7. Now try pushing or showing a specific remote. That should just work!

Now, I can move this command into a script with a nice name that I’ll remember for the next time I find myself in this situation.

References

Stack Overflow, “Tell git which SSH config file to use”.

Achilleas Pipinellis, “Gitlab.com Now Supports an Alternate git+ssh Port”. The connection information for Gitlab. Your git repository hosting service likely offers something similar.