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
I can almost do this, otherwise I wouldn’t write this article.
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
- 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.comand you’ll find it in the references below.
- Test that you can connect to their alternate server with
ssh -T -p 443 $server_name. For Gitlab, I use
altssh.gitlab.comas the server name. If you can’t connect, then I imagine you have a bigger problem and these instructions won’t help you.
- Create an alternative SSH configuration file at
$HOME/.ssh/config-blocked-sshto use in situations like this.
- Paste into
config-blocked-sshthe connection information from your git repository hosting service. (See the References section.)
- 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.
- In a terminal session, tell
gitto use a different SSH command with
GIT_SSH_COMMAND="ssh -F $HOME/.ssh/config-blocked-ssh".
- 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.
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.