similar to: Sending SSH_MSG_DISCONNECT before dropping connections

Hello, can anyone confirm that OpenSSH server doesn't log client disconnect without SSH_MSG_DISCONNECT? PuTTY stopped sending it long time ago [1] and I wonder if any client must or at least should do that like OpenSSH client does. I have disabled e-mail delivery so Cc me please. Regards, Opty ---------- [1]

On Tue, 21 May 2024, Opty wrote: > Hello, > > can anyone confirm that OpenSSH server doesn't log client disconnect > without SSH_MSG_DISCONNECT? OpenSSH logs the disconnection regardless of whether the client sends SSH_MSG_DISCONNECT or just drops the connection. A little more information may be logged from the disconnect packet if it was sent, but there should always be a

On Sun, 26 May 2024, Opty wrote: > On Wed, May 22, 2024 at 6:29?AM Damien Miller <djm at mindrot.org> wrote: > > On Tue, 21 May 2024, Opty wrote: > > > Hello, > > > > > > can anyone confirm that OpenSSH server doesn't log client disconnect > > > without SSH_MSG_DISCONNECT? > > > > OpenSSH logs the disconnection regardless of

On Wed, May 22, 2024 at 6:29?AM Damien Miller <djm at mindrot.org> wrote: > OpenSSH logs the disconnection regardless of whether the client sends > SSH_MSG_DISCONNECT or just drops the connection. > > A little more information may be logged from the disconnect packet > if it was sent, but there should always be a "Connection closed by ..." > message regardless. I

On Mon, May 27, 2024 at 4:18?AM Damien Miller <djm at mindrot.org> wrote: > Yeah, you're adding a new thing that will be logged. IMO you should > try to figure out why the "Connection closed" message that is present > in the debug log you sent is not making to to your syslog. If I change LogLevel in /etc/ssh/sshd_config from default INFO to VERBOSE then I see

On Wed, 29 May 2024, Opty wrote: > On Mon, May 27, 2024 at 4:18?AM Damien Miller <djm at mindrot.org> wrote: > > Yeah, you're adding a new thing that will be logged. IMO you should > > try to figure out why the "Connection closed" message that is present > > in the debug log you sent is not making to to your syslog. > > If I change LogLevel in

On Thu, May 30, 2024 at 6:02?PM Opty <opty77 at gmail.com> wrote: > On Thu, May 30, 2024 at 3:03?AM Damien Miller <djm at mindrot.org> wrote: > > On Wed, 29 May 2024, Opty wrote: > > > On Mon, May 27, 2024 at 4:18?AM Damien Miller <djm at mindrot.org> wrote: > > > > Yeah, you're adding a new thing that will be logged. IMO you should > >

On Fri, 31 May 2024, Opty wrote: > > 9.3p2, 64-bit Slackware 15.0 package which uses two patches but they > > look LogLevel-safe to me, you can check at > > http://ftp.slackware.com/pub/slackware/slackware64-15.0/patches/source/openssh/ > > 9.7p1 built from source without TCP wrappers and still no 'Connection > closed' at 'LogLevel INFO'. You might be

On Sat, Jun 1, 2024 at 5:23?AM Damien Miller <djm at mindrot.org> wrote: > On Fri, 31 May 2024, Opty wrote: > > 9.7p1 built from source without TCP wrappers and still no 'Connection > > closed' at 'LogLevel INFO'. > > You might be hitting this exit path: > > diff --git a/serverloop.c b/serverloop.c > index 4eabfced6..bf45f77a2 100644 > ---

On Sat, 1 Jun 2024, Opty wrote: > Indeed I am. > > What now? We need to decide whether to promote these log messages to INFO. > Should PuTTY change its 'perfectly OK to unceremoniously > slam the connection shut when you're done' attitude? I don't think they need to. I think it's fair that we log connections that are terminated regardsless of how graceful

On Wed, Jun 5, 2024 at 6:03?AM Damien Miller <djm at mindrot.org> wrote: > On Sat, 1 Jun 2024, Opty wrote: > > Indeed I am. > > > > What now? > > We need to decide whether to promote these log messages to INFO. > > > Should PuTTY change its 'perfectly OK to unceremoniously > > slam the connection shut when you're done' attitude? > >

On Wed, Jun 5, 2024 at 3:14?PM Opty <opty77 at gmail.com> wrote: > On Wed, Jun 5, 2024 at 6:03?AM Damien Miller <djm at mindrot.org> wrote: > > On Sat, 1 Jun 2024, Opty wrote: > > > Indeed I am. > > > > > > What now? > > > > We need to decide whether to promote these log messages to INFO. > > > > > Should PuTTY change its

On Tue, Jun 11, 2024 at 1:24?PM Opty <opty77 at gmail.com> wrote: > On Wed, Jun 5, 2024 at 3:14?PM Opty <opty77 at gmail.com> wrote: > > On Wed, Jun 5, 2024 at 6:03?AM Damien Miller <djm at mindrot.org> wrote: > > > We need to decide whether to promote these log messages to INFO. > > > > > > [...] > > > > I will wait for the final

On Fri, 14 Jun 2024, Opty wrote: > On Tue, Jun 11, 2024 at 1:24?PM Opty <opty77 at gmail.com> wrote: > > On Wed, Jun 5, 2024 at 3:14?PM Opty <opty77 at gmail.com> wrote: > > > On Wed, Jun 5, 2024 at 6:03?AM Damien Miller <djm at mindrot.org> wrote: > > > > We need to decide whether to promote these log messages to INFO. > > > > > >

On Mon, Jun 17, 2024 at 10:50?AM Damien Miller <djm at mindrot.org> wrote: > On Fri, 14 Jun 2024, Opty wrote: > > On Tue, Jun 11, 2024 at 1:24?PM Opty <opty77 at gmail.com> wrote: > > > On Wed, Jun 5, 2024 at 3:14?PM Opty <opty77 at gmail.com> wrote: > > > > On Wed, Jun 5, 2024 at 6:03?AM Damien Miller <djm at mindrot.org> wrote: > > >

On Thu, May 30, 2024 at 3:03?AM Damien Miller <djm at mindrot.org> wrote: > On Wed, 29 May 2024, Opty wrote: > > On Mon, May 27, 2024 at 4:18?AM Damien Miller <djm at mindrot.org> wrote: > > > Yeah, you're adding a new thing that will be logged. IMO you should > > > try to figure out why the "Connection closed" message that is present > >

To whomsoever it may concern, I use putty-0.51 as ssh client on windows and openssh-2.9p2 implementation on RedHat 7.0 Linux as ssh server. For the client to exit, I expected ssh client to send SSH_CMSG_EOF to the server and the server respond with SSH_CMSG_EXITSTATUS and finally close the connection when the client sends SSH_CMSG_EXIT_CONFIRMATION. This will effectively end the server_loop in

I am testing with a 5.4p1 client and have noticed, on the server side, that sometimes an SSH_MSG_DISCONNECT message is received with the following 28-byte long payload: 0x00 0x00 0x00 0x0b Reason: SSH_DISCONNECT_BY_APPLICATION 0x00 0x00 0x00 0x14 Description string length: 20 bytes 0x64 0x69 0x73 0x63 0x6f 0x6e 0x6e 0x65

http://bugzilla.mindrot.org/show_bug.cgi?id=1307 Summary: client disconnects if ServerAlive enabled but not implemented Product: Portable OpenSSH Version: 4.3p2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at

Is anyone aware of a method to force termination of a single channel without waiting for the associated process to complete? I have a use case where my client submits several commands to be executed over the same session at the same time on separate channels. In some cases (cough df), one or more those commands may hang indefinitely. I detect that the command is not finishing in a reasonable