SSH disconnect after 15 min of idling

[Rabiat1963]

Describe the bug

After one of the latest updates my SSH connection is being disconnected/logged off after 15 minutes of idling. How can I prevent this?

Reproduction steps

1. Logging in to the VM with SSH as root.
2. Not doing anything for 15 minutes.
3. SSH connection is disconnected/logged off.

Expected behavior

I should not be disconnected/logged off after 15 minutes as before.

Additional context

No response

[dcasota]

Hi,
This is a communication issue, indeed. The Photon OS team has not yet implemented an autonomous AI agent to analyze, summarize, or blog about daily changes. For now, people rely on commit logs and LLM queries for important updates.

How can I prevent this?
You could easily change the new behavior manually by modifying /etc/sshd_config. Have a look to the line ClientAliveInterval 900.

To disable the server's idle timeout feature enforced by the ClientAliveInterval and ClientAliveCountMax settings (which probe for client responsiveness and disconnect inactive sessions), follow these steps:

Install vim if necessary (tdnf install vim -y), open the SSH daemon configuration file for editing (typically requires root privileges, e.g., via sudo):

sudo vi /etc/ssh/sshd_config

Locate the lines for ClientAliveInterval and ClientAliveCountMax. Comment them out (by adding a # at the start) or explicitly set ClientAliveInterval to 0:

#ClientAliveInterval 900
ClientAliveInterval 0
#ClientAliveCountMax 1

Setting ClientAliveInterval to 0 prevents the server from sending any keepalive probes, effectively disabling the idle disconnection.
ClientAliveCountMax becomes irrelevant once the interval is 0, but you can leave or comment it as needed.

Save and exit the editor.
Restart the SSH service to apply the changes.

sudo systemctl restart sshd

---

The change in 9adb674 was made for security, updating sshd_config to meet the latest STIG. In the U.S. Department of Defense, Security Technical Implementation Guides (STIGs) set technical hardening standards.

The change included a few modifications:

• FIPS Compliance for Algorithms: Added explicit configurations for KexAlgorithms, Ciphers, and MACs to restrict them to FIPS-compliant options only, removing any non-compliant ones (e.g., limiting ciphers to AES variants like aes128-ctr).
• Enhanced Authentication Security: Tightened login parameters by setting LoginGraceTime to 30 seconds, disabling root login (PermitRootLogin no), enabling strict modes (StrictModes yes), and limiting authentication attempts (MaxAuthTries 6). Also enabled PAM authentication (UsePAM yes) and set IgnoreUserKnownHosts yes.
• Disabled Insecure Features: Turned off several potentially risky options, including agent forwarding (AllowAgentForwarding no), TCP forwarding (AllowTcpForwarding no), compression (Compression no), and TCP keepalives (TCPKeepAlive no). Adjusted session timeouts with ClientAliveInterval 900 and ClientAliveCountMax 1, and set a banner file (Banner /etc/issue).

[Rabiat1963]

How can I prevent this? You could easily change the new behavior manually by modifying /etc/sshd_config. Have a look to the line ClientAliveInterval 900.

This was however not the correct answer, but it got me searching for the right one.

The problem is not related to the 'ClientAliveInterval 900' but instead the $TMOUT environment variable. It is set to 900 seconds (15 minutes) by default. Tested with "echo $TMOUT".

And what fixed the problem for me was to edit the file: /etc/profile.d/tmout.sh

TMOUT=900
readonly TMOUT
export TMOUT
mesg n 2>/dev/null

changed to

TMOUT=0
readonly TMOUT
export TMOUT
mesg n 2>/dev/null

Logged off and back on, and now there's no logging off after 15 minutes.

[dcasota]

Awesome, very good, you're right - the latest updates also contain 7753c0f. The shadow package includes tmout.sh and you described the change impact very well. Good catch! There were much more hardening changes during the last couple of weeks.