Live data from Hacker News

Putting Raspberry Pi Online with Caddy and SSH Tunnel

gist.github.com

11–20 of 157 posts

Re: Putting Raspberry Pi Online with Caddy and SSH Tunnel

#11
post #2

I think a better option would be to create a Wireguard tunnel between Raspberry Pi and the remote server instead of a SSH Tunnel. Then there is no need to add or change ports and restart the tunnel for every service.

OP's solution sound good enough for their needs. Solutions can always be improved, but it's not always worth doing that.

OP has literally written in the gist about exploring a way to map entire port range and avoiding doing this, so the non hacky way of doing this is setting up something like a wireguard tunnel. That's the reason I suggested doing this instead of a tunnel which has other disadvantages like doing TCP on TCP.

Re: Putting Raspberry Pi Online with Caddy and SSH Tunnel

#12
Look at https://h2o.examp1e.net/

H2O web server seems to be faster than nginx , litespeed and supports http1/http2/http3 . It's config file is yaml file.

For HTTPS, i recommend https://acme.sh . It's very very easy and autorenews certificates using cron job.

Re: Putting Raspberry Pi Online with Caddy and SSH Tunnel

#13

> I disabled nginx on the server and installed Caddy instead. I wonder how a somehow simpler config syntax (Caddyfile) compares to a simpler maintenance system (apt).

Caddy underwent a complete rewrite that also invalidated most of the existing config. Personally I don't see any benefits in using caddy or another non mainstream httpd as it adds more risk to my project with usually very little benefits. Nothing against using it for hobby projects but in production I've migrated back to nginx.

Re: Putting Raspberry Pi Online with Caddy and SSH Tunnel

#17

Check with your ISP to see if you have IPv6 available, and use that. I have a cheap VPS that I can jump through if I'm on an IPv4 only host.

The solution in TFA works behind NAT and routers/firewalls, and has the added benefit of encrypting all of the traffic between the two machines thanks to SSH.

I’m not sure people who aren’t network administrators should be putting public IPv6 all over their LAN behind their router, at least not until v6 is more common and routers have better inbound security features for such things (like how NAT functions today for v4).

Re: Putting Raspberry Pi Online with Caddy and SSH Tunnel

#18

Earlier quoted context omitted.

OP's solution sound good enough for their needs. Solutions can always be improved, but it's not always worth doing that.

OP has literally written in the gist about exploring a way to map entire port range and avoiding doing this, so the non hacky way of doing this is setting up something like a wireguard tunnel. That's the reason I suggested doing this instead of a tunnel which has other disadvantages like doing TCP on TCP.

SSH tunnels do not run TCP inside of them, just the bytes of the connection data itself.

The only TCP in use is the TCP connection of the SSH connection between hosts.

Re: Putting Raspberry Pi Online with Caddy and SSH Tunnel

#19
post #18

Earlier quoted context omitted.

OP has literally written in the gist about exploring a way to map entire port range and avoiding doing this, so the non hacky way of doing this is setting up something like a wireguard tunnel. That's the reason I suggested doing this instead of a tunnel which has other disadvantages like doing TCP on TCP.

SSH tunnels do not run TCP inside of them, just the bytes of the connection data itself. The only TCP in use is the TCP connection of the SSH connection between hosts.

Ohh TIL but my other point still stands.

Re: Putting Raspberry Pi Online with Caddy and SSH Tunnel

#20
post #17

Check with your ISP to see if you have IPv6 available, and use that. I have a cheap VPS that I can jump through if I'm on an IPv4 only host.

The solution in TFA works behind NAT and routers/firewalls, and has the added benefit of encrypting all of the traffic between the two machines thanks to SSH. I’m not sure people who aren’t network administrators should be putting public IPv6 all over their LAN behind their router, at least not until v6 is more common and routers have better inbound security features for such things (like how NAT functions today for…

NAT like security for IPv6 is just dumb. We should always configure firewall for v4 and V6. NAT is not for security!! It has different purpose which is now being taken care by V6 and NAT should just die.
Post reply on HN