Knowledge Base

Ssh Session is Disconnected After Idle Out Time for SCO Unix OpenServer or Unixware

Problem: ssh session is getting disconnected after idle out time.

Cause: Most firewalls will drop idle connections after a period of time which can interfere with ssh daemon default TCPKeepAlive mechanism.

Solution: Replace the sshd TCPKeepAlive with the ClientAlive probing mechanism.

  1. Edit /etc/ssh/sshd_config
  2. Find or add comments about the TCPKeepAlive option and set it to ‘no’. Some modern configuration files might already have the ClientAlive* options commented out:

    # Firewall workaround
    TCPKeepAlive yes
    # fail after 6 tries (30 minutes)
    # ClientAliveInterval 300
    # ClientAliveCountMax 6

    Change these settings to (If these options are not in the sshd_config file, add them to the end of the /etc/ssh/sshd_config file.):

    #Firewall workaround
    # turn TCPKeepAlive off and check the client every 5 minutes
    # TCPKeepAlive no
    # fail after 6 tries (30 minutes)
    ClientAliveInterval 300
    ClientAliveCountMax 6
  3. Restart sshd
    Find the parent /etc/sshd process and send it a SIGHUP (-1):

    ps -ef | grep sshd | grep -v grep | grep -v — ” -R” | grep -v “sshd:”
    kill -1 <PID_of_sshd>

    Alternatively, the changes will take effect during the next reboot.

If you still experience idle time disconnects, you might try reducing the ClientAliveInterval value to 2 minutes (120).

If you need to allow for more idle time than 30 minutes, the ClientAliveCountMax should be increased instead of the ClientAliveInterval. Increasing the ClientAliveInterval too much will not prevent the firewall from dropping idle connections.

The changes above will extend the idle timeout for all ssh logins. If you would prefer to only extend the idle timeout for specific clients, you can adjust values in the client’s ssh_config file, or ~/.ssh/config and set similar ServerAlive* parameters, for example:
ServerAliveInterval 60
ServerAliveCountMax 6

This will enable server probing from the client and also keep the idle connection active even when the firewall blocks TCPKeepAlive probing.

TCPKeepAlive mechanisms can be spoofed since they use the normal TCP channel and therefor are not encrypted, however, ClientAlive* & ServerAlive* mechanisms use the ssh channel and are encrypted and will not be blocked by the firewall since it can not be distinguished from normal ssh traffic.

telnetd still relies on the older TCPKeepAlive mechanism and does not have a workaround to this situation. It is recommended that telnet connections be replaced by more secure ssh connections if possible.

1402 reads
How did you like this article?0000