If by "1 hour and 20 minutes of inactivity" you mean
- that the user hasn't typed in their shell for 1 hour and 20 minutes
- or the user used
ssh -N … 1 hour and 20 minutes ago
- in general: no data has flown for 1 hour and 20 minutes
then this is not the inactivity that matters to the ClientAlive* mechanism.
To understand the point of ClientAlive*, let's analyze what may happen to an already existing connection from the point of view of a robust sshd.
- The client may disconnect gracefully. In this case
ssh notifies sshd, the server knows for sure the connection is terminated.
- The
ssh executable may die unexpectedly for whatever reason (e.g. it gets forcefully killed), so it cannot communicate its intention to disconnect. Still the OS on the client side is able to close the TCP connection properly, so sshd recognizes the connection is no more.
- The whole client machine is killed or disappears for whatever reason (e.g. because of unplugged network cable). Now
sshd cannot tell if the client is silent because it has no data to send, or because it's no longer there.
The ClientAlive* mechanism detects the last case. The server sends client alive messages and the client responds, if the client is there. This happens automatically within the SSH protocol. Applications using SSH as their transport neither are affected nor they interfere.
ClientAliveInterval and ClientAliveCountMax settings you used configure how often the server asks and how many unresponded tries it takes before it can give up and consider the connection terminated.
The client is able to detect a dead connection in a similar way thanks to ServerAliveInterval and ServerAliveCountMax.
There is also a more general mechanism for TCP connections (not specific to SSH): TCP keepalive. Compare this answer of mine.
Keepalive packets of any kind not only allow the connection endpoints to detect if the connection became dead. They also "renew" the connection in between. I mean e.g. my home router with NAT may recognize a connection as dead if no packet belonging to it has been seen for a long time. If this happens, the NAT entry will be forgotten and when the connection eventually gets active, the router will not be able to handle it right. Compare this answer.
Letting the SSH terminal open without typing anything to it does not prevent ssh from responding to client alive messages generated by the server. If the client is there, the client will respond.
To log out a user who hasn't interacted with their shell for some timeout, you need help from the shell: TMOUT or similar variable (depending on the shell). But then the user can reconfigure their shell.
There are guides on the Internet that treat the ClientAlive* mechanism as an alternative to TMOUT. Now you know these are different things.
There may be ways to let the OS detect "inactivity" of a user (e.g. no new processes spawned, only sshd and bash running, no data flow via their pts). Even if I knew them, I wouldn't use them to terminate SSH connections that look inactive.
What if the user requested port forwarding via SSH? A connection to the forwarded port may come in at any time. The application willing to use the port may be anything, without any knowledge there is the forwarding involved. The user may want to rely on SSH silently waiting for a connection to happen. IMO terminating the SSH connection only because there is no traffic is not a good practice. As long as the client responds to client alive messages, the connection should remain.
In your case the client kept responding.
UPDATE
In 2023 OpenSSH introduced ChannelTimeout and UnusedConnectionTimeout options you can use in sshd_config. These options are what you need. See this other answer of mine for details.
ClientAliveCountMax 0` and test it out? – Rui F Ribeiro May 11 '20 at 09:57