Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SSH timeouts



Applications like Konqueror using the fish:// protocol apparently send
'refresh' requests and stay up forever, while a Konsole on the same
local workstation will get disconnected from the reomote server.  This
apparently is because the router decides to drop you when there is no
activity between the client and the server.

Setting ClientAliveInterval would work to keep your router from dropping you.

see http://www.brandonhutchinson.com/OpenSSH_ClientAliveInterval.html

TCPKeepAlive will tell the server to drop the session if the user
(network) goes away, I'm not certain that it persists your session.


from man:sshd_config

ClientAliveCountMax
 Sets the number of client alive messages (see above) which may be
sent without sshd receiving any messages back from the client. If this
threshold is reached while client alive messages are being sent, sshd
will disconnect the client, terminating the session. It is important
to note that the use of client alive messages is very different from
TCPKeepAlive (below). The client alive messages are sent through the
encrypted channel and therefore will not be spoofable. The TCP
keepalive option enabled by TCPKeepAlive is spoofable. The client
alive mechanism is valuable when the client or server depend on
knowing when a connection has become inactive.

 The default value is 3. If ClientAliveInterval (above) is set to 15,
and ClientAliveCountMax is left at the default, unresponsive ssh
clients will be disconnected after approximately 45 seconds.
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.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org