Re: sshd doesn't disconnect for 30+ minutes after the TCP connection is closed ungracefully
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