I read up a bit on stunnel, and it seems a little messy, requiring you 
to deal with SSL certificates for authentication.  (But I could be wrong.)

   So unless you eat SSL certification for breakfast, and if a VPN solution 
isn't what you want, there are a couple of command line options for ssh to 
deal with the first minor nit:


On Fri, 15 Dec 2006, Jan Danielsson wrote:

>   - Sometimes I switch to the ssh tunnel-window in screen, and start
> typing things.. And nothing works as I expect. And after a while I
> realize that I'm not on my local system as I was expecting, but rather
> in ssh shell I used to establish the tunnels. :-)


   Looks like the -N option would take care of this, assuming my ancient 
man page is still relevant.


      -N      Do not execute a remote command.  This is useful for just for-
              warding ports (protocol version 2 only).

      -n      Redirects stdin from /dev/null (actually, prevents reading from
              stdin).  This must be used when ssh is run in the background. [...]

      -f      Requests ssh to go to background just before command execution.
              This is useful if ssh is going to ask for passwords or passphras-
              es, but the user wants it in the background.  This implies -n.


So, something like: 'ssh -n -N <other options> host &'

or with password auth: 'ssh -f -N <other options> host'


   And -f might not be necessary even if ssh asks for a password, if you're 
in X and normally get the dialog window for that sort of thing.  Which is 
good, since -f effectively "hides" ssh from the normal shell job control 
commands.


   Or just 'ssh -N', and be stuck with a confusing non-prompt instead of a 
confusing prompt.  :-)


   Alternatively, just make the remote command prompt different enough that 
you'll notice; insert the hostname perhaps.  Yes, I know, it's too simple, 
but it works for me.


MAgnus