Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Jakub Jelen <jjelen@xxxxxxxxxx>]

Thank you.

I see right, in this case, there is no log line with
ssh_message_reply_default(), that was the problem previously.

I also see in the build process that the patch to check the return
value of nc_session_ssh_msg() was added (but with wrong argument --
msg instead of ssh_msg) -- I also do not see that patch applied
anywhere. Can you try with the attached patch if it will make some
difference?


On Thu, Sep 5, 2024 at 4:14 PM Mikael Petterson
<mikael.petterson@xxxxxxxxxxxx> wrote:
>
> Hi Jakub and Michal
>
> I finally managed to replace and use level 4.
>
> I will attach file.
>
> Br,
>
> //mike
>
> -----Original Message-----
> From: Jakub Jelen <jjelen@xxxxxxxxxx>
> Sent: Thursday, 5 September 2024 10:58
> To: libssh@xxxxxxxxxx
> Subject: Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown
>
> Right, this message sounds suspicious, but it is not clear to me where does it come from, especially when I can not reproduce the issue with just libssh as mentioned before.
>
> I see in the log that the `trilead-ping` is received twice over the exchange, but both are processed only at the end of the output. The first comes with type 0:
>
> 2024-09-04 10:02:36,496 (Slf4jLogConsumer.java:73)  INFO : STDERR:
> [2024/09/04 08:02:36.482476, 3] ssh_message_reply_default:  Don't know what to default reply to 0 type
>
> but the second comes with the suspicious large value, which differs between invocations (If I read right):
>
> 2024-09-04 10:02:36,920 (Slf4jLogConsumer.java:73)  INFO : STDERR:
> [2024/09/04 08:02:36.925229, 3] ssh_message_reply_default:  Don't know what to default reply to 1120325360 type
>
> So this looks like that the memory where the message is stored (when passed to the ssh_message_reply_default() function), is either uninitialized or more likely freed and already rewritten by something else. Can you run the netopeer2 under valgrind to see if there are some invalid memory accesses or violations?
>
> Jakub
>
> On Thu, Sep 5, 2024 at 8:18 AM Michal Vasko <mvasko@xxxxxxxxx> wrote:
> >
> > Hi Jakub,
> >
> > libnetconf2/netopeer2 author here. The issue actually started in our
> > projects but was then moved to libssh because I believe that is where
> > the problem is. That should be supported by the output
> >
> > [2024/09/02 09:46:31.284447, 3] ssh_message_reply_default:  Don't know
> > what to default reply to 67108912 type
> >
> > meaning libssh is asked to send the reply but it fails to do so. You
> > asked for trace-level output and Mike should be able to provide it,
> > soon. Hopefully, you will be able to reproduce the problem and fix it then.
> >
> > Regards,
> > Michal
> >
> > On 4. 9. 2024 17:21, Jakub Jelen wrote:
> > > The following line from the log shows that the function processing
> > > the packet is called as expected
> > >
> > > 2024-09-04 10:02:36,919 (Slf4jLogConsumer.java:73)  INFO : STDERR:
> > > [2024/09/04 08:02:36.925128, 3] ssh_message_handle_channel_request:
> > > Received a trilead-ping channel_request for channel (43:100)
> > > (want_reply=1)
> > >
> > > So it looks like all of the message is parsed correctly on the
> > > libssh side. The next message comes form netopeer2:
> > >
> > > 2024-09-04 10:02:36,920 (Slf4jLogConsumer.java:73)  INFO : STDERR:
> > > [INF]: LN: Session 1: Received an SSH message "request-channel" of
> > > subtype "unknown".
> > >
> > >  From here:
> > >
> > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2FCESNET%2Flibnetconf2%2Fblob%2F47ca0fb5f94588d112ec2bf2694
> > > 6948189e1c18d%2Fsrc%2Fsession_server_ssh.c%23L1692&data=05%7C02%7Cmi
> > > kael.petterson%40ericsson.com%7C719221ae31dc4b58302a08dccd88d893%7C9
> > > 2e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638611234853208375%7CUnkno
> > > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> > > iLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Y6QUN%2Fj4%2F9qN9Dscw4MgnrDVxy7oJ
> > > 1ytZ%2B4Evkphj5E%3D&reserved=0
> > >
> > > It looks like netopeer2 is handling the messages on its own instead
> > > of using the callbacks. It most of the cases, the callers of this
> > > function check the return value, but there is one where they do not
> > > do that, which might cause this behavior where the reply is not sent:
> > >
> > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2FCESNET%2Flibnetconf2%2Fblob%2F47ca0fb5f94588d112ec2bf2694
> > > 6948189e1c18d%2Fsrc%2Fsession_server.c%23L1609&data=05%7C02%7Cmikael
> > > .petterson%40ericsson.com%7C719221ae31dc4b58302a08dccd88d893%7C92e84
> > > cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638611234853219071%7CUnknown%7
> > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> > > XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=p3xTb6x9a1nrqaZPJ5H1l7NNGDSHctbuOHE%2
> > > BTqO775c%3D&reserved=0
> > >
> > > I would probably suggest to open an issue to netopeer2 to confirm
> > > that this could be the cause. The default callbacks that we have in
> > > libssh seems to process the messages correctly.
> > >
> > > Jakub
> > >>>>> I checked the RFC
> > >>>>> https://ww/
> > >>>>> w.rfc-editor.org%2Frfc%2Frfc4254.html%23section-5&data=05%7C02%7
> > >>>>> Cm
> > >>>>> ik
> > >>>>> ael.petterson%40ericsson.com%7C2e154092532e4b0f804308dccc035f05%
> > >>>>> 7C
> > >>>>> 92
> > >>>>> e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638609562056373731%7CUn
> > >>>>> kn
> > >>>>> ow
> > >>>>> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> > >>>>> aW
> > >>>>> wi
> > >>>>> LCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Q%2FSgGmCtGEbBiJV2ah9n2IAsdFaa
> > >>>>> CN
> > >>>>> XW
> > >>>>> QsYZ7E0CcmQ%3D&reserved=0
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 5.4.  Channel-Specific Requests
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>     Many 'channel type' values have extensions that are specific
> > >>>>> to that
> > >>>>>
> > >>>>>     particular 'channel type'.  An example is requesting a pty
> > >>>>> (pseudo
> > >>>>>
> > >>>>>     terminal) for an interactive session.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>     All channel-specific requests use the following format.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>        byte      SSH_MSG_CHANNEL_REQUEST
> > >>>>>
> > >>>>>        uint32    recipient channel
> > >>>>>
> > >>>>>        string    request type in US-ASCII characters only
> > >>>>>
> > >>>>>        boolean   want reply
> > >>>>>
> > >>>>>        ....      type-specific data follows
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Ylonen & Lonvick            Standards Track                     [Page 9]
> > >>>>>
> > >>>>> ________________________________
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> RFC 4254                SSH Connection Protocol             January 2006
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>     If 'want reply' is FALSE, no response will be sent to the request.
> > >>>>>
> > >>>>>     Otherwise, the recipient responds with either
> > >>>>>
> > >>>>>     SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, or
> > >>>>> request-specific
> > >>>>>
> > >>>>>     continuation messages.  If the request is not recognized or
> > >>>>> is not
> > >>>>>
> > >>>>>     supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>     This message does not consume window space and can be sent
> > >>>>> even if no
> > >>>>>
> > >>>>>     window space is available.  The values of 'request type' are
> > >>>>> local to
> > >>>>>
> > >>>>>     each channel type.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>     The client is allowed to send further messages without
> > >>>>> waiting for
> > >>>>>
> > >>>>>     the response to the request.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>     'request type' names follow the DNS extensibility naming
> > >>>>> convention
> > >>>>>
> > >>>>>     outlined in [SSH-ARCH] and [SSH-NUMBERS].
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>        byte      SSH_MSG_CHANNEL_SUCCESS
> > >>>>>
> > >>>>>        uint32    recipient channel
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>        byte      SSH_MSG_CHANNEL_FAILURE
> > >>>>>
> > >>>>>        uint32    recipient channel
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>     These messages do not consume window space and can be sent
> > >>>>> even if no
> > >>>>>
> > >>>>>     window space is available.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> So we should at least expect a SSH_MSG_CHANNEL_FAILURE.
> > >>>>>
> > >>>>>
> > >>>>> I checked:
> > >>>>>
> > >>>>> https://gi/
> > >>>>> thub.com%2Flibssh%2Flibssh-mirror%2Fblob%2Fmaster%2Fsrc%2Fmessag
> > >>>>> es
> > >>>>> .c
> > >>>>> %23L175&data=05%7C02%7Cmikael.petterson%40ericsson.com%7C2e15409
> > >>>>> 25
> > >>>>> 32
> > >>>>> e4b0f804308dccc035f05%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0
> > >>>>> %7
> > >>>>> C6
> > >>>>> 38609562056380910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > >>>>> JQ
> > >>>>> Ij
> > >>>>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=71nn
> > >>>>> DT
> > >>>>> 4y
> > >>>>> jtVA0tkfjqrViDjTKFyhsPwtQibVIJFzhr8%3D&reserved=0
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> But could not see any support for unknown.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Maybe I am looking in the wrong place.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Br.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> //mike
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>
> > >
>
>

diff --git a/src/session_server.c b/src/session_server.c
index 5abbb8e..3ebbcf9 100644
--- a/src/session_server.c
+++ b/src/session_server.c
@@ -1646,7 +1646,10 @@ nc_ps_poll_session_io(struct nc_session *session, int io_timeout, time_t now_mon
     case NC_TI_SSH:
         ssh_msg = ssh_message_get(session->ti.libssh.session);
         if (ssh_msg) {
-            nc_session_ssh_msg(session, NULL, ssh_msg, NULL);
+            r = nc_session_ssh_msg(session, NULL, ssh_msg, NULL);
+            if (r == 1) {
+                ssh_message_reply_default(ssh_msg);
+            }
             if (session->ti.libssh.next) {
                 for (new = session->ti.libssh.next; new != session; new = new->ti.libssh.next) {
                     if ((new->status == NC_STATUS_STARTING) && new->ti.libssh.channel &&