Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Jakub Jelen <jjelen@xxxxxxxxxx>]

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://www.rfc-editor.org/rfc/rfc4254.html#section-5
> >
> >
> >
> >
> >
> >
> >
> > 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://github.com/libssh/libssh-mirror/blob/master/src/messages.c#L175
> >
> >
> >
> > But could not see any support for unknown.
> >
> >
> >
> > Maybe I am looking in the wrong place.
> >
> >
> >
> > Br.
> >
> >
> >
> > //mike
> >
> >
> >