SSH timeout - Linux/Unix

I've noticed that various sites that I SSH into have an odd "timeout" behaviour.  Where is this timeout option located?

To me, this is odd: I've logged into the same site, as the same user...on different windows machines.  One machine never kills my connection, while the other machine's connection get disconnected after a number of inactive minutes.  I haven't really timed it yet to determine the number of minutes.

It almost seems that the machine is being assigned a timeout value based on the IP.  I set up IP restriction with TCP_wrappers.  But I didn't knowingly assign any IP timeout value with any IP's.  I don't even know if it's an option.

The SSH client that I use has an option to send a string, or a NO-OP, to avoid timeout: which neither is set on either SSH client install.

So, I was wondering if anyone else has notices such behaviour, and could help in solving the timout problem.

Thanks
rambleAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

5733133Commented:
there are several possibilities:

1. ipchains/iptables firewalls can be configured to timeout ssh (and other) sessions.
is there a possibility of any client server or in-between devices having timeouts set up in their filtering rules?

2. /etc/ssh/sshd_config has a KeepAlive feature that is often commented out by default, that can be set to "yes"

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

4. there is also a program called "idled" that can be configured to terminate idle connections

5. there are probably other programs that do similar things, so please drop a note if none of these helps you arrive at a solution

==================================================
I would check out each of these, as just doing one of them won't necessarily help, if any of the others are contributing to the problem you are experiencing.
5733133Commented:
sorry about the obvious typo from a careless cut-and-paste (omit "less"), the example under #3 should read:

echo -n  43200 > /proc/sys/net/ipv4/tcp_keepalive_time
fishtankCommented:
sshd_config also has a parameter setting: IdleTimeout

If IdleTimeout is 0 then the users never get time out problem. You can set it to 1d (1 day), 5m (5 minutes) to control the idel timeout.

Your problem is not causing by this because you login as same user on differnt machines but got the different result.  I don't what SSH client you're using but there should has a connection parameter setting for keep session active. This feature is to sending of null packets to SSH server to keep session active in certain time to let the IdelTimeout think the session active within the IdelTimeout time. I guess one of the machine setting is 0 (never send null packet) and the other may be in every 300 seconds.  Please check.
Need More Insight Into What’s Killing Your Network

Flow data analysis from SolarWinds NetFlow Traffic Analyzer (NTA), along with Network Performance Monitor (NPM), can give you deeper visibility into your network’s traffic.

rambleAuthor Commented:
5733133

Could you send me a link to that "idled" program?  Although it's not related to this question, it's a program that I was actually going to implement myself...so, why re-invent the wheel?  :^)

Also: tcp_keepalive_time isn't on the server.  It's a Solaris 8 Box...perhaps it's not implemented the same way..?

Fishtank

IdleTimeout isn't located in the sshd_config.  Perhaps this I could add it.  However, it looks like it may not be supported based on this article: http://lists.debian.org/debian-user/2003/debian-user-200301/msg02645.html
/etc/ssh/sshd_config: line 79: Bad configuration option: IdleTimeOut

I'll have to wait for a good time to do this change, as ssh would have to be brought down.

Also, about the "send null" packet.  I mentioned in my original posting that my SSH client has that option.
5733133Commented:
ramble -

here's the link for idled:

http://www.darkwing.com/idled/

it's been a while since i have worked with Solaris, so i don't know that i could necessarily help you out there...
i'll have to check around and see if i can find anything

-
5
5733133Commented:
is there a timeout parameter in a file called /etc/default/login that you can change?
rambleAuthor Commented:
Yes

# TIMEOUT sets the number of seconds (between 0 and 900) to wait before
# abandoning a login session.
#
#TIMEOUT=300

It's currently commented out
5733133Commented:
1. In the event that is related to your problem, i believe when it is commented out it is still equal to the default (i.e. 300) you would have to explicitly set it to 0
TIMEOUT=0

Although it says it is for abandoning login sessions, i have read posts that seem to indicate it might be relevant for timing out tcp sessions, it's doubtful in my book, but i thought i would mention it anyway...

2. is there a firewall between you and the Solaris box to which you are connecting from one of the locations that times out? are you connecting using a cable modem from any of the locations that times out? in which case the problem would be between the client and server rather than *on* either of them...

3. Do you have a TMOUT variable set in your shell ?
(i.e. "echo $TMOUT" to verify) if that is set to 7200, then that could be the problem
alrternate ways of doing the same thing:
env | grep OUT
or
set | grep OUT

4. the equivalent to the Linux "tcp_keepalive_time" file might be "tcpkeep_interval" on Solaris
  you might have to run something like: find / -name "tcpkeep_interval" -print
in order to find out where it is hiding in your filesystem

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
rambleAuthor Commented:

I have  a little side note for you, 5733133,

Idled seems to have complied successfully on my machine, and when I execute it...it doesn't display any errors.  But I don't see it in the ps -ef list.  Does it start a different process?  Or is it *really* not running on my system.

Anyway, it's not related to the question...but I thought I'd poll you for you experience with it.

Thanks

5733133Commented:
You could try either of the following to see if they produce any help for you in tracking down the process:

lsof -i
or
lsof -i | grep idled


I only knew about idled because i had to troubleshoot some issues some users were having with it on a Debian server a couple years ago, so i might not be your best resource, but i'll try to help if i can.

-
5
rambleAuthor Commented:
Thanks_ramble

Just Ignore the last comment
brycenCommented:
OpenSSH (which is probably what you're running) has two options of interest:

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.

 ClientAliveCountMax
             Sets the number of client alive messages (see above) which may be
             sent without sshd receiving any messages back from the client.

(This is based on OpenSSH_3.1p1).  The above options are placed in /etc/ssh/sshd_conf, next to the KeepAlive option previousy mentioned.  The sshd manual describes the difference between KeepAlive, and ClientAlive.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Security

From novice to tech pro — start learning today.