Mailing List Archive

Try setting

Host *
  ServerAliveInterval 240

in .ssh/config on the client (wherever that is in Windows).  Or pass "-o
ServerAliveInterval=240" on the ssh client command line.

I've seen this where connections pass through some low grade external
firewall, which drops state after a certain amount of inactivity without
sending back RST (and apparently is immune to TCP keepalives too).

You say both boxes are on the same LAN, but it's possible that a
badly-configured software firewall on the FreeBSD box could be the cause
- or on Windows itself.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

It depends how you "kill" the SSH server.

If you kill it by sending it a SIGKILL signal, it will NOT notify the
client, so the client will stay running until the client discovers the
connection is broken.

What happens if you send the SSH server a SIGHUP signal? This should cause
an orderly shutdown on the server, which should notify the client, which
should cause the client to do an orderly shutdown.

On Fri, 7 Apr 2023, Yuri wrote:

> I connect with the OpenSSH client on Windows to the OpenSSH server on
> FreeBSD, all in one LAN, Wifi to Eithernet.
>
>
> After a while, usually when the connection is inactive for some time, it
> becomes dysfunctional: it becomes impossible to connect through reverse port
> forwards from FreeBSD to Windows.
>
> At such times killing the ssh server process on FreeBSD, corresponding to the
> connection, doesn't cause the client to exit on Windows.
>
> But hitting Enter on the client in Windows causes it to immediately exit.
>
>
> Did anybody experience a problem like this?
>
> Could there be a bug in OpenSSH?
>
> Is it possible that Windows fails to deliver the signal to the client that
> the connection was terminated?
>
>
> Thank you,
>
> Yuri
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

Regards,
....Bob Rasmussen, President, Rasmussen Software, Inc.

personal e-mail: ras@anzio.com
company e-mail: rsi@anzio.com
voice: (US) 503-624-0360
fax: no longer available
web: http://www.anzio.com
Mailing address: Rasmussen Software, Inc. NEW AS OF JULY 1, 2022
6265 SW Erickson Ave.
Beaverton OR 97008 USA
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi Brian,

On 4/7/23 09:32, Brian Candler wrote:
> in .ssh/config on the client (wherever that is in Windows).  Or pass
> "-o ServerAliveInterval=240" on the ssh client command line.


I added '-o ServerAliveInterval=50' in the beginning of arguments on the
client side, but it made no difference at all.


Yuri


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi Rob,


On 4/7/23 10:08, Bob Rasmussen wrote:
> It depends how you "kill" the SSH server.
>
> If you kill it by sending it a SIGKILL signal, it will NOT notify the
> client, so the client will stay running until the client discovers the
> connection is broken.


I run 'kill <pid>' which sends SIGTERM. This should shout it down
gracefully.

But even with SIGKILL the OS would still shut down the network
connection gracefully, and this should be propagated to the client.



Yuri


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Friday, April 7, 2023 1:13 PM, Yuri wrote:
>On 4/7/23 10:08, Bob Rasmussen wrote:
>> It depends how you "kill" the SSH server.
>>
>> If you kill it by sending it a SIGKILL signal, it will NOT notify the
>> client, so the client will stay running until the client discovers the
>> connection is broken.
>
>
>I run 'kill <pid>' which sends SIGTERM. This should shout it down
>gracefully.
>
>But even with SIGKILL the OS would still shut down the network
>connection gracefully, and this should be propagated to the client.

Windows sometimes keeps sockets around until TTL expires. If you have Cygwin
or similar, netstat -a will show you any sockets that are around but no
longer connected (FIN-WAIT). If a process tries to bind to a bound socket on
the same port during that period, the bind may fail (it does not on some
platforms).

--Randall

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

The OpenSSH daemon is supposed to start, and fork off additional
daemons for new connections, to prevent the loss of the main daemon
from killing vital, long-running, active connections. Various tools
have tried to mandate the end of client sessions, for various reasons
and by various mens,

Please don't try to "improve security" by breaking long-standing
features. This feature, in particular, allows a remote administrator
to revise the SSH configuration, restart it for validation, and not
lose the existing remote shell session to allow reverting a risky
chnage. Such changes would become *vastly* more risky, and very
difficult to revert due to the now broken sshd configuration. Been
there, done that. Last Tuesday.....

On Fri, Apr 7, 2023 at 12:18?PM Yuri <yuri@rawbw.com> wrote:
>
> I connect with the OpenSSH client on Windows to the OpenSSH server on
> FreeBSD, all in one LAN, Wifi to Eithernet.
>
>
> After a while, usually when the connection is inactive for some time, it
> becomes dysfunctional: it becomes impossible to connect through reverse
> port forwards from FreeBSD to Windows.
>
> At such times killing the ssh server process on FreeBSD, corresponding
> to the connection, doesn't cause the client to exit on Windows.
>
> But hitting Enter on the client in Windows causes it to immediately exit.
>
>
> Did anybody experience a problem like this?
>
> Could there be a bug in OpenSSH?
>
> Is it possible that Windows fails to deliver the signal to the client
> that the connection was terminated?
>
>
> Thank you,
>
> Yuri
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 4/7/23 21:46, Damien Miller wrote:
> without debug logs from both the client and server in this situation, it's
> not really possible to say what is going on.


What are the options that I should use to generate logs?


Yuri


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Fri, 7 Apr 2023, Yuri wrote:

> On 4/7/23 21:46, Damien Miller wrote:
> > without debug logs from both the client and server in this situation, it's
> > not really possible to say what is going on.
>
>
> What are the options that I should use to generate logs?

ssh -vvv on the client, sshd -oLogLevel=debug3 on the server
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, 8 Apr 2023 at 08:46, Yuri <yuri@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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 4/7/2023 1:13 PM, Yuri wrote:
> On 4/7/23 10:08, Bob Rasmussen wrote:
>> It depends how you "kill" the SSH server.
>>
>> If you kill it by sending it a SIGKILL signal, it will NOT notify the
>> client, so the client will stay running until the client discovers
>> the connection is broken.
>
>
> I run 'kill <pid>' which sends SIGTERM. This should shout it down
> gracefully.
>
The <pid> you reference, is that the process for the actual windows
client connection that was spawned off, or the server. If the server,
the existing connections will still live.

e.g.

here are all the ssh processes on a FreeBSD server. If I kill the master
(pid 865), my session is still alive. I just cant get new ones

#  ps -auxwww | grep ssh
root       865   0.0  0.2  21072  8816  -  Ss   Thu11 0:00.00 sshd:
/usr/sbin/sshd [listener] 0 of 10-100 startups (sshd)
root     12441   0.0  0.2  21144  9372  -  Ss   13:01 0:00.02 sshd: mike
[priv] (sshd)
mike 12443   0.0  0.2  21144  9644  -  S    13:01       0:00.01 sshd:
mike@pts/0 (sshd)
root     12458   0.0  0.1  12816  2340  1  S+   13:01 0:00.00 grep ssh

# kill 865

# ps -auxwww | grep ssh
root     12441   0.0  0.2  21144  9372  -  Is   13:01 0:00.02 sshd: mike
[priv] (sshd)
mike  12443   0.0  0.2  21144  9644  -  S    13:01       0:00.01 sshd:
mike@pts/0 (sshd)
root     12461   0.0  0.1  12868  2364  1  R+   13:02 0:00.00 grep ssh

In the above case, I think you want to kill 12441 and its child 12443.

I just tested on a new login via the windows ssh client, and it indeed
killed the connection when I killed the two processes on the server

 kill 12532 12534


0(testgateway)# Connection to 192.168.243.5 closed by remote host.
Connection to 192.168.243.5 closed.

C:\Users\mike>


    ---Mike

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 4/11/23 10:09, mike tancsa wrote:
> The <pid> you reference, is that the process for the actual windows
> client connection that was spawned off, or the server. If the server,
> the existing connections will still live.


The <pid> there is ssh server child process pid for the Windows connection.

It should own the connection, and killing it should gracefully kill the
TCP connection.


Yuri


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev