Gregory Novak writes:
> The question, then, is "How do I do this, either with SSH or other
> software that uses SSH (since SSH is the only way through the
> firewalls in question)?"

If it's primarily X that concerns you, and if you aren't yet familiar
with VNC (Virtual Network Computing), I suspect it's going to
a) delight you
b) make you wonder how you ever lived without it.

There are a variety of VNC servers and clients out there (TightVNC,
RealVNC are the usual suspects). VNC communication is not only far
less bulky than X11's chattiness, but the reconnectability feature is
exactly the sort of thing you're looking for.

Servers and clients are available for windows and linux which is
another very handy thing. VNC to your windows desktop from your Linux
box, for instance.

VNC communicaiton can be encrypted in the SSH tunnel fairly easily.
If you happen to be a SecureCRT user under windows, and wishing to get
to remote VNC servers (be they windows or *nix) via ssh, here's how:
http://www.vandyke.com/aboutus/news/...pr03_news.html

The only thing that would rule VNC out is if you were not able/allowed
to install vnc-server on the remote end of the connection. That would
be quite a pisser.

Best Regards,
--
Todd H.
http://www.toddh.net/

"Gregory Novak" wrote in message
news:m2psotzh31.fsf@euterpe.local...
>I make extensive use of ssh port forwarding to access machines behind
> firewalls, etc. I often run programs that require presistent
> connections over these ports (such as X11 programs). Unfortunately my
> home DSL connection has become unreliable lately, going down for a few
> minutes and then coming back. This often has the effect of killing
> the programs that rely on the forwarded connections.
>
> I would much prefer it if the forwarded connections behaved more like
> plain vanilla TCP connections--if the network goes down, they should
> patiently wait a long time before finally snipping the connection.

The "screen" program is your friend, at least for terminal sessions and the
programs started from them. That will allow you to reconnect to an
interrupted session, although X programs may not work well if their X-server
connection is lost.

"Todd H." wrote in message
news:84sltp7chh.fsf@ripco.com...
> Gregory Novak writes:
>> The question, then, is "How do I do this, either with SSH or other
>> software that uses SSH (since SSH is the only way through the
>> firewalls in question)?"
>
> If it's primarily X that concerns you, and if you aren't yet familiar
> with VNC (Virtual Network Computing), I suspect it's going to
> a) delight you
> b) make you wonder how you ever lived without it.
>
> There are a variety of VNC servers and clients out there (TightVNC,
> RealVNC are the usual suspects). VNC communication is not only far
> less bulky than X11's chattiness, but the reconnectability feature is
> exactly the sort of thing you're looking for.

This is better than my suggestion of using "screen", at least for X
sessions.

VNC also runs well over HTTPS sessions with its Java client capabilities, so
you need not even install a client for it. It's a bit more of a bandwidth
pig that way, but it can ease gaining X-windows access to a machine while on
the road.

"Nico Kadel-Garcia" writes:
> "Todd H." wrote in message
> news:84sltp7chh.fsf@ripco.com...
> > Gregory Novak writes:
> >> The question, then, is "How do I do this, either with SSH or other
> >> software that uses SSH (since SSH is the only way through the
> >> firewalls in question)?"
> >
> > If it's primarily X that concerns you, and if you aren't yet familiar
> > with VNC (Virtual Network Computing), I suspect it's going to
> > a) delight you
> > b) make you wonder how you ever lived without it.
> >
> > There are a variety of VNC servers and clients out there (TightVNC,
> > RealVNC are the usual suspects). VNC communication is not only far
> > less bulky than X11's chattiness, but the reconnectability feature is
> > exactly the sort of thing you're looking for.
>
> This is better than my suggestion of using "screen", at least for X
> sessions.

Gnu screen absolutely rocks. That reconnectability for terminal
sessions is SO nice. How would that go on the SAT test?
screen:terminal :: vnc:GUI ?

Hee hee.

> VNC also runs well over HTTPS sessions with its Java client
> capabilities, so you need not even install a client for it. It's a
> bit more of a bandwidth pig that way, but it can ease gaining
> X-windows access to a machine while on the road.

Good info to know!

--
Todd H.
http://www.toddh.net/

In article Gregory Novak
writes:
>I make extensive use of ssh port forwarding to access machines behind
>firewalls, etc. I often run programs that require presistent
>connections over these ports (such as X11 programs). Unfortunately my
>home DSL connection has become unreliable lately, going down for a few
>minutes and then coming back. This often has the effect of killing
>the programs that rely on the forwarded connections.
>
>I would much prefer it if the forwarded connections behaved more like
>plain vanilla TCP connections--if the network goes down, they should
>patiently wait a long time before finally snipping the connection.
>
>Ideally, this would even include starting a new ssh process to handle
>the port forwarding. My understanding of ssh port forwarding is that
>ssh simply catches the TCP packets at one end, shoots them over the
>secure connection, and allows them to pop out at the other end.

Well, unfortunately your understanding is flawed - there are actually
two separate TCP connections when you do port forwarding, one from the
local program to ssh, and one from sshd to the remote program (in the
other direction for reverse or X11 forwarding of course). No way could
you replace the ssh/sshd in the middle without the local and remote
programs cooperating by establishing new connections, and no way can
this be "fixed" in ssh - you basically need "true" VPN capability for
that (which is possible but quite awkward to do on top of ssh port
forwarding).

There's no obvious reason the ssh<->sshd connection (including the
"embedded" port forwarding connections) couldn't survive "outage" like
"plain vanilla TCP connections" though, since that's exactly what it
is. There is various "keepalive" (or "killdead") functionality that may
cause problems wih this though - it's not there to cause problems, but
primarily to detect the case where the ssh client has "gone away"
permanently without closing the connection properly, since otherwise the
sshd and assocated programs on the server end could be left running
indefinitely. Search the ssh_config and sshd_config man pages for
"Alive" to learn more about this.

And of course any "keepalive" or similar periodic traffic from the
programs using the port forwarding will have a similar effect - a TCP
connection with pending data to send will not survive very long in most
current OSes in my experience.

--Per Hedeland
per@hedeland.org

per@hedeland.org (Per Hedeland) writes:
> Well, unfortunately your understanding is flawed - there are actually
> two separate TCP connections when you do port forwarding, one from the
> local program to ssh, and one from sshd to the remote program (in the
> other direction for reverse or X11 forwarding of course). No way could
> you replace the ssh/sshd in the middle without the local and remote
> programs cooperating by establishing new connections, and no way can
> this be "fixed" in ssh - you basically need "true" VPN capability for
> that (which is possible but quite awkward to do on top of ssh port
> forwarding).

I see. That's too bad.

Regarding VPN, I've made several attempts to get it running, all of
which petered out because of the complexity of setting it up combined
with the lack of a clear (in my mind) benefit of doing so. Would VPN
solve this problem for me? That would be enough incentive for me to
get it running...

> There's no obvious reason the ssh<->sshd connection (including the
> "embedded" port forwarding connections) couldn't survive "outage" like
> "plain vanilla TCP connections" though, since that's exactly what it
> is.

Regarding Keepalive packets, I have them turned on for ssh connections
(for unrelated reasons). You think I would have better luck with this
by turning them off? This seems like a fragile situation: I have to
notice when the network goes out and then scrupulously avoid doing
anything that sends any traffic over the connection until the network
comes back. Am I correct in thinking this?

Thank you!
Greg

comphelp@toddh.net (Todd H.) writes:

>Gnu screen absolutely rocks.

Funny you'd mention "rocks". I'd say it's quite appropriate here.
http://www.cs.wisc.edu/~zandy/rocks/
I've also dabbled with autossh.
http://www.harding.motd.ca/autossh/
Either should help SSH tame unreliable connections.

I still usually think in terms of using SSH for everything but these
days I find OpenVPN solving many of my problems more robustly.
http://openvpn.net/

--kyler

In article Gregory Novak
writes:
>per@hedeland.org (Per Hedeland) writes:
>> Well, unfortunately your understanding is flawed - there are actually
>> two separate TCP connections when you do port forwarding, one from the
>> local program to ssh, and one from sshd to the remote program (in the
>> other direction for reverse or X11 forwarding of course). No way could
>> you replace the ssh/sshd in the middle without the local and remote
>> programs cooperating by establishing new connections, and no way can
>> this be "fixed" in ssh - you basically need "true" VPN capability for
>> that (which is possible but quite awkward to do on top of ssh port
>> forwarding).
>
>I see. That's too bad.
>
>Regarding VPN, I've made several attempts to get it running, all of
>which petered out because of the complexity of setting it up combined
>with the lack of a clear (in my mind) benefit of doing so. Would VPN
>solve this problem for me? That would be enough incentive for me to
>get it running...

I'm not sure that it would solve anything - I was just saying that this
is the type of mechanism you need for it to be possible for the
connectivity to totally go away and be re-established without
applications noticing.

There are certainly additional requirements that must be fulfilled,
e.g. that the VPN connection itself can be re-established more or less
"automatically", and that you have the same "inner" IP address (i.e. the
one associated with the VPN rather than the "physical" one) after the
reconnect - and of course it is still required that the applications
running on top of the VPN can tolerate the outage.

>Regarding Keepalive packets, I have them turned on for ssh connections
>(for unrelated reasons). You think I would have better luck with this
>by turning them off?

Probably.

> This seems like a fragile situation: I have to
>notice when the network goes out and then scrupulously avoid doing
>anything that sends any traffic over the connection until the network
>comes back. Am I correct in thinking this?

More or less - the timeouts for pending TCP data vary by OS and can
often also be configured (e.g. 'tcp_retries2' proc/sysctl node on
Linux). And of course applications can have their own timeouts
independent of this (most probably don't, though).

--Per Hedeland
per@hedeland.org