Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Jakub Jelen <jjelen@xxxxxxxxxx>]

Thank you for the information. So it should be up to date.

My tests seems to work ok in [1] so we need to figure out what is the
difference between your code and my test.

> 2024-09-02 11:46:31,297 (Slf4jLogConsumer.java:73)  INFO : STDERR: [2024/09/02 09:46:31.284447, 3] ssh_message_reply_default:  Don't know what to default reply to 67108912 type
> I assume ssh_message_reply_default()  is part of libssh.

Correct, this is part of libssh and looks like the message type was
not correctly set. Can you provide the server TRACE (log level 4) logs
processing this message -- there should be much more than this one?
There should be more messages when the packet is received and
processed which should give us an idea about the code path that is
being taken and why.

[1] https://gitlab.com/libssh/libssh-mirror/-/merge_requests/533

Jakub

On Tue, Sep 3, 2024 at 1:33 PM Mikael Petterson
<mikael.petterson@xxxxxxxxxxxx> wrote:
>
> Hi,
>
> Thanks for the workaround suggestion but I  cannot use workaround since trilead ssh2 public method uses  SSH_MSG_CHANNEL_REQUEST.
> Changing it to SSH_MSG_CHANNEL_REQUEST could most likely be backwards incompatible. Maybe something for consideration for trilead ssh2.
>
> Thx
>
> //mike
>
>
>
> I think changing to use
>
> -----Original Message-----
> From: Mikael Petterson <mikael.petterson@xxxxxxxxxxxx>
> Sent: Tuesday, 3 September 2024 12:42
> To: libssh@xxxxxxxxxx
> Subject: RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknown
>
> Hi Jakub,
>
> I am using: libssh-0.11.0
>
> Br,
>
> //mike
>
> -----Original Message-----
> From: Jakub Jelen <jjelen@xxxxxxxxxx>
> Sent: Tuesday, 3 September 2024 12:29
> To: libssh@xxxxxxxxxx
> Subject: Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown
>
> I actually wrote a test for this but it looks like the master version returns me correctly the expected messages:
>
> https://gitlab.com/jjelen/libssh-mirror/-/commits/channel-request
>
> What is the  libssh version you are using?
>
> Jakub
>
> On Tue, Sep 3, 2024 at 11:08 AM Jakub Jelen <jjelen@xxxxxxxxxx> wrote:
> >
> > Hello.
> >
> > Thank you for your clarification. Indeed, you are right and the
> > response to this message should be send. I will open a MR and try to
> > fix that.
> >
> > I thought that all the implementations used the global requests, but
> > clearly its not the case.
> >
> > So one possible workaround if you do not want to wait for new libssh
> > release would be to use the global requests instead of the channel
> > request, which should already implement replies to unknown messages.
> >
> > Jakub
> >
> > On Mon, Sep 2, 2024 at 1:48 PM Mikael Petterson
> > <mikael.petterson@xxxxxxxxxxxx> wrote:
> > >
> > > Hi again,
> > >
> > >
> > >
> > > Thanks Jakub for your reply. I need to make some corrections in this message.
> > >
> > >
> > >
> > > We are using libnetconf2 that uses libssh.
> > >
> > >
> > >
> > > The trilead ssh2 java client we use has a ping method that uses this:
> > >
> > > public byte[] getPayload()
> > >
> > >                 {
> > >
> > >                                 if (payload == null)
> > >
> > >                                 {
> > >
> > >                                                 TypesWriter tw = new
> > > TypesWriter();
> > >
> > >
> > > tw.writeByte(Packets.SSH_MSG_CHANNEL_REQUEST);
> > >
> > >
> > > tw.writeUINT32(recipientChannelID);
> > >
> > >
> > > tw.writeString("trilead-ping");
> > >
> > >
> > > tw.writeBoolean(true);
> > >
> > >                                                 payload =
> > > tw.getBytes();
> > >
> > >                                 }
> > >
> > >                                 return payload;
> > >
> > >                 }
> > >
> > > }
> > >
> > > So I need to correct myself. It is a SSH_MSG_CHANNEL_REQUEST that is sent as ping and nothing else.
> > >
> > >
> > >
> > > I checked the logs when enabling ssh logging.
> > >
> > >
> > >
> > >
> > >
> > > 2024-09-02 11:46:31,297 (Slf4jLogConsumer.java:73)  INFO : STDERR: [INF]: LN: Session 2: Received an SSH message "request-channel" of subtype "unknown".
> > >
> > > 2024-09-02 11:46:31,297 (Slf4jLogConsumer.java:73)  INFO : STDERR:
> > > [2024/09/02 09:46:31.284447, 3] ssh_message_reply_default:  Don't
> > > know what to default reply to 67108912 type
> > >
> > >
> > >
> > >
> > >
> > > I assume ssh_message_reply_default()  is part of libssh.
> > >
> > > I checked the RFC
> > > https://ww/
> > > w.rfc-editor.org%2Frfc%2Frfc4254.html%23section-5&data=05%7C02%7Cmik
> > > ael.petterson%40ericsson.com%7C2e154092532e4b0f804308dccc035f05%7C92
> > > e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638609562056373731%7CUnknow
> > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> > > LCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Q%2FSgGmCtGEbBiJV2ah9n2IAsdFaaCNXW
> > > 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%7C2e154092532
> > > e4b0f804308dccc035f05%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C6
> > > 38609562056380910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=71nnDT4y
> > > jtVA0tkfjqrViDjTKFyhsPwtQibVIJFzhr8%3D&reserved=0
> > >
> > >
> > >
> > > But could not see any support for unknown.
> > >
> > >
> > >
> > > Maybe I am looking in the wrong place.
> > >
> > >
> > >
> > > Br.
> > >
> > >
> > >
> > > //mike
> > >
> > >
> > >
>
>