Re: sshd doesn't disconnect for 30+ minutes after the TCP connection is closed ungracefully

From: Peter Wemm <peter_at_wemm.org>
Date: Mon, 06 Mar 2023 20:49:02 UTC
On 3/1/23 05:03, Mike Karels wrote:
> On 1 Mar 2023, at 5:36, Michael Gmelin wrote:
>
>>> On 1. Mar 2023, at 11:35, Yuri <yuri@freebsd.org> wrote:
>>>
>>> Windows system connects to FreeBSD through ssh and then this connection dies because of WiFi or VPN issues.
>>>
>>> FreeBSD still has the sshd process alive for this connection for 30+ minutes.
>>>
>>> TCP keepalive is enabled on the FreeBSD host:
>>>
>>> $ sysctl net.inet.tcp.always_keepalive
>>> net.inet.tcp.always_keepalive: 1
>>>
>>> Shouldn't TCP keepalive kill this sshd process after 3-4 minutes because this connection isn't alive?
>>>
>> Keepalives start after net.inet.tcp.keepidle milliseconds (2h by default).
> When this happens to me, I generally log into the server again and use write(1)
> to send a message to that tty (a newline will do).  That probes the connection
> and causes a reset, and the session gets cleaned up.  I use a longer keepidle
> value for other reasons.
>
> 		Mike
>
Personaly, I set ClientAliveCountMax and ClientAliveCountInterval in 
sshd_config on my servers.

      ClientAliveInterval
              Sets a timeout interval in seconds after which if no data has
              been received from the client, sshd(8) will send a message
              through the encrypted channel to request a response from the
              client.

I set mine fairly to start early (eg: Interval = 60).  If the connection 
has dropped then even the first probe will cause tcp to do its retries 
and lead to a connection drop.

When I was commuting on shuttles and rail, I did this on the client side 
(~/.ssh/config with ServerAlive* probes) for different reasons.  The 
(overloaded) router would drop connections that seemed idle.  Sending 
probes helped prevent that - or at least making the router drop somebody 
else's instead.

-Peter