4 ms·

How does that help you access your app from some other machine? And how does ssh help you get secure access from a remote browser to the tunneled port? The ss

How does that help you access your app from some other machine? And how does ssh help you get secure access from a remote browser to the tunneled port? The ssh security is only from the tunneled port to your local port.

pdkl95 9y ago
There commands above are suggesting two tunnels, appropriate for when both parties have private IP addresses behind NATing routers. This requires a rendezvous server with a publicly visible IP address, The first (with -R) forwards the listening port of the local private server to the rendezvous server: ssh -nNT -R 8080:localhost:80 rendezvous.example.com This allows connections to the private local server from processes on rendezvous.example.com which connect to their localhost:8080. This requires configuring "GatewayPorts yes" on the rendezvous server, which is disabled by default. The person you are sharing with then sets up their tunnel to using the forwarded port: ssh -L 8081:localhost:80 rendezvous.example.com (port number changed to distinguish between the endpoints) This creates a tunnel from their localhost:8081 to rendezvous.example.com:8080, which is then forwarded to port 80 on your server that you wanted to share. Both tunnels are encrypted. While traffic analysis is still possible, the tunnels also obscure the details of each request; eavesdroppers only see the tunnels as a stream of encrypted data regardless of how many GET/POST requests actually happen. If one side has a public address that can be directly accessed, the rendezvous server is not needed; just use one tunnel. The fact that we ever need a rendezvous server is part of the incredible damage IP Masquerading (private IPv4 addresses behind NAT) has done to the internet. Working around "party lines" is incredibly frustrating. If you're setting up many forwarded ports, it may be easier to use a SOCKS proxy server (ssh option -D <local_proxy_port) instead of many "ssh -L" tunnels. The other side (-R) will be the same.
- Symbiote 9y ago
  With a public address, and control of the firewall, this isn't even needed. We have a /23. I've opened ports 7000-7010 to a few developers' computers, so they can easily share what they're working on when they want to. With IPv6, anyone can do this.

pdkl95 9y ago

There commands above are suggesting two tunnels, appropriate for when both parties have private IP addresses behind NATing routers. This requires a rendezvous server with a publicly visible IP address, The first (with -R) forwards the listening port of the local private server to the rendezvous server: ssh -nNT -R 8080:localhost:80 rendezvous.example.com This allows connections to the private local server from processes on rendezvous.example.com which connect to their localhost:8080. This requires configuring "GatewayPorts yes" on the rendezvous server, which is disabled by default. The person you are sharing with then sets up their tunnel to using the forwarded port: ssh -L 8081:localhost:80 rendezvous.example.com (port number changed to distinguish between the endpoints) This creates a tunnel from their localhost:8081 to rendezvous.example.com:8080, which is then forwarded to port 80 on your server that you wanted to share. Both tunnels are encrypted. While traffic analysis is still possible, the tunnels also obscure the details of each request; eavesdroppers only see the tunnels as a stream of encrypted data regardless of how many GET/POST requests actually happen. If one side has a public address that can be directly accessed, the rendezvous server is not needed; just use one tunnel. The fact that we ever need a rendezvous server is part of the incredible damage IP Masquerading (private IPv4 addresses behind NAT) has done to the internet. Working around "party lines" is incredibly frustrating. If you're setting up many forwarded ports, it may be easier to use a SOCKS proxy server (ssh option -D <local_proxy_port) instead of many "ssh -L" tunnels. The other side (-R) will be the same.

Symbiote 9y ago
With a public address, and control of the firewall, this isn't even needed. We have a /23. I've opened ports 7000-7010 to a few developers' computers, so they can easily share what they're working on when they want to. With IPv6, anyone can do this.