From nobody Mon Mar 06 20:49:02 2023 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PVrKN5t75z3wMcs for ; Mon, 6 Mar 2023 20:49:12 +0000 (UTC) (envelope-from peter@wemm.org) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp2.wemm.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PVrKM5qkJz4X05; Mon, 6 Mar 2023 20:49:11 +0000 (UTC) (envelope-from peter@wemm.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=wemm.org header.s=m20140428 header.b=UYjX9AL1; spf=pass (mx1.freebsd.org: domain of peter@wemm.org designates 192.203.228.78 as permitted sender) smtp.mailfrom=peter@wemm.org; dmarc=none Received: from [10.0.0.3] (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 38A0116E70; Mon, 6 Mar 2023 12:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1678135742; bh=L+tfVjPcfsRmdcbBUCanL/5VHOam4HgAgFArTx1SbIk=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=UYjX9AL10DLcDj6O/ITQB9RkPt8ZP3lN5LKiEsfkA8uJtv/UuAw7s9X+24aHswW01 LXzfckkjDFjk74zpxjsFu8omPbLYCdlgCXwIAygDyQrIHnzxxXrEIwrKERws/JkKeM kZOObLnORLnFUUVqx7LEXZCuBuyi9vyT4PqM9Yrw= Message-ID: <540652d7-953b-12bc-42cc-982d4dd85849@wemm.org> Date: Mon, 6 Mar 2023 12:49:02 -0800 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: sshd doesn't disconnect for 30+ minutes after the TCP connection is closed ungracefully Content-Language: en-US To: Mike Karels , Michael Gmelin Cc: Yuri , freebsd-net@freebsd.org References: <08DDB90C-5D30-40A3-86C0-87021959F04D@freebsd.org> <49CE5046-7934-414C-9B62-F3712DECBA52@karels.net> From: Peter Wemm In-Reply-To: <49CE5046-7934-414C-9B62-F3712DECBA52@karels.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_SPF_ALLOW(-0.20)[+ip4:192.203.228.78]; R_DKIM_ALLOW(-0.20)[wemm.org:s=m20140428]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:6140, ipnet:192.203.228.0/24, country:US]; DKIM_TRACE(0.00)[wemm.org:+]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[peter]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[wemm.org]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PVrKM5qkJz4X05 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N 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 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