set OpenSSH timeout for inactive connections

My SSH sessions keep getting disconnected after ~20 minutes of inactivity. My server runs Debian and OpenSSH, and so far I haven't changed any settings or initialization scripts related to ssh. How can I set disallow timeouts due to insufficient use of the connection?

Thanks.
BerkeleyJeffAsked:
Who is Participating?
 
ravenplConnect With a Mentor Commented:
on server side
/etc/ssh/sshd_config

     ClientAliveInterval
             Sets a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through
             the encrypted channel to request a response from the client.  The default is 0, indicating that these messages will not be sent
             to the client.  This option applies to protocol version 2 only.

on client side
/etc/ssh/ssh_config or ~/.ssh/config
     ServerAliveInterval
             Sets a timeout interval in seconds after which if no data has been received from the server, ssh will send a message through
             the encrypted channel to request a response from the server.  The default is 0, indicating that these messages will not be sent
             to the server.  This option applies to protocol version 2 only.
0
 
ahoffmannCommented:
in ~/.ssh/config
  KeepAlive no

in /etc/ssh/sshd_config
  KeepAlive no
0
 
BerkeleyJeffAuthor Commented:
My sshd_config file doesn't have 'ClientAliveInterval' in it. It does have 'KeepAlive' set to 'Yes', but could that be my problem? The server isn't supposed to disconnect upon the keepAlive, as long as the client is still connected, right? I thought KeepAlive was more to detect dropped connections.
0
Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.

 
ahoffmannCommented:
> It does have 'KeepAlive' set to 'Yes', but could that be my problem?
yes
0
 
ravenplCommented:
> How can I set disallow timeouts due to insufficient use of the connection?
I understand, that the connection is broken, and the author want it alive. Right?
0
 
BerkeleyJeffAuthor Commented:
So I switched KeepAlive from 'Yes' to 'No', but I still get disconnected frequently. Here's a typical error message:

> Read from remote host metaglossary.com: Connection reset by peer
Connection to metaglossary.com closed.


Are there some other settings that might be responsible?
0
 
ravenplCommented:
Yes - I proposed some in my first comment.
0
 
kblack05Commented:
You might also be seing a firewall or socket timeout, which will typically ignore keepalive settings.

you can check one of the /proc settings for tcp timeouts with a command like this:

less /proc/sys/net/ipv4/tcp_keepalive_time

it will probably be around 7200 (i.e. 2 hours)
if you like, you can reset the timeout by echoing to /proc/sys/net/ipv4/tcp_keepalive_time

example:
echo -n  43200 > less /proc/sys/net/ipv4/tcp_keepalive_time
0
 
ahoffmannCommented:
firewall or kernel problem, as already said
0
 
ravenplCommented:
Yep, and ClientAliveInterval/ServerAliveInterval should fix it up.
Alternative: run following script while leaving session alone
while true; do echo -n "."; sleep 60; done
0
 
ahoffmannCommented:
.. or
  ping -i 42 localhost
0
 
ravenplCommented:
I guess my comments was on the right track, and are ssh based only.
messing with ernel timeouts would do, if they are done on the firewall - not peer system.
0
 
ahoffmannCommented:
hmm, we could dispute the henn-egg problem which means KeepAlive and ClientAliveInterval/ServerAliveInterval here.
But the problem turns out to be network and not ssh related.
I'd vote for a 3-way split then.
0
 
ravenplCommented:
ahoffmann: how did You get the impression that it's network/firewall problem?
Let me explain:
firewalls may ignore TCP KeepAlive packets, but surealy can't ignore ClientAliveInterval/ServerAliveInterval packets (as it's data based).
any router/firewall on the way may do connection tracking, and therefore messing with TCP stack values on the peer systems will not help.
Also /proc/sys/net/ipv4/tcp_keepalive_time means how often the kernal should send KeepAlive if enabled. Enlarging it shurely will not help!
0
 
ahoffmannCommented:
>  ahoffmann: how did You get the impression that it's network/firewall problem?
see http:#17168698

> firewalls may ..
agreed

> any router/firewall on the way may do ..
agreed and confirms my network assumtion
0
 
ravenplCommented:
The point is that ClientAliveInterval/ServerAliveInterval should help - it uses data channel, thus firewall can't cut it out...
0
 
ahoffmannCommented:
> .. thus firewall can't cut it out...
true, the firewall can't cut out the application data, but if the firewall's timeout is less than that configured for ssh it drops the connection before the heart beat is sent.
0
 
VenabiliCommented:
So what we do with the question?
0
 
ahoffmannCommented:
I'd still vote for a 3-way split. ravenpl, do you agree?
0
 
ravenplCommented:
Whatever - I already said what I'm thinking.
0
 
BerkeleyJeffAuthor Commented:
Indeed, the value in  /proc/sys/net/ipv4/tcp_keepalive_time is 7200 (i.e. 2 hours). However, the timeout tends to occur after more like 5 minutes.

Secondly, I have ruled in hardware problems, since I have the same problem with two servers, from any clients. All servers and clients run a minimal distribution of debian linux.

Leaving "top" running (or while true; do echo -n "."; sleep 60; done), keeps the connection from closing. I will try modifying ClientAliveInterval/ServerAliveInterval.

Thanks for help.
0
 
BerkeleyJeffAuthor Commented:
I think that when I originally posted this, I was also having network problems. No longer. Now changing these alive intervals seems to solve the problem. Thanks, all.
0
 
ahoffmannCommented:
the author's descission is most likely the best ;-)
Thanks for comming back BerkeleyJeff.
0
 
VenabiliCommented:
Thanks for closing ;)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.