Skip to content

Instantly share code, notes, and snippets.

@guillochon
Last active March 8, 2024 23:56
Show Gist options
  • Save guillochon/eeaa54b328952d260472c14c559f698a to your computer and use it in GitHub Desktop.
Save guillochon/eeaa54b328952d260472c14c559f698a to your computer and use it in GitHub Desktop.
Instructions on how to SSH on airplane WiFi that blocks port 22

Using SSH through airplane WiFi that blocks port 22

Many aircraft that offer wifi only permit access to machines on port 80/443, the standard http(s) ports. If you want to SSH, you have to set up an intermediate machine that hosts the SSH service on either port 80 or 443. An easy (and free) way to do this is via a Google free-tier micro instance. These instances have a 1 GB transfer ceiling per month, but so long are you are only transmitting textual data a few days per month, this limit should not be easily exceeded. Set up one of these VMs via the Google Cloud console, and select CentOS 7 as the disk image. Make sure that you allow http/https traffic on the instance, the two checkboxes in the Firewalls section of the VM settings. Optionally, set a static external IP address for your server in the VM config, in case you don't want to look up the IP each time. Then, ssh into the new VM (the IP address will be listed as the "external IP" in the list of instances) and edit your /etc/ssh/sshd_config file, changing the Port 22 line to Port 80.

By default selinux will only allow the SSH service to use port 22, so you have to change your selinux permissions as well. Enter the following commands into the VM:

sudo su
semanage port -m -t ssh_port_t -p tcp 80
firewall-cmd --permanent --zone=public --add-port=80/tcp
firewall-cmd --reload
systemctl restart sshd.service

Make sure that SSH is listening on port 80:

ss -tnlp | grep ssh

Example output:

LISTEN     0      128          *:80                       *:*                   users:(("sshd",pid=1895,fd=3))
LISTEN     0      128         :::80                      :::*                   users:(("sshd",pid=1895,fd=4))

If so, log out and attempt to SSH into your server on the new port:

ssh 123.45.67.89 -p80

And you're done! Happy SSHing!

@a17levine
Copy link

Many thanks!!

@tanabi
Copy link

tanabi commented Apr 29, 2019

You can also do this with Digital Ocean which has a 100% web-based console client that works on a plane. Be aware that any hosting service that uses a Java based client may or may not work ... often those work on odd non-web ports.

@rosefun
Copy link

rosefun commented Jun 30, 2019

root@ss-instance:/home/rosefun96# semanage port -m -t ssh_port_t -p tcp 80
SELinux:  Could not downgrade policy file /etc/selinux/default/policy/policy.29, searching for an older version.
SELinux:  Could not open policy file <= /etc/selinux/default/policy/policy.29:  No such file or directory
/sbin/load_policy:  Can't load policy:  No such file or directory
libsemanage.semanage_reload_policy: load_policy returned error code 2.
SELinux:  Could not downgrade policy file /etc/selinux/default/policy/policy.29, searching for an older version.
SELinux:  Could not open policy file <= /etc/selinux/default/policy/policy.29:  No such file or directory
/sbin/load_policy:  Can't load policy:  No such file or directory
libsemanage.semanage_reload_policy: load_policy returned error code 2.
OSError: Error

How to solve this?

@ABaldwinHunter
Copy link

Thanks!

Also can adjust the port in ssh config it seems like?: https://stackoverflow.com/questions/7953806/github-ssh-via-public-wifi-port-22-blocked

A little faster perhaps?

@slingamn
Copy link

I was recently on a JetBlue flight ("Fly-Fi") and found that this technique did not work. Here's an excerpt of the ssh -vv output:

debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Ubuntu-10
debug1: match: OpenSSH_7.9p1 Ubuntu-10 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to [redacted]:443 as 'shivaram'
debug1: SSH2_MSG_KEXINIT sent
[connection times out]

The client (openssh on Ubuntu 18.04) was able to open a connection on port 443 to the server (openssh on Ubuntu 19.04), and it successfully received the server's version banner. But after this, no more data could be exchanged. As surprising as it sounds, I think they were detecting ssh via an application-layer firewall. (However, TLS seemed to be allowed on any port, including 6697, which is commonly blocked by layer 4 firewalls.)

@guillochon
Copy link
Author

guillochon commented Sep 12, 2019 via email

@slingamn
Copy link

I wasn't able to set it up at the time, but based on my observations, I think tunnelling ssh inside TLS on port 443 would work. I set up these configs on my server today:

https://github.com/slingamn/inconveniences/tree/master/system/ssh_tls_proxy

but unfortunately, I don't plan to fly again for a few months so I won't be able to test them myself.

@pangyuteng
Copy link

Thanks for sharing. This was a true life saver. 👍 👍 👍
I've forked your gist and made the instructions a bit more detailed for those that are not familiar with GCP. https://gist.github.com/pangyuteng/b8501304389584a067dddb5b84642c4f

@louisbuchbinder
Copy link

If you don't want to go through the hassle of setting up your own server you can use https://ssh443.com

@cunnie
Copy link

cunnie commented Jul 20, 2021

Scratch https://ssh443.com; it has been deprecated & no longer running. Also, JetBlue is definitely using a squid proxy, and they're not hiding it—this was the output from ssh -v -p 80 my-machine-that-has-ssh-bound-to-port-80:

debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: kex_exchange_identification: banner line 0: HTTP/1.1 400 Bad Request
debug1: kex_exchange_identification: banner line 1: Server: squid
...

@a17levine
Copy link

VPN also works on JetBlue (ExpressVPN)

@MortenVinding
Copy link

I wasn't able to set it up at the time, but based on my observations, I think tunnelling ssh inside TLS on port 443 would work. I set up these configs on my server today:

https://github.com/slingamn/inconveniences/tree/master/system/ssh_tls_proxy

Excelent!
worked like a charm.

I did get a little confused about why you would needs stunnel and the go program on the client side, so that inspired me to look at OpenSSL.
and indeed it seems to work with simple OpenSSL s_client piping to stdin/out.

I have made a fork with the changes here: https://github.com/MortenVinding/ssh-ssl-tls-tunnel

@slingamn
Copy link

Oh, that's very nice, thanks! I always thought of s_client as brittle but it's actually probably fine as long as either -ign_eof or -quiet is enabled.

@MortenVinding
Copy link

Oh, that's very nice, thanks! I always thought of s_client as brittle but it's actually probably fine as long as either -ign_eof or -quiet is enabled.

yes s_client disconnected almost immediately without it.
but it looks stable with -ign_eof.
didn’t try -quiet but it seems to imply -ign_eof without any session info, so might actually be more suited here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment