On Tuesday 05 May 2009, Sascha Hlusiak wrote: > Am Dienstag 05 Mai 2009 23:28:22 schrieb Steve: > > Sascha Hlusiak wrote: > > > The easiest thing would probably be to just use ssh port forwarding > > > because you already have all the pieces running anyway. Wouldn't a > > > simple > > > > > > ssh -L 12345:secondapache:https u...@remotessh > > > > > > and the browsing to https://localhost:12345 do the trick? Or you could > > > use a pppd over ssh vpn, yes, but that is a bit more complex. > > > > > > - Sascha > > > > I really want to avoid having to access a non-standard port from the > > URLs - I want to use the final URLs exactly as they will be once the > > in-development website is eventually deployed. > > > > Can you recommend a 'how-to' for the pppd over ssh approach? > > # /usr/sbin/pppd pty "ssh r...@remoteserver pppd notty local > 10.0.0.1:10.0.0.2" noipdefault nodefaultroute noauth updetach > > You can also just create a file in /etc/ppp/peers/ with the following lines > and then call 'pon': > pty "ssh r...@remoteserver pppd notty local 10.0.0.1:10.0.0.2" > noipdefault > nodefaultroute > noauth > updetach > > You'll get the IP 10.0.0.2 and on the server 10.0.0.1. You need to setup > proper routing and maybe NAT for that separate subnet, but it will be a > tunnel into your home network. > > - Sascha
Or even simpler solution, can't you only allow access to https from your desired remote host IP address at your server's LAN firewall, or just use the accept/deny wrapper of the server itself after forwarding the https port at the firewall? -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
