Is it possible to set ClientAliveInterval from the client side?

Question

Is it possible to set something like the sshd ClientAliveInterval and ClientAliveCountMax from the client (ssh) side for a particular connection?

I am thinking of something like ssh -o ClientAliveInterval=15 (which obviously doesn't work since -o is for client/ssh options. Or perhaps a way to have sshd options applied to particular connections.

My use case is that for remote port forwarding connections I would like to set the ClientAliveInterval low so that the server closes them more quickly. To goal being to avoid a stale sshd session holding on to the port and keeping me from reconnecting ("Error: remote port forwarding failed for listen port").

Note I am not looking for ServerAliveInterval or ServerAliveCountMax since they only control the client side of the connection, which doesn't help for remote port forwarding.

Answer 1

If you can use a separate connection only to forward port(s), i.e. possibly with -N, then consider this workaround:

while echo; do sleep 1; done | ssh user@server 'exec bash -c "while read -t 5; do :; done"'

(Include port forwarding(s) on your own).

When newlines from echo stop getting to the remote side, read -t 5 will eventually fail and the entire remote loop will exit. The SSH server will notice its child process exited, it will terminate the connection and release the port(s).

Notes:

• read -t is not portable, the command explicitly calls bash to handle it.
• If the command interpreter for user@server is bash then there is no need for exec bash; sole "while read -t 5; do :; done" (instead of 'exec bash -c …') will work.
• read -t 5 is quite straightforward. You can develop code that implements the concepts of Interval and CountMax.

I tested this approach on my laptop, with actual remote port forwarding (-R) and beep instead of : to hear from the server. When I disconnected Wi-Fi, the beeping stopped. When I reconnected Wi-Fi quickly, the beeping caught up and continued. But when I reconnected few seconds too late, the local command exited because it learned the SSH server had terminated the connection as designed. Important things:

• There were other SSH connections to the same server, governed by *AliveInterval and *AliveCountMax, and they survived. This means my special connection ended without assistance from these options. If I waited long enough with Wi-Fi turned off, then almost all connections would terminate because of the options, including the local half of the special connection. The exception would be the remote half; it would have been long gone anyway because bash would had exited.
• I was able to connect again immediately, never got remote port forwarding failed for listen port. Therefore I think my approach can be a valid solution to your problem.

Answer 2

No, it isn't possible to control those settings from the client side. They control how often the server sends keepalive messages and how many to wait for before disconnecting. Those are server-wide settings and apply to all connections. Allowing clients to set them, even per-connection, would have security implications since it could permit malicious clients to consume excessive server resources.

If you wanted to set those settings, you'd need to do that in the server's /etc/sshd/sshd_config file. Note that setting them such that dropped connections are terminated quickly shouldn't be a problem, since generally those connections would be dropped eventually anyway.