openssh unix dev - Apr 2023 - Killing the OpenSSH server doesn't cause the Windows OpenSSH client to die

The fact that '-o ServerAliveInterval=50' makes no difference suggests 
that there is a bug in the OpenSSH client.
It either fails to sent heartbeats, or it gets stuck in some Windows 
system call and this makes it to fail to send heartbeats.


Yuri

On Fri, 7 Apr 2023, Yuri wrote:
> The fact that '-o ServerAliveInterval=50' makes no difference
suggests that
> there is a bug in the OpenSSH client.
> It either fails to sent heartbeats, or it gets stuck in some Windows system
> call and this makes it to fail to send heartbeats.
without debug logs from both the client and server in this situation, it's
not really possible to say what is going on.

Bear in mind that the Portable OpenSSH project and the Windows OpenSSH
project are separate. They use our code, but do a number of things quite
differently so if you suspect a problem in their code then they are the ones
to contact (e.g. via a github issue).

-d

On Sat, 8 Apr 2023 at 08:46, Yuri <yuri at rawbw.com>
wrote:
> The fact that '-o ServerAliveInterval=50' makes no difference
suggests
> that there is a bug in the OpenSSH client.
> It either fails to sent heartbeats or it gets stuck in some Windows
> system call and this makes it to fail to send heartbeats.
Not necessarily.  Setting the ServerAliveInterval by itself is not
sufficient to detect some classes of problems, for example if the
remote end becomes completely non-responsive or the packets are
dropped by a firewall.  If the heartbeats do not provoke a response
from the peer (a TCP reset in this example), ssh won't know it's
really gone.   You need to add ServerAliveCountMax  to tell the client
to give up after some number of unacknowledged ServerAlives.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.