RE: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Mikael Petterson <mikael.petterson@xxxxxxxxxxxx>]

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