SSH sessions close after 1 hour

Support
1

We have 3 AL8/CL8 and 1 AL9/CL9 servers running cPanel.

All 4 servers close SSH sessions after 1 hour, no matter the settings in sshd_config, logind.conf, PuTTY, .bashrc, or .bash_profile. The AL8/CL8 boxes were upgraded from Centos7/CL7 using cPanel elevate process with no issues. Prior to the upgrade, ssh sessions stayed open as long as we need them.

These are not idle sessions; disconnects happen even while actively typing. We suspect this may be related to the lack of output from w or who when logged in via ssh - only console sessions are displayed. However, we’ve found nothing definitive.

We have searched far and wide for an explanation and fix, and all we’ve been able to find are people complaining about the same thing, with no solution. It would be great if somebody had a fix.

2

After some poking around, it’s clear that lack of ssh sessions listed in the w and who output is not related.

3

I hate to say it, but the only time I’ve seen this kind of behavior is with a public server that’s been compromised at the root level. I’d recommend checking your servers for rootkits, and taking steps to remedy the situation (likely a fresh OS install and a restoration of the account backups).

4

Did all that. The AL9/CL9 box is brand new.

5

Here’s the answer that was driving me crazy.

We checked and changed all server ssh settings that everybody says will work. They didn’t, leading us to believe that it was not a server-side ssh issue.

We use PuTTY to access, and all settings for all servers have been the same since we started using it about 97 years ago. Out of about 2 dozen hosting servers we manage, the only ones with the timeout issue were AL/CL8/9.

After some more research, it turns out the issue is related to the key exchange algorithm between PuTTY and the AL/CL8/9 boxen.

PuTTY connections on AlmaLinux/CloudLinux 8 and 9 are likely being closed after exactly one hour because of an SSH key rekeying issue. This is not a problem with PuTTY settings or the standard sshd_config settings but rather an incompatibility with older or specific SSH client implementations.

Secure Shell (SSH) connections regularly renegotiate encryption keys to maintain a high level of security.

By default, the rekeying happens every 60 minutes or after a certain amount of data has been transferred. Some SSH server versions, including those on older systems or specific configurations, cannot properly handle a client’s request to rekey a connection and will simply disconnect.

The exact one-hour timeframe for the disconnection strongly points to this key renegotiation as the cause.

Why it’s specific to AlmaLinux/CloudLinux 8/9:

While the rekeying issue is a general SSH problem, experience suggests that the default OpenSSH server (sshd) versions or configurations used by AlmaLinux/CloudLinux 8 and 9 handle this process differently than the SSH servers on other operating systems. For instance, an older version of the SSH daemon might not fully support the rekeying process initiated by a more modern client, or it may have a bug that causes the connection to terminate instead of renegotiating the key.

What we did:

  1. Open PuTTY
  2. Select Connections > SSH > Kex
  3. Change ‘Max minutes before rekey (0 for no limit)’ from 60 to 0
  4. Save settings

No more timeouts while in the middle of typing.

1 Like