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

[Jakub Jelen <jjelen@xxxxxxxxxx>]

Hi,
what libssh version do you use on the server? Do you have debug logs
from the server?

This is how the keepalive is implemented by most of the SSH
implementations so I do not see anything wrong with that.

I think this issue was possible before 0.10 release, but should be
fixed in all currently supported libssh versions with this commit:

https://gitlab.com/libssh/libssh-mirror/-/commit/3d7d3f303ed5f79c1df248abf5c8362443faf905

Jakub

On Fri, Aug 30, 2024 at 10:38 AM Mikael Petterson
<mikael.petterson@xxxxxxxxxxxx> wrote:
>
> 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)
>
> 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.  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].
>
>
>
>    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.”