Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Jakub Jelen <jjelen@xxxxxxxxxx>]

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
> > > >
> > > >
> > > >
> >
> >
>
>