Date: Mon, 6 Mar 2023 12:49:02 -0800 From: Peter Wemm <peter@wemm.org> To: Mike Karels <mike@karels.net>, Michael Gmelin <grembo@freebsd.org> Cc: Yuri <yuri@freebsd.org>, freebsd-net@freebsd.org Subject: Re: sshd doesn't disconnect for 30+ minutes after the TCP connection is closed ungracefully Message-ID: <540652d7-953b-12bc-42cc-982d4dd85849@wemm.org> In-Reply-To: <49CE5046-7934-414C-9B62-F3712DECBA52@karels.net> References: <baf5faa3-3c03-fb9e-4196-bd26c2fc622e@tsoft.com> <08DDB90C-5D30-40A3-86C0-87021959F04D@freebsd.org> <49CE5046-7934-414C-9B62-F3712DECBA52@karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?540652d7-953b-12bc-42cc-982d4dd85849>