Open patrakov opened 11 months ago
Also looking to understand the intent of these values, specifically ClientAliveCountMax 0
and ClientAliveInterval 300
.
Based on the sshd_config docs:
Setting a zero
ClientAliveCountMax
disables connection termination.
Which makes me think the ClientAliveCountMax 0
nullifies any value set for ClientAliveInterval
.
I realize these values are just examples, but agree with @patrakov that the implication is that there is some security impact by leaving them at the defaults and would love to see some justification or additional reading.
Edit: On rereading the docs, I understood it differently. If ClientAliveCountMax
is 0, the server won't terminate the connection, but it will continue to poll to keep the connection alive. Still unsure of the security benefit of not terminating or of having such a large polling interval
According to the manpages, TCPKeepAlive
is a potential security risk, as it is spoofable.
Plus, there does not seem to be any reason to use both TCPKeepAlive
and ClientAlive*
values,
as they perform the same goal: to clean up lost connections.
ClientAlive*
values, however, are a preference between cleaning up unused resources (closing dropped connections) and possibly getting disconnected by a temporary connection loss.
Specifies whether the system should send TCP keepalive messages to the other side. This allows connection loss to be noticed. Beware that temporary loss of connection will cause the connection to be closed. We will disable this, as we will use the ClientAlive options. TCPKeepAlive is spoofable, whilst ClientAlive is not.
Sets the number of client alive messages which may be sent without sshd receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. Set this to 0 to disable connection termination. We will set this to the default 3.
Sets a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. We will set this to 15 seconds. This means an unresponsive SSH client will be disconnected after 3 messages, 15 seconds apart from each other (45 seconds, approx).
The example SSH configuration has several options that (at least from my point of view) are not related to security and that do not have any written justification:
TCPKeepAlive no
(probably copied from http://web.archive.org/web/20200413100933/https://www.techbrown.com/harden-ssh-secure-linux-vps-server/ which does not provide a justification either)ClientAliveCountMax 0
Also, the suggested value of
ClientAliveInterval 300
is too high to ensure reliable connections from modern LTE ISPs (e.g., your friend's ISP) that have a ridiculously low NAT timeout, as low as 25 seconds.