A la hora de establecer los Timeouts por inactividad en el servidor SSH hay que tener en cuenta que no es lo mismo configurarlo por tiempo de inactividad en la sesión que por un problema con el cliente que está conectado y en algún momento ha dejado la sesión colgada, es decir, la sesión ssh está activa pero el cliente no responde.
Timeout por inactividad
En el primer caso, el timeout por inactividad establece que en el momento que el cliente conectado por SSH está inactivo por el tiempo especificado en el parámetro «ClientAliveInterval» será desconectado del servidor SSH. Lo configuramos en el fichero de configuración /etc/ssh/sshd_config:
/etc/ssh/sshd_config
ClientAliveInterval 500
En el ejemplo anterior configuramos que tras 500 segundos de inactividad la sesión ssh finalice:
$ $ Connection to server closed by remote host. Connection to server closed.
Timeout por cliente ssh que no responde
En cambio, si lo que queremos es que la sesión SSH se libere cuando el cliente deja de responder (no por inactividad, sino por un fallo de conexión), también jugamos con el parámetro «ClientAliveInterval» pero añadiendo otro más: ClientAliveCountMax. Ejemplo:
/etc/ssh/sshd_config
ClientAliveInterval 500 ClientAliveCountMax 3
En el ejemplo anterior, se enviará cada 500 segundos un mensaje al cliente para «ver si está vivo«. Si tras 3 envíos de este mensaje el cliente sigue sin responder, se forzará el cierre de su sesión. En ese caso, tras 1500 segundos sin que el cliente responda se cerraría la sesión. La diferencia es que si lo que queremos es que el Timeout sea por inactividad, ese parámetro lo ponemos a 0 para que no sea determinante si el cliente contesta o no al mensaje, pues el cliente siempre contestará (es automático) si la sesión no está colgada y no tendremos nunca un timeout por inactividad.
En resumen:
Timeout por inactividad:
ClientAliveInterval 500 ClientAliveCountMax 0
Timeout por fallo de conexión:
ClientAliveInterval 500 ClientAliveCountMax 3
Otro detalle interesante de configuracion de Timeouts es el parámetro «TCPKeepAlive». Seguro que alguna vez os habéis fijado en que pese a perder conexión durante unos segundos, cuando esta vuelve seguimos conectados a las sesiones SSH que teníamos previamente:
KeepAlive yes
Esto es debido a que con TCPKeepAlive activo se envían mensajes de Keepalive TCP para que en caso de pequeños cortes (o según definamos los intervalos de envío de mensajes) la conexión no se pierda. Esto permite que ante fallos de nuestra conexión a Internet podamos mantener las sesiones durante un tiempo específico, pero también provoca que en caso de fallo permanente las sesiones se puedan quedar colgadas tal y como especificamos en el punto 2.