Development and deployment on networks that block port 22

Rob Pickering

• 2 min read
Development and deployment on networks that block port 22
Photo by Sigmund / Unsplash

I hit an awkward problem that I've never hit before, last week.

After a weekend at a hackathon with great Wifi, I checked back into my codebase to do a bit more work from the place I was staying and found all my cloud hosts were now rejecting port 22.

After a while I twigged that everything on the Internet was just fine, but the local WiFi was blocking TCP port 22 outbound. I've never come across this before, maybe I have lead a sheltered life, but how evil and pointless is that!

How to workaround it?

I had two issues, I couldn't ssh to GCP instances (VMs) that I was test staging my code on, and I couldn't even push my code changes upstream to the github repo as that also required ssh.

Google cloud

This one is relatively easy. Google has a service called Identity-Aware Proxy which allows you to use local auth credentials to access protected services via a proxy rather than direct network connection. All you need to do is enable it on the project:

gcloud projects add-iam-policy-binding PROJECT_NAME \
   --member=user:USER_ID \
   --role=roles/iap.tunnelResourceAccessor
gcloud projects add-iam-policy-binding PROJECT_NAME \
   --member=user:USER_ID \
   --role=roles/compute.instanceAdmin.v1

Where PROJECT_NAME is the GCP project ID, and USER_ID is your username (usually email address).

Now gcloud compute ssh will just use the IAP proxy anyway if you try to access an instance which isn't accessible on a public IP. If it is, then it will try to access by public IP and fail. All we have to do is use the --tunnel-through-iap to force it to sidestep the evil local WiFi provider and use IAP:

gcloud compute ssh instance-1 --tunnel-through-iap 

Last login: Wed Nov 30 20:32:26 2022 from 35.235.240.112
rob@instance-1:~$
Using --tunnel-through-iap to force a tunnel

Done.

Github push by ssh without port 22

Github have obviously come across this before because ssh.github.com also listens on port 443. Adding the following to your ~/.ssh/config will cause your client to use this port and therefore allow do ssh pushes on an alternative, more "hostile Wifi" friendly port:

Host github.com
    Hostname ssh.github.com
    Port 443
    User git

The first time you connect after switching to port 443, you may get a warning message that the host wasn't found in known_hosts, or that it was found by another name.

It is generally safe to answer "yes" to this question if you understand what is going on, verify with GitHub's published fingerprints at Github's SSH key fingerprints (which you did when sshing to them the first time right?).

You can, but should you?

I've made these notes for search engines to find in the hope that it helps someone who needs a quick fix to be able to commit and stage code from hostile public WiFi.

I was developing low value hackathon grade code that nobody relies on, committing to public repos and staging prototypes on throwaway VMs. If you are developing stuff that other people rely on, then maybe public WiFi that you know messes with your packets isn't the best place to be doing that. Assess your own risks or consult skilled infosec people or your management to understand whether this is a good idea (it probably isn't).

Mastodon