RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Mikael Petterson <mikael.petterson@xxxxxxxxxxxx>]

Hi

Yes my testcase works now and I cannot see any issues.
Thanks for the support from both of you.

Br,

//mike


-----Original Message-----
From: Michal Vasko <mvasko@xxxxxxxxx> 
Sent: Monday, 9 September 2024 11:34
To: libssh@xxxxxxxxxx
Subject: Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

Hi,

@Mike Please try using the current `devel` branches WITHOUT any patches. 
It is likely there was some confusion and you were applying a faulty 
patch. Jakub's patch should fix the issue, so I have committed it.

@Jakub Thanks for the patch.

Regards,
Michal

On 9. 9. 2024 10:16, Mikael Petterson wrote:
> Hi,
>
> Jakub, was the log sufficient?
>
> Br.
>
> //mike
>
> -----Original Message-----
> From: Mikael Petterson <mikael.petterson@xxxxxxxxxxxx>
> Sent: Friday, 6 September 2024 11:22
> To: libssh@xxxxxxxxxx
> Subject: RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknown
>
> Hi,
>
> I applied the patch.
>
> Attaching new log file here.
>
> Br,
>
> //mike
>
> -----Original Message-----
> From: Jakub Jelen <jjelen@xxxxxxxxxx>
> Sent: Friday, 6 September 2024 09:41
> To: libssh@xxxxxxxxxx
> Subject: Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown
>
> 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%2F
>>>> gi%2F&data=05%7C02%7Cmikael.petterson%40ericsson.com%7C4523de353f3
>>>> b4b21677f08dcce474669%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7
>>>> C638612052746761002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
>>>> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Lh
>>>> BNVBPm7pfRaiqrxSfmTJw4AaTTLdp6UYbFejf2TLU%3D&reserved=0
>>>> thub.com%2FCESNET%2Flibnetconf2%2Fblob%2F47ca0fb5f94588d112ec2bf26
>>>> 94
>>>> 6948189e1c18d%2Fsrc%2Fsession_server_ssh.c%23L1692&data=05%7C02%7C
>>>> mi
>>>> kael.petterson%40ericsson.com%7C719221ae31dc4b58302a08dccd88d893%7
>>>> C9
>>>> 2e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638611234853208375%7CUnk
>>>> no
>>>> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>>>> Ww
>>>> iLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Y6QUN%2Fj4%2F9qN9Dscw4MgnrDVxy7
>>>> oJ
>>>> 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%2F
>>>> gi%2F&data=05%7C02%7Cmikael.petterson%40ericsson.com%7C4523de353f3
>>>> b4b21677f08dcce474669%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7
>>>> C638612052746778162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
>>>> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=u8
>>>> iOGYcF1WcUjrK%2BI3TeQNrMrn0Bu0leulAEKbc1JS4%3D&reserved=0
>>>> thub.com%2FCESNET%2Flibnetconf2%2Fblob%2F47ca0fb5f94588d112ec2bf26
>>>> 94
>>>> 6948189e1c18d%2Fsrc%2Fsession_server.c%23L1609&data=05%7C02%7Cmika
>>>> el
>>>> .petterson%40ericsson.com%7C719221ae31dc4b58302a08dccd88d893%7C92e
>>>> 84
>>>> cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638611234853219071%7CUnknown
>>>> %7
>>>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
>>>> CJ
>>>> 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%7C2e154092532e4b0f804308dccc035f0
>>>>>>>> 5%
>>>>>>>> 7C
>>>>>>>> 92
>>>>>>>> e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638609562056373731%7C
>>>>>>>> Un
>>>>>>>> kn
>>>>>>>> ow
>>>>>>>> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
>>>>>>>> 1h
>>>>>>>> aW
>>>>>>>> wi
>>>>>>>> LCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Q%2FSgGmCtGEbBiJV2ah9n2IAsdF
>>>>>>>> aa
>>>>>>>> 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%2Fmess
>>>>>>>> ag
>>>>>>>> es
>>>>>>>> .c
>>>>>>>> %23L175&data=05%7C02%7Cmikael.petterson%40ericsson.com%7C2e154
>>>>>>>> 09
>>>>>>>> 25
>>>>>>>> 32
>>>>>>>> e4b0f804308dccc035f05%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7
>>>>>>>> C0
>>>>>>>> %7
>>>>>>>> C6
>>>>>>>> 38609562056380910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
>>>>>>>> LC
>>>>>>>> JQ
>>>>>>>> Ij
>>>>>>>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=71
>>>>>>>> nn
>>>>>>>> DT
>>>>>>>> 4y
>>>>>>>> jtVA0tkfjqrViDjTKFyhsPwtQibVIJFzhr8%3D&reserved=0
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> But could not see any support for unknown.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Maybe I am looking in the wrong place.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Br.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> //mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>