Port Forwarding over Unreliable Connections - SSH

This is a discussion on Port Forwarding over Unreliable Connections - SSH ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Port Forwarding over Unreliable Connections

  1. Port Forwarding over Unreliable Connections

    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.
    Therefore it doesn't seem like it would be impossible to, for example,

    1) start an xterm on a remote machine, forwarding the X11 connection
    over the SSH connection so that its window pops up on the local
    machine.
    2) Kill the SSH process.
    3) Start a new SSH process, forwarding the same ports that were
    forwarded by the first SSH process
    4) Happily use the Xterm as though nothing happened.

    In my experience, the Xterm always dies in this situation. It's very
    possible that my understanding is flawed and that things are not so
    simple, but at the moment I don't see the problem with the above.

    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)?"

    Thank you,
    Greg

  2. Re: Port Forwarding over Unreliable Connections

    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/

  3. Re: Port Forwarding over Unreliable Connections


    "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.



  4. Re: Port Forwarding over Unreliable Connections


    "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.



  5. Re: Port Forwarding over Unreliable Connections

    "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/

  6. Re: Port Forwarding over Unreliable Connections

    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

  7. Re: Port Forwarding over Unreliable Connections

    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

  8. Re: Port Forwarding over Unreliable Connections

    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

  9. Re: Port Forwarding over Unreliable Connections

    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

+ Reply to Thread