The author of a blog post has built a trick: a personal server forwards a localhost port over SSH, then nginx proxies traffic back, with a hashed token guarding access. The method requires nothing more than OpenSSH and nginx.
How the Port Gets Forwarded
The trick starts with an SSH command that opens a remote tunnel. The author connects to a server called web02.luffy.cx and tells it to forward any connection arriving on a free port back to localhost:8080 on his machine.
The command looks like this:
ssh -N -R 0:localhost:8080 web02.luffy.cx
The server assigns a free port automatically. In the author’s example, it lands at 41535. That number becomes the public face of the whole setup.
What Nginx Does With It
Once the port is assigned, nginx takes over. The author configures it to listen on HTTPS across all addresses, routing requests from https://p41535.ssh.luffy.cx to http://127.0.0.1:41535 behind the scenes.
The configuration includes a DNS setup too. The author adds a CNAME record pointing *.ssh.luffy.cx at web02.luffy.cx and a wildcard certificate through Let’s Encrypt, with acme.luffy.cx handling the DNS-01 challenges.
The result is a working tunnel that anyone can reach by typing the assigned number into the URL.
Why the Token Matters
The exposed port is the only secret in the system. Anyone who guesses the number could reach the content. The author solves this by wrapping the URL in a hashed token that includes a secret, an expiration timestamp, and the port itself.
He uses the ngx_http_secure_link_module to compute the hash. The token appears as a username in the URL, followed by the expiration timestamp. Here is what the breakdown looks like:
https://6J3jK1WmB15c6WmjW_X-Wg--1789928654@p41535.ssh.luffy.cx/
The client sends the username with HTTP basic authentication. Nginx checks the hash against a stored value, which includes the timestamp, the port, and a fixed secret.
The module returns its status in a variable. An empty response means the hashes don’t match. A zero means the link has expired. Anything else means the token checks out.
An empty response means the hashes don’t match. A zero means the link has expired.
The Helper Script
The token approach works, but it is inconvenient. The author admits as much. He offers a helper script that finds the allocated port, generates the token, and displays the working URL.
The script searches for the ancestor sshd-session processes to find the port number, since OpenSSH does not expose the port in an environment variable. It then calculates the MD5 hash, encodes it, and formats the output.
The final command produces the token directly:
$ printf '%s %s %s' "$expires" "$port" "$secret" \
| openssl md5 -binary \
| openssl base64 \
| tr +/ -_ | tr -d =
The author installs the script on the server and adds an entry to ~/.ssh/config so users can call it easily.
Our View of the Trick
This is a neat hack. It uses standard tools in a clever combination. The token layer adds real security without requiring a special client or a commercial service.
The downside is the friction. Generating a token by hand is awkward, and the helper script, while effective, still asks the user to run commands on the server.
But the core idea holds up. A personal server, a free port, and a hashed URL can replace commercial tunnel services entirely. The author has shown how to build it yourself, and the method is worth remembering for anyone who needs a temporary exposure to a localhost service.
The trick works because it trusts the port number as the secret and layers the hash on top. The script eases the pain of manual calculation. The author’s method is a practical example of what you can build with only OpenSSH and nginx.
Source material: “Self-hosted HTTP tunnels with SSH and Nginx,” bernat.ch.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.