pull down to refresh

Good guide, but for those interested in ease and simplicity Wireguard is overkill and a major PITA
Once you have SSH set up on your VPS all you need to do is connect your node to it with a reverse tunnel flag, ssh -N -R 8080:localhost:8080 root@vps
That would present 8080 on the VPS as 8080 on your local system, so you can just run Caddy/Nginx/nc or whatever on the VPS
115 sats \ 1 reply \ @random_ 11 Jul
How to keep the connection persistent? For example, if the vps gets rebooted, etc.
reply
Run it via systemd, create and enable a unit file and it will automate a restart on failure or on boot
[Unit] Description=Establish SSH Reverse Tunnel to VPS After=network.target [Service] ExecStart=/usr/bin/ssh -N -R 8080:localhost:8080 root
reply
100 sats \ 2 replies \ @Hakuna 11 Jul
ssh -N -R 8080:localhost:8080 root@vps
Valid points, however everyone needs to make their own choice of convenience vs speed & security. As I'm putting my own sats on the line, I err on latter.
Summary For maximum security and speed: As said wg would be my recommended choice, and we have it in productions with many VPNs and clients across the globe. And following that guide isn't that much PITA, but actually a great linux learning experience. I'd say this is a good asset if you're into running a node in any case.
For simplicity and quick setup: SSH tunneling can be a decent option, especially for temporary or less sensitive use cases.
reply
ehh.. those are very unsubstantial claims... Are you suggesting SSH is cryptographically broken and ignoring that it has far more production use in the wild than anything else?
Speed I'd give you sure, but the kind of things one would use it for is not going to be noticeable
It's probably a better Linux 101 to understand the vast capabilities inherent to SSH and get the user terminal maxxing
reply
101 sats \ 0 replies \ @Hakuna 11 Jul
I'm not suggesting the cryptography is broken, but having an ongoing SSH root tunnel exposes unnecessary attack vectors. Terrapin was just the recent one, and I'm in favor to not have my ssh in the open at all.
Yes you can FW restrict the access to specific ip ranges, but then you're back into the configuration and security overhead you intended to avoid in the first place.
Read my summary, I think it's a valid option, but I wouldn't want this for my production routing node running for 4 years 24/7
reply