Support for SSH_MSG_CHANNEL_REQUEST that is unknown

[Mikael Petterson <mikael.petterson@xxxxxxxxxxxx>]

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<https://www.rfc-editor.org/rfc/rfc4254.html#section-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<https://www.rfc-editor.org/rfc/rfc4254>                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<https://www.rfc-editor.org/rfc/rfc4254.html#ref-SSH-ARCH>] and [SSH-NUMBERS<https://www.rfc-editor.org/rfc/rfc4254.html#ref-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