Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Michal Vasko <mvasko@xxxxxxxxx>]

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://github.com/CESNET/libnetconf2/blob/47ca0fb5f94588d112ec2bf26946948189e1c18d/src/session_server_ssh.c#L1692
>
> 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://github.com/CESNET/libnetconf2/blob/47ca0fb5f94588d112ec2bf26946948189e1c18d/src/session_server.c#L1609
>
> 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%7Cm
> > > > > ik
> > > > > ael.petterson%40ericsson.com%7C2e154092532e4b0f804308dccc035f05%7C
> > > > > 92
> > > > > e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638609562056373731%7CUnkn
> > > > > ow
> > > > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> > > > > wi
> > > > > LCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Q%2FSgGmCtGEbBiJV2ah9n2IAsdFaaCN
> > > > > 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%2Fmessages
> > > > > .c
> > > > > %23L175&data=05%7C02%7Cmikael.petterson%40ericsson.com%7C2e1540925
> > > > > 32
> > > > > e4b0f804308dccc035f05%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7
> > > > > C6
> > > > > 38609562056380910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > > > > Ij
> > > > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=71nnDT
> > > > > 4y
> > > > > jtVA0tkfjqrViDjTKFyhsPwtQibVIJFzhr8%3D&reserved=0
> > > > >
> > > > >
> > > > >
> > > > > But could not see any support for unknown.
> > > > >
> > > > >
> > > > >
> > > > > Maybe I am looking in the wrong place.
> > > > >
> > > > >
> > > > >
> > > > > Br.
> > > > >
> > > > >
> > > > >
> > > > > //mike

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature