[BUGS] SSH timeout

[Andrew Reilly]

On Mon, 31 Dec 2007 23:26:47 +1100
Jerahmy Pocott <quakenet1 at optusnet.com.au> wrote:

> Hello all, and a happy new year!
> 
> On this remote 4.2 stable box I'm having an issue with SSH timing out  
> or something.. It seems to be when I'm running a long command where I  
> don't provide any input for a few hours, like buildworld or a large  
> tar, cp, etc. I come back to find the message:
> 
> Read from remote host x.x.x.x: Connection reset by peer
> Connection to x.x.x.x closed.
> 
> Looking at the various configuration files there doesn't seem to be  
> any timeout set, I was wondering if maybe some default is compiled in?  
> Of course it could be a gateway closing the connection I guess.. But  
> I'v never had this problem on older boxes.. Maybe I'm not looking in  
> the right spot?

It hides, in the ssh_config man page, sort-of.  Try setting -o
ServerAliveInterval to 30 or so (which means that ssh will send a
message to the sshd server every 30 seconds, to see if it's
alive (if nothing else has happened in the mean time)).  The
default is 0, which means that this doesn't happen.  These
messages are inside the encrypted channel, so firewalls and
what-not should not be in a position to discard them, and so
should keep the channel open.

> My current work around has been to run any long processes in the  
> background and pipe their output to a file, but this doesn't always  
> capture all the messages, especially with things like buildworld..

Others have mentioned redirection of stderr as well, which should
get everything.  Two other options you might want to try are
explicitly for this purpose: nohup+script and screen.  Script
should be in the base system, screen will be in ports.  They're a
bit different, in that script will also record stdin (if any) in
the typescript file, whereas screen maintains a "virtual
terminal", server side.  It doesn't log anything, but it'll stick
around if your session disconnects, and you can re-connect to it
later.  The important part is that the job that you run from
inside it doesn't get the HUP signal, and so doesn't stop.

Hope this helps.

Cheers and happy new year to you (all) too!

-- 
Andrew