Keeping OpenSSH connections alive

From: JCA (
Date: 06/17/05

  • Next message: G Lehnert: "64bit-compiled sshd fails on IBM/AIX"
    Date: Fri, 17 Jun 2005 08:28:23 -0700

      I inquired about this in, with limited success;
    hopefully somebody in this mailing list can provide further feedback.

      I have two Linux boxes, A and B, running OpenSSH versions 3.6.1p2
    and 3.9p1, respectively. I connect from B to A by means of ssh. That
    is, on B I am running X windows, and I open xterms that create a shell
    on A by means of the ssh command.

      The thing is, I have to bring B down on a regular basis. "Bring
    down" means suspend my running session to disk, by means of the
    suspend software available in When I wake B up,
    after being suspended for a few hours, I retrieve my setup all right,
    including the xterms where I have my ssh connections to A. However, as
    soon as I press any key when the pointer is in any such windows, the
    following message is printed out:

        Read from remote host Connection reset by peer
       Connection to closed.

    And the xterm window disappears (it had been created as xterm -e ssh, so it just exits when the ssh connection terminates.)

       In an attempt the get around this, I added the following lines to
    the global sshd_config file on

       KeepAlive no
       ClientAliveInterval 30
       ClientAliveCountMax 1540

    My intention here was to make sure that the OpenSSH daemon on A would
    mantain connections open for up to 12 hours, regardless of what the
    clients are doing. As it happens, after such changes (and after
    restarting the OpenSSH daemon on A) I noticed that the sshd daemons
    forked in A for each ssh connection from B stay alive for just a few
    minutes (between 2 and 30; I hope I'll be able to measure this more
    accurately soon) after B gets suspended to disk.

       Somebody suggested to use autossh on B. With this, when B is
    brought back from hibernation, pressing a key on any of the ssh xterms
    on B elicits the same message as above, but a new ssh connection is
    automatically opened instantly. This is fine, but if I had something
    like, say, a debugging session running within the original ssh
    connection, that debugging session gets lost.

       The bottom line is, is there a way to coax A to keep its OpenSSH
    forked processes alive for a prespecified time, no matter what their
    matching ssh clients in B are doing? Why is it the case that the three
    lines I added to the sshd_config file do not pull it off? Something to
    do with the TCP stack overriding them perhaps?

  • Next message: G Lehnert: "64bit-compiled sshd fails on IBM/AIX"

    Relevant Pages

    • RE: Kind of off topic.
      ... If you "need" remote desktop access, perhaps WebEx would help - or as others pointed out an RDP client for *nix should work as well. ... To some I would be able to connect using ssh, ... >> OS's from FreeBSD? ... >The fastest and simplest method is still a plain good old SSH connection ...
    • Re: reconnect expect to a rebooting remote
      ... If the appliance goes away the hard way and your ssh connection ... Either way you will get eof only when the network stack on the ... sshd is not running you will get connection refused. ...
    • RE: Kind of off topic.
      ... To some I would be able to connect using ssh, ... OS's from FreeBSD? ... If the remote hosts are running FreeBSD, ... The fastest and simplest method is still a plain good old SSH connection ...
    • Re: ssh - connection refused
      ... not the ssh connection is thru the local network only or thru the ... Then, the pb could come from my router, and its configuration. ... (the IP of my homeserver on the local lan) ...
    • Re: [overworked] How to get the local a Remote-X-Display?
      ... You may need ssh -Y to enable applications to run in xterms. ... the display is broken) on my Laptop, ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx ...