How is a keep-alive handled when sent to libssh server.

[Mikael Petterson <mikael.petterson@xxxxxxxxxxxx>]

Hi,

We are using trilead-ssh2 SSH library.

It uses the following:

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();

to send a keep-alive.

We use libssh together with netopeer2 & libnetconf2 and when we send this kind of message we only get a time-out ( server is up and running).

We checked

RFC 4254 - The Secure Shell (SSH) Connection Protocol (ietf.org)<https://datatracker.ietf.org/doc/html/rfc4254#section-4>

see text snippet below.

And it should be ok to send what trilead ssh2 sends.

So trilead ssh2 expects  a reply but now our request only times out instead of
Replying any of


SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is

   TRUE.

Why is this so?

Br,

//mikael


“4<https://datatracker.ietf.org/doc/html/rfc4254#section-4>.  Global Requests



   There are several kinds of requests that affect the state of the

   remote end globally, independent of any channels.  An example is a

   request to start TCP/IP forwarding for a specific port.  Note that

   both the client and server MAY send global requests at any time, and

   the receiver MUST respond appropriately.  All such requests use the

   following format.



      byte      SSH_MSG_GLOBAL_REQUEST

      string    request name in US-ASCII only

      boolean   want reply

      ....      request-specific data follows



   The value of 'request name' follows the DNS extensibility naming

   convention outlined in [SSH-ARCH<https://datatracker.ietf.org/doc/html/rfc4254#ref-SSH-ARCH>].



   The recipient will respond to this message with

   SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is

   TRUE.



      byte      SSH_MSG_REQUEST_SUCCESS

      ....     response specific data



   Usually, the 'response specific data' is non-existent.



   If the recipient does not recognize or support the request, it simply

   responds with SSH_MSG_REQUEST_FAILURE.



      byte      SSH_MSG_REQUEST_FAILURE



   In general, the reply messages do not include request type

   identifiers.  To make it possible for the originator of a request to

   identify to which request each reply refers, it is REQUIRED that

   replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as

   the corresponding request messages.  For channel requests, replies

   that relate to the same channel MUST also be replied to in the right

   order.  However, channel requests for distinct channels MAY be

   replied to out-of-order.”