Sish : HTTP(S)/WS(S)/TCP Tunnels To Localhost Using Only SSH

Sish is an open source serveo/ngrok alternative.

Builds are made automatically for each commit to the repo and are pushed to Dockerhub. Builds are tagged using a commit sha, branch name, tag, latest if released on main. You can find a list here. Each release builds separate sish binaries that can be downloaded from here for various OS/archs. Feel free to either use the automated binaries or to build your own. If you submit a PR, images are not built by default and will require a retag from a maintainer to be built.

• Pull the Docker image

docker pull antoniomika/sish:latest

• Run the image

docker run -itd –name sish \ -v ~/sish/ssl:/ssl \ -v ~/sish/keys:/keys \ -v ~/sish/pubkeys:/pubkeys \ –net=host antoniomika/sish:latest \ –ssh-address=:22 \ –http-address=:80 \ –https-address=:443 \ –https=true \ –https-certificate-directory=/ssl \ –authentication-keys-directory=/pubkeys \ –private-key-location=/keys/ssh_key \ –bind-random-ports=false

• SSH to your host to communicate with sish

ssh -p 2222 -R 80:localhost:8080 ssi.sh

Docker Compose

You can also use Docker Compose to setup your sish instance. This includes taking care of SSL via Let’s Encrypt for you. This uses the adferrand/dnsrobocert container to handle issuing wildcard certifications over DNS. For more information on how to use this, head to that link above. Generally, you can deploy your service like so:

docker-compose -f deploy/docker-compose.yml up -d

The domain and DNS auth info in deploy/docker-compose.yml and deploy/le-config.yml should be updated to reflect your needs. You will also need to create a symlink that points to your domain’s Let’s Encrypt certificates like:

ln -s /etc/letsencrypt/live/<your domain>/fullchain.pem deploy/ssl/<your domain>.crt
ln -s /etc/letsencrypt/live/<your domain>/privkey.pem deploy/ssl/<your domain>.key

Careful: the symlinks need to point to /etc/letsencrypt, not a relative path. The symlinks will not resolve on the host filesystem, but they will resolve inside of the sish container because it mounts the letsencrypt files in /etc/letsencrypt, not ./letsencrypt.

I use these files in my deployment of ssi.sh and have included them here for consistency.

Google Cloud Platform

There is a tutorial for creating an instance in Google Cloud Platform with sish fully setup that can be found here. It can be accessed through Google Cloud Shell.

How it works?

SSH can normally forward local and remote ports. This service implements an SSH server that only handles forwarding and nothing else. The service supports multiplexing connections over HTTP/HTTPS with WebSocket support. Just assign a remote port as port 80 to proxy HTTP traffic and 443 to proxy HTTPS traffic. If you use any other remote port, the server will listen to the port for TCP connections, but only if that port is available.

You can choose your own subdomain instead of relying on a randomly assigned one by setting the --bind-random-subdomains option to false and then selecting a subdomain by prepending it to the remote port specifier:

ssh -p 2222 -R foo:80:localhost:8080 ssi.sh

If the selected subdomain is not taken, it will be assigned to your connection.

Supported Forwarding Types

• HTTP Forwarding

sish can forward any number of HTTP connections through SSH. It also provides logging the connections to the connected client that has forwarded the connection and a web interface to see full request and responses made to each forwarded connection. Each webinterface can be unique to the forwarded connection or use a unified access token. To make use of HTTP forwarding, ports [80, 443] are used to tell sish that a HTTP connection is being forwarded and that HTTP virtualhosting should be defined for the service. For example, let’s say I’m developing a HTTP webservice on my laptop at port 8080 that uses websockets and I want to show one of my coworkers who is not near me. I can forward the connection like so:

ssh -R hereiam:80:localhost:8080 ssi.sh

And then share the link https://hereiam.ssi.sh with my coworker. They should be able to access the service seamlessly over HTTPS, with full websocket support working fine. Let’s say hereiam.ssi.sh isn’t available, then sish will generate a random subdomain and give that to me.

• TCP Forwarding

Any TCP based service can be used with sish for TCP and alias forwarding. TCP forwarding will establish a remote port on the server that you deploy sish to and will forward all connections to that port through the SSH connection and to your local device. For example, if I was to run a SSH server on my laptop with port 22 and want to be able to access it from anywhere at ssi.sh:2222, I can use an SSH command on my laptop like so to forward the connection:

ssh -R 2222:localhost:22 ssi.sh

I can use the forwarded connection to then access my laptop from anywhere:

ssh -p 2222 ssi.sh

• TCP alias forwarding

Let’s say instead I don’t want the service to be accessible by the rest of the world, you can then use a TCP alias. A TCP alias is a type of forwarded TCP connection that only exists inside of sish. You can gain access to the alias by using SSH with the -W flag, which will forwarding the SSH process’ stdin/stdout to the fowarded TCP connection. In combination with authentication, this will guarantee your remote service is safe from the rest of the world because you need to login to sish before you can access it. Changing the example above for this would mean running the following command on my laptop:

ssh -R mylaptop:22:localhost:22 ssi.sh

sish won’t publish port 22 or 2222 to the rest of the world anymore, instead it’ll retain a pointer saying that TCP connections made from within SSH after a user has authenticated to mylaptop:22 should be forwarded to the forwarded TCP tunnel. Then I can use the forwarded connection access my laptop from anywhere using:

ssh -o ProxyCommand=”ssh -W %h:%p ssi.sh” mylaptop

Shorthand for which is this with newer SSH versions:

ssh -J ssi.sh mylaptop

Authentication

If you want to use this service privately, it supports both public key and password authentication. To enable authentication, set --authentication=true as one of your CLI options and be sure to configure --authentication-password or --authentication-keys-directory to your liking. The directory provided by --authentication-keys-directory is watched for changes and will reload the authorized keys automatically. The authorized cert index is regenerated on directory modification, so removed public keys will also automatically be removed. Files in this directory can either be single key per file, or multiple keys per file separated by newlines, similar to authorized_keys. Password auth can be disabled by setting --authentication-password="" as a CLI option.

One of my favorite ways of using this for authentication is like so:

sish@sish0:~/sish/pubkeys# curl https://github.com/antoniomika.keys > antoniomika

This will load my public keys from GitHub, place them in the directory that sish is watching, and then load the pubkey. As soon as this command is run, I can SSH normally and it will authorize me.

Custom Domains

sish supports allowing users to bring custom domains to the service, but SSH key auth is required to be enabled. To use this feature, you must setup TXT and CNAME/A records for the domain/subdomain you would like to use for your forwarded connection. The CNAME/A record must point to the domain or IP that is hosting sish. The TXT record must be be a key=val string that looks like:

sish=SSHKEYFINGERPRINT

Where SSHKEYFINGERPRINT is the fingerprint of the key used for logging into the server. You can set multiple TXT records and sish will check all of them to ensure at least one is a match. You can retrieve your key fingerprint by running:

ssh-keygen -lf ~/.ssh/id_rsa | awk ‘{print $2}’

If you trust the users connecting to sish and would like to allow any domain to be used with sish (bypassing verification), there are a few added flags to aid in this. This is especially useful when adding multiple wildcard certificates to sish in order to not need to automatically provision Let’s Encrypt certs. To disable verfication, set --bind-any-host=true, which will allow and subdomain/domain combination to be used. To only allow subdomains of a certain subset of domains, you can set --bind-hosts to a comma separated list of domains that are allowed to be bound.

To add certficates for sish to use, configure the --https-certificate-directory flag to point to a dir that is accessible by sish. In the directory, sish will look for a combination of files that look like name.crt and name.key. name can be arbitrary in either case, it just needs to be unique to the cert and key pair to allow them to be loaded into sish.

Load Balancing

sish can load balance any type of forwarded connection, but this needs to be enabled when starting sish using the --http-load-balancer, --tcp-load-balancer, and --alias-load-balancer flags. Let’s say you have a few edge nodes (raspberry pis) that are running a service internally but you want to be able to balance load across these devices from the outside world. By enabling load balancing in sish, this happens automatically when a device with the same forwarded TCP port, alias, or HTTP subdomain connects to sish. Connections will then be evenly distributed to whatever nodes are connected to sish that match the forwarded connection.

Whitelisting IPs

Whitelisting IP ranges or countries is also possible. Whole CIDR ranges can be specified with the --whitelisted-ips option that accepts a comma-separated string like “192.30.252.0/22,185.199.108.0/22”. If you want to whitelist a single IP, use the /32 range.

To whitelist countries, use --whitelisted-countries with a comma-separated string of countries in ISO format (for example, “pt” for Portugal). You’ll also need to set --geodb to true.

DNS Setup

To use sish, you need to add a wildcard DNS record that is used for multiplexed subdomains. Adding an A record with * as the subdomain to the IP address of your server is the simplest way to achieve this configuration.

Demo – At this time, the demo instance has been set to require auth due to abuse

There is a demo service (and my private instance) currently running on ssi.sh that doesn’t require any authentication. This service provides default logging (errors, connection IP/username, and pubkey fingerprint). I do not log any of the password authentication data or the data sent within the service/tunnels. My deploy uses the exact deploy steps that are listed above. This instance is for testing and educational purposes only. You can deploy this extremely easily on any host (Google Cloud Platform provides an always-free instance that this should run perfectly on). If the service begins to accrue a lot of traffic, I will enable authentication and then you can reach out to me to get your SSH key whitelisted (make sure it’s on GitHub and you provide me with your GitHub username).

Notes

1. This is by no means production ready in any way. This was hacked together and solves a fairly specific use case.
   • You can help it get production ready by submitting PRs/reviewing code/writing tests/etc
2. This is a fairly simple implementation, I’ve intentionally cut corners in some places to make it easier to write.
3. If you have any questions or comments, feel free to reach out via email me@antoniomika.me or on freenode IRC #sish

Upgrading To v1.0

There are numerous breaking changes in sish between pre-1.0 and post-1.0 versions. The largest changes are found in the mapping of command flags and configuration params. Those have changed drastically, but it should be easy to find the new counterpart. The other change is SSH keys that are supported for host key auth. sish continues to support most modern keys, but by default if a host key is not found, it will create an OpenSSH ED25519 key to use. Previous versions of sish would aes encrypt the pem block of this private key, but we have since moved to using the native OpenSSH private key format to allow for easy interop between OpenSSH tools. For this reason, you will either have to manually convert an AES encrypted key or generate a new one.