This is wildly over-complicated and also has a bunch of footguns and security risks.

For example, that very first NGINX section allows an attacker to direct their incoming traffic to any arbitrary listening port on localhost. They can even write a simple for loop in bash that would use curl to test all of the different ports. This also bypasses any firewall rules that you might have blocking traffic from the outside world.

be very careful following the instructions in this article.

Read the man page for SSH, and especially the remote forward section. https://man7.org/linux/man-pages/man1/ssh.1.html

▲

vbernat 6 hours ago | parent | next [-]

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

▲

jamiesonbecker 6 hours ago | parent [-]

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.

	▲	vbernat 5 hours ago \| parent [-]
		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).

▲

zac-builds 23 minutes ago | parent | prev [-]

[flagged]