Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Out of curiosity, why not a simple reverse proxy on the VPS (that only adds client real IP to headers), tunneled to a full reverse proxy on the home server (that does host routing and everything else) through a SSH tunnel?
How would that kind of a setup look like?
Variant 1:
Pro: very secure, VPS doesn't store any sensitive data (no TLS certificates, only a SSH public key) and the client connections pass through the VPS double-encrypted (TLS between client browser and home proxy, wrapped inside SSH).
Con: you don't get the client's IP. When the home apps receive the connections they appear to originate at the home end of the SSH tunnel, which is a private interface on the home server.
Variant 2 (in case you need client IPs):
Pro: by decrypting the TLS connection the simple proxy can add the client's IP to the HTTP headers, making it available to logs and apps at home.
Con: the VPS needs to store the TLS certificates for all the domains you're serving, you need to copy fresh certificates to the VPS whenever they expire, and the unencrypted connections are available on the VPS between the exit from TLS and the entry into the SSH tunnel.
Edit: Variant 3? proxy protocol
I've never tried this but apparently there's a so called proxy_protocol that can be used to attach information such as client IP to TLS connections without terminating them.
You would still need a VPS proxy and a home proxy like in variant 2, and they both need to support proxy protocol.
The frontend (VPS) proxy would forward connections in stream mode and use proxy protocol to add client info on the outside.
The backend (home) proxy would terminate TLS and do host routing etc. but also it can unpack client IP from the proxy protocol and place it in HTTP headers for apps and logs.
Pro: It's basically the best of both variant 1 and 2. TLS connections don't need to be terminated half-way, but you still get client IPs.
Please note that it's up to you to weigh the pros and cons of having the client IPs or not. In some circumstances it may actually be a feature to not log client IPs, for example If you expect you might be compelled to provide logs to someone.
Very interesting... How do I get started?
The SSH tunnel is just one command, but you may want to use autossh to restart it if it fails.
If you choose variant 2 you will need to configure a pass-through reverse proxy on the VPS that does TLS termination (uses correct certificates for each domain on 443). Look into nginx, caddy, traefik or haproxy.
For the full home proxy you will once again need a proxy but you'll additionally need to do host routing to direct each (sub)domain to the correct app. You'll probably want to use the same proxy as above to avoid learning two different proxies.
I would recommend either caddy (both) or nginx (vps) + nginx proxy manager (home) if you're a beginner.
How do I make the SSH tunnel forward traffic? It can't be as easy as just running
ssh user@SERVER_IP
in the terminal.(I only need variant 1 btw)
You also add the -R parameter:
https://linuxize.com/post/how-to-setup-ssh-tunneling/ (you want the "remote port forwarding"). ssh -R, -L and -D options are magical, more people should learn about them.
You may also need to open access to port 443 on the VPS. How you do that depends on the VPS service, check their documentation.
Hi, whenever I try to enter the ports 80 and 443 at the beginning of the -R parameter, I get this error:
Warning: remote port forwarding failed for listen port 80
. How do I fix this?Ah yes. Ports below 1024 are normally privileged and only superuser can use them (and the account you're using to ssh in is not and should not be root).
This link has several possible solutions: https://unix.stackexchange.com/questions/10735/allowing-a-regular-user-to-listen-to-a-port-below-1024