OpenSSH-server: Are there any security implications and/or value of/for 'TCPKeepAlive yes'

Question

I have read a degree of mixed reports on the security implications and/or value of allowing TCPKeepAlive yes in /etc/ssh/sshd_config (for OpenSSH-server). Anything definitive on the security best practices regarding TCPKeepAlive and/or ClientAliveInterval, etc would be warmly welcomed.

---

From what I gather there appears to be no real and/or immediate risk of having TCPKeepAlive yes (source) beyond the possibility that someone could spoof a TCP packet to stop an SSH session from timing out. I.e.

You will note in the next section that a spoofing issue exists with keep alive

(source - under the heading "SSH Users")

I read this as meaning that the risk of it actually having any serious security impact on the SSH session itself is nil.

However, a GitHub user notes:

You're quite right. It seems that there's no actual exploitable vulnerability with TCPKeepAlive -- yet

Implying that it's only a matter of time before it may become exploitable?!

Another source suggests that there is little value in TCPKeepAlive yes, so long as ClientAliveInterval is configured appropriately.

A blog post (from 2013) titled "Hardening your SSH server" (under the heading "Prevent zombies") suggests:

To avoid infinitely hanging sessions, this should be left on.

Although as it doesn't mention ClientAliveInterval, I'm guessing perhaps that may not be 100% relevant now?

Please note that despite my significant googling, all of my sources, bar the 2013 blog post, come from the GitHub thread I've linked to. Beyond those few mentions. I can find nothing substantial one way or the other. Further sources, especially authoritative ones would be warmly welcomed.

Answer 1

There are three primary ways to keep an SSH session alive:

• TCPKeepAlive - An empty ACK is periodically sent, preventing the TCP connection from naturally closing due to inactivity. This operates entirely on the TCP-level. It can only be spoofed with an MITM attack or an extremely advanced TCP-hijacking adversary.

• ServerAliveInterval - A message is sent periodically from the client to the server using the SSH protocol. The main benefit to using this is that a firewall cannot tell if it is a keepalive or a legitimate message. A TCP keepalive on the other hand may be blocked by a firewall.

• ClientAliveInterval - Idem but sent from the server to the client.

Is there any risk to an attacker forcing an SSH connection to stay open? Not really. The ephemeral session key is periodically changed to prevent a long-running SSH session from being a more juicy target. As such, I can't think of any significant reason why sending keepalives through the TCP layer would be considered a security issue. However, there is still no reason to use it. You can safely use either ClientAliveInterval or ServerAliveInterval and disable TCP keepalives.