Instructions on how to SSH on airplane WiFi that blocks port 22

ssh-airplane-wifi.md

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!

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.

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?

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?

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.)

Maybe this changed since I last tried. Did you find a technique that worked?

…

On Thu, Sep 12, 2019 at 3:46 PM Shivaram Lingamneni < ***@***.***> wrote: 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.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://gist.github.com/eeaa54b328952d260472c14c559f698a?email_source=notifications&email_token=ABGEHKUFCSJTI4RP4SDS27TQJKMARA5CNFSM4HJHPKH2YY3PNVWWK3TUL52HS4DFVNDWS43UINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAFYWG6#gistcomment-3026031>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGEHKSULPS4L7BDE76PNBTQJKMARANCNFSM4HJHPKHQ> .

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.

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

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

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
...

VPN also works on JetBlue (ExpressVPN)

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

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.

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.