Hacker News Reader

The attack you mention is solved in the second part of the article.

I did notice that you tried to mitigate the risk, but why not just pick a high port rather than this complex redirection?

Your scheme is smart and creative but unnecessarily risky.

SSH can do remote listens to the world by itself, no second nginx needed, but sish or ngrok might be a better solution for the general case.

Anytime you punch holes, you're taking a risk, so make it as narrow as you can.

It's already using a high port. Forwarding a high port directly with SSH prevent exposing the service through a virtual host and provide HTTPS (but I didn't think of it until your mentioned it). And it would open the service to be discovered by enumerating all possible ports, like you mentioned in your first comment.

sish and ngrok are mentioned in the intro along with the reasons I didn't go this way (specific SSH server to run for the first and not self-hosted for the later).

This domain is crowded with solutions. I only explored that myself because the "free" solutions only requiring an SSH client were unreliable, including the free tier of ngrok (broken SSH tunnel).

Reply on news.ycombinator.com