Re: Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Jakub Jelen <jjelen@xxxxxxxxxx>]

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