sslh

Search the Azure Marketplace for sslh, select the SecureAnyCloud publisher, and select Create.

Add these network security group (NSG) rules, each from the networks you connect from:

• TCP 443, the multiplexed port that carries SSH, HTTPS and HTTP
• TCP 22, direct admin SSH, which stays available independently of the multiplexer
• TCP 80, the HTTP-to-HTTPS redirect and the health probe

RG="sslh-prod"; LOCATION="eastus"; VM_NAME="sslh-01" IMAGE_URN="sac1647283583153:sslh:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name sslh-vnet --address-prefix 10.100.0.0/16 --subnet-name sslh-subnet --subnet-prefix 10.100.1.0/24 az network nsg create -g "$RG" --name sslh-nsg az network nsg rule create -g "$RG" --nsg-name sslh-nsg --name allow-mux --priority 100 \
  --destination-port-ranges 443 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name sslh-nsg --name allow-ssh --priority 110 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name sslh-nsg --name allow-http --priority 120 \
  --destination-port-ranges 80 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:sslh:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name sslh-vnet --subnet sslh-subnet --nsg sslh-nsg --public-ip-sku Standard

Connect over SSH on port 22. Confirm that the three services are active, then read the listener table. The table shows how the appliance is built: sslh alone holds the public port 443, while the backends it routes to are bound to the loopback interface, where nothing outside the VM can reach them directly.

sudo systemctl is-active sslh nginx ssh
sudo ss -tlnp | grep -E ':443|:8443|:8080' cat /opt/sslh/VERSION

systemctl is-active prints active three times. The listener table shows sslh on 0.0.0.0:443 and nginx on 127.0.0.1:8443 and 127.0.0.1:8080. /opt/sslh/VERSION records the exact upstream tag the binary was compiled from.

Open three connections to the same port 443 and watch each one land on a different service. The TLS connection reaches the HTTPS backend, the SSH connection receives a real OpenSSH protocol banner, and the plain HTTP connection reaches the HTTP backend:

curl -sk -o /dev/null -w 'TLS on 443 -> HTTP %{http_code}\n' https://127.0.0.1:443/
curl -sk https://127.0.0.1:443/ | grep -q 'TLS backend' && echo "TLS on 443 -> routed to the HTTPS backend" timeout 10 bash -c 'exec 3<>/dev/tcp/127.0.0.1/443; printf "SSH-2.0-sac_demo\r\n" >&3; IFS= read -t 8 -r l <&3; printf "%s\n" "$l"' | tr -d '\r'
curl -s http://127.0.0.1:443/ | grep -q 'HTTP backend' && echo "HTTP on 443 -> routed to the HTTP backend"

The third command needs a short explanation. sslh identifies SSH from the client's own identification string, so the probe writes SSH-2.0-... first and then reads. The reply is the banner of the VM's OpenSSH server, for example SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18. That banner shows that port 443 handed the connection to sshd.

The image also ships a single command that runs all three checks and fails with a clear message if any route is wrong:

sudo /usr/local/sbin/sslh-selftest

On success it prints one sslh-selftest OK: line that names each backend it reached. If a route is broken, it exits non-zero with a FAIL reason. Run it after every configuration change.

The previous steps ran on the VM. The value of sslh is what it lets you do from outside, over a network that only permits port 443. From your workstation, run:

ssh -p 443 azureuser@<public-ip> curl -k https://<public-ip>/

Both commands use port 443. To make ssh -p 443 the default for this host, add an entry to your ~/.ssh/config:

Host my-sslh-host HostName <public-ip> User azureuser Port 443

Port 22 stays open, so you keep direct administrative access when you change the multiplexer configuration.

One file, /etc/sslh/sslh.cfg, defines all of this behaviour. Read it:

sudo cat /etc/sslh/sslh.cfg

The listen block is the single public port. The protocols block is the routing table, and order matters: sslh tries each probe in turn and uses the first that matches, so the anyprot catch-all must stay last.

on-timeout: "ssh" covers protocols where the server speaks first and the client sends nothing. user: "sslh" is the unprivileged account that sslh permanently drops to once it has bound port 443.

The shipped backends let the appliance work standalone. To multiplex your own services, change the host and port of the tls and http entries to where your services listen. Those services can be on the VM or on another host, anywhere sslh can reach. Find the lines to edit:

sudo grep -nE 'name: "(tls|http)"' /etc/sslh/sslh.cfg

Edit those lines in /etc/sslh/sslh.cfg. For example, point tls at 127.0.0.1 port 8443 on your own web server, or at another host. Then restart sslh to apply the change:

sudo systemctl restart sslh

You can run sudo /usr/local/sbin/sslh-selftest again afterwards. Its TLS and HTTP checks look for the shipped demonstration pages, so once you repoint those routes at your own services, the self test reports a mismatch. At that point, verify with curl against your own service instead.

Adding more protocols. sslh can also probe OpenVPN, XMPP, TINC, SOCKS and others. It can match on TLS ALPN or SNI so that several TLS services share the port. Add further entries to the protocols block in the same shape, and keep anyprot last. Run man sslh on the VM for the full list of probes and options.

The per-instance self-signed certificate gets you started, but browsers warn about it. Point a DNS name that you control at the VM public IP, then install a certificate for that name:

sudo cp /path/to/fullchain-<your-domain>.pem /etc/nginx/tls/cert.pem
sudo cp /path/to/privkey-<your-domain>.pem /etc/nginx/tls/key.pem
sudo systemctl reload nginx

If you repointed the tls route at your own service instead of the shipped nginx backend, install the certificate on that service. Either way, sslh is unaffected. It never terminates TLS: it recognises TLS and forwards the connection untouched, so only the service that terminates TLS sees your certificate and private key.

Component Version / Detail

Multiplexer sslh (latest stable upstream tag, compiled reproducibly, see /opt/sslh/VERSION)

Binaries /usr/local/sbin/sslh (sslh-fork), plus sslh-select and sslh-ev

Public port 0.0.0.0:443 held by sslh, routing ssh, tls, http, anyprot

SSH backend the VM's own OpenSSH server on 127.0.0.1:22 (also reachable directly on port 22)

TLS backend nginx on 127.0.0.1:8443, per instance certificate in /etc/nginx/tls/

HTTP backend nginx on 127.0.0.1:8080

Front helper nginx on :80 (unauthenticated /healthz, 301 to HTTPS)

Configuration /etc/sslh/sslh.cfg

Self test /usr/local/sbin/sslh-selftest

Privileges binds 443 as root, drops permanently to the sslh account

Operating system Ubuntu 24.04 LTS (patched at build)

License GPL-2.0 (sslh), source at /opt/sslh/src/

sudo systemctl is-active sslh nginx
sudo journalctl -u sslh --no-pager | tail -5

Apply a configuration change with sudo systemctl restart sslh. Follow the logs live with sudo journalctl -u sslh -f. On first boot, the image writes a summary of this VM's endpoints to /root/sslh-credentials.txt. Read it with sudo cat /root/sslh-credentials.txt.

To log the protocol decision for each connection, add verbose-connections: 1; to /etc/sslh/sslh.cfg and restart. Check this log first if a client is routed to the wrong backend.

Switching backend. sslh-fork is the default and forks a process per connection. For very high connection rates, point the ExecStart line in /etc/systemd/system/sslh.service at /usr/local/sbin/sslh-ev or /usr/local/sbin/sslh-select. Both handle all connections in a single process. Then run sudo systemctl daemon-reload and restart sslh.

sslh does not add authentication and does not terminate TLS. It only routes connections. Every backend keeps its own security, so keep SSH on key-only authentication and keep your TLS service's certificate configuration correct.

Restrict the NSG. Allow port 443 from the networks your users connect from. Restrict port 22 to your management range, so that you always have an administrative route that does not depend on the multiplexer.

Keep backends on the loopback. The shipped backends are bound to 127.0.0.1, so they are reachable only through sslh. If you repoint a route at another host, restrict that host's firewall to the sslh VM.

Plan for client IP addresses. Backends see connections from the sslh VM, not from the original client, because transparent mode is not enabled by default (it needs additional routing rules). If a backend needs the true client address, enable sslh's transparent proxy mode as described in man sslh, or use the PROXY protocol where the backend supports it.

Use a trusted certificate and your own domain (Step 8), so that clients validate the service without a manual trust step.

Keep the OS patched. Unattended security upgrades stay enabled on the running VM.

sslh is distributed under the GNU General Public License version 2. Because the GPL is a copyleft licence, this image carries both of the things that licence requires: the verbatim licence text at /opt/sslh/LICENSE, and the complete corresponding source for the binaries it runs at /opt/sslh/src/, with rebuild instructions in /opt/sslh/README.sac. sslh is redistributed unmodified.

SecureAnyCloud provides the packaging, the systemd integration, the working demonstration backends, the per instance TLS bootstrap, the self test tooling, and 24/7 support with a guaranteed 24 hour response SLA. sslh is an independent open source project by Yves Rutschle and this image is not affiliated with or endorsed by the sslh project or its authors.

Deploy on Azure

Find sslh on Ubuntu 24.04 on the Azure Marketplace, published by SecureAnyCloud. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email sales@secureanycloud.com for deployment help, configuration questions, or licensing enquiries.

Deploy on Azure

Launch sslh on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com