Re: checking ssh tunnels: best practices?
Thanks, Xavier, Vivek:
On Thu, May 22, 2003 at 09:48:33AM -0400, xavier renaut wrote:
>
> |The problem is that sometimes these programs don't work
> |right and hassle ensues if I start them up without starting
> |up my ssh session first, or if the ssh session has dropped
> |someplace along the way. A lot of the time I'm working
> |locally, so I might not notice that the tunnel went away,
> |and exim will tell me that the message couldn't be
> |delivered, etc.
>
> you could use a vpn (vtun, openvpn)
> which tries all the time to connect.
Well, I looked at some, and they seem to use special kernel opts and
modules. I don't mind tweaking my own kernel but am not prepared to
tweak the kernels of the shared machines between me and the net.
> you could start ssh automatically with a wrapper to restart it
> each time the connexion is dropped. (and start all of this
> inside of a screen) :
>
> wrapper :
>
> #!/bin/sh
> while ($e);do $@ ;date;echo "$@... ";echo sleeping 300;sleep 300 ;done
>
> screenrc :
> defescape ^na
> escape ^na
> nethack on
> startup_message off
> vbell on
> defscrollback 1024
> deflogin off
> obuflimit 30000
> screen wrapper.sh ssh -L 2525:localhost:25 mailhost
>
> startup script :
> screen -d -m -S tunnel -c ~/.screenrc
>
> and link the startup script from, say, /etc/rc2.d/S80screen
OK, I think I see what you're getting at. In my case, I'd probably
start it in an xterm rather than in screen (I'm not familiar with it).
On Thu, May 22, 2003 at 11:25:11AM +0100, Vivek wrote:
> On Wed, 21 May 2003, Tony Godshall wrote:
>
> > The problem is that sometimes these programs don't work
> > right and hassle ensues if I start them up without starting
> > up my ssh session first, or if the ssh session has dropped
>
> [snip]
>
> Perhaps an inetd based solution would be simpler?
Hmmm. An idea.
For that to work the script I hook into inetd would have to
be smart enough to figure out where it is (home, office,
jobsite) and Do The Right Thing (I have to ssh through
different bastions to get to the mail server).
I've played with whereami and tho it didn't seem to fit
situation quite right, maybe I can follow its detect.conf
example and use mii-tool (detect whether network cable is
connected) and arping (detect which network I'm on) to that
end.
A downside with using inetd is that the ssh connections
take a few seconds to come up, and the one that does the
actual tunnelling (back to my laptop) sometimes doesn't come
up on the first attempt, so it's a bit of a delay, I'd think.
Another would be that it connects to a particular port,
right? Would I have to run an ssh command for each port I
want to forward then? I'd think there's less overhead in
making one ssh connection and running the multiple tunnels
through it.
Reply to: