This is not an SSH problem. This is the standard builtin behaviour of
TCP. The TCP connection is timing out, not the SSH session. You are not
going to be able to get around this, the way you want. Your "sshd" process=
es
are dying because their TCP connection is getting a timeout error and is fo=
rced
to close.

If you are not doing any port forwarding, (ie. just using shell access) the=
n
I would suggest using "screen".
http://www.gnu.org/software/screen/

"screen" will be able to background the active shells upon disconnection.
You can then, reconnect to the backgrounded screen session, upon relogin.

If you are using X forwarding, you will not be able to do this anymore.
A work around for X applications, would be to run something like TightVNC.
http://tightvnc.org/

You can then login via ssh and start a "vncserver" and port forward the cli=
ent
from your B box. Upon client disconnection, the vncserver will still be ru=
nning
and maintaining an X framebuffer for the X applications. You would then
upon re-sshing into A, tunnel a new vncclient connection to the vncserver a=
nd
it will repaint the framebuffer on your screen. Then you are back in busin=
ess.

On 6/17/05, JCA <1.41421@gmail.com> wrote:
> I inquired about this in comp.security.ssh, with limited success;
> hopefully somebody in this mailing list can provide further feedback.
>=20
> 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.
>=20
> 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 www.suspend2.net. 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:
>=20
> Read from remote host xxx.xxx.xxx: Connection reset by peer
> Connection to xxx.xxx.xxx closed.
>=20
> And the xterm window disappears (it had been created as xterm -e ssh
> xxx.xxx.xxx, so it just exits when the ssh connection terminates.)
>=20
> In an attempt the get around this, I added the following lines to
> the global sshd_config file on
> A:
>=20
> KeepAlive no
> ClientAliveInterval 30
> ClientAliveCountMax 1540
>=20
> 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.
>=20
> 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.
>=20
> 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?
>=20



--=20
END OF LINE
-MCP