HP-UX TCP/IP (SSH) sessions cut after ~30minutes of inactivity

[Adam Garsha]

Where is this controlled?

idle sessions are dropped after about 30minutes.

[Andy Torres · Accepted solution]

See if this thread helps:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=966920

[Mel Burslan]

If I were you, I would start questioning the firewall admins if there is one between your server and the clients connecting to this server.

if your clients are connecting from a windows PC using putty, here is the info from the putty faq:

The timeout value can't be set on per application or per session
basis. To increase the TCP timeout globally, you need to add the
following key to the registry
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\MaxDataRetries
in Win95/98/ME (it must be DWORD in Win95, or String in Win98/ME),

Then set the key's value to something like 10. This will cause
Windows to try harder to keep connections alive instead of
abandoning them.

Hope this helps

[Adam Garsha]

Thanks, but no TMOUT set and using openssh from Konsole on Linux.

Sessions to Tru64 hosts on the same subnet don't timeout.

No firewall between me and the hosts.

[Mel Burslan]

can you post the output of these two commands:

grep -v ^# /opt/ssh/etc/ssh_config
grep -v ^# /opt/ssh/etc/sshd_config

[Adam Garsha]

/opt/ssh/etc/ssh_config:

Protocol 2

/opt/ssh/etc/sshd_config:

Protocol 2
PermitRootLogin no
StrictModes no
PubkeyAuthentication yes
KerberosAuthentication yes
X11Forwarding yes
X11UseLocalhost no
Subsystem sftp /opt/ssh/libexec/sftp-server

[Adam Garsha]

Is there a "default" TMOUT value that takes effect when "TMOUT=0" or when no TMOUT value is defined in /etc/profile or elsewhere?

[Ranjith_5]

Hi Adam,

Set the TMOUT value for the system. You can either add it in /etc/profile OR $HOME/.profile. If you add this in /etc/profile the time out value will be same for all users where as in $HOME/.profile , you can set different values for different users. The line to be added is,

export TMOUT=300

This will allow a 300 sec ( 5 mins) in activity and then the session will be disconnected.

Regards,
Syam

[Mel Burslan]

if

echo $TMOUT

yields 0, it means that you do not have a timeout set and your session will not timeout due to OS imposition.

On the other hand I did not see anything special in your config files to force an ssh timeout neither.

can you connect to this system via telnet and see if that one as well times out in about the same lenght of inactivity.

I still suspect that you have a firewall between your clients and the server or another piece of software on the server that I can not know, killing the idle connections.

what ssh client are you using to connect ?

[Adam Garsha]

No telnet enabled.

debug1: Remote protocol version 2.0, remote software version OpenSSH_3.6.1p2

debug1: Local version string SSH-2.0-OpenSSH_3.9p1

I'll peck network guys again and try a few more experiments.

[Mel Burslan]

unless the firewall is blocking telnet packets by stateful inspection, you can enable (I hope you are the sysadmin of this server) telnet temporarily to test.

[Adam Garsha]

I am going to try a couple of other things first when I have a free minute. e.g. connecting outward and connecting from a different host, etc.

I can tell it is something server-side or network based because an idle ssh session:

Read from remote host XXX: Connection reset by peer
Connection to XXXX closed.
debug1: Transferred: stdin 0, stdout 0, stderr 86 bytes in 3610.8 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1

[Mel Burslan]

unless somebody is kiling the terminal session from the ssh client side, this definitely is coming from the man in the middle, i.e. the firewall or router. 30 minutes is generally the default global timeout for cisco pix firewalls if my memory is still serving me good.

[rick jones]

Connection reset by peer - that means that whatever is closing the connection is doing so with an abortive (ie bad) flavor of close. It should be using a graceful close (FIN's instead of RSTs) if it is going to be closing a connection. That sounds a bit like either Windows, or an evil, end-to-end breaking gizmo such as a firewall :)

If you know the sshd id of the sessions, you could also try taking a tusc trace of that pid on the UX server and see what system calls it makes after 30 minutes. Ditto for the user's shell. Connect, find the apropriate PIDs and fire-up some tusc commands while the connection sits idle. Then twiddle thumbs and wait.