Subject: Re: Persistent tunnel
To: Jan Danielsson <jan.m.danielsson@gmail.com>
From: Magnus Eriksson <magetoo@fastmail.fm>
List: netbsd-users
Date: 12/15/2006 13:11:54
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