How netopeer2 triggers the sending of SSH_MSG_GLOBAL_REQUEST ?

[satomhxl]

Hello, in this issue: https://github.com/CESNET/Netopeer2/issues/563 Some output is posted

[2020/02/27 09:15:14.115625, 2] ssh_packet_global_request:  Received SSH_MSG_GLOBAL_REQUEST packet
[2020/02/27 09:15:14.115687, 2] ssh_packet_global_request:  Received keepalive@openssh.com 1
[2020/02/27 09:15:16.118159, 2] ssh_packet_global_request:  Received SSH_MSG_GLOBAL_REQUEST packet
[2020/02/27 09:15:16.118213, 2] ssh_packet_global_request:  Received keepalive@openssh.com 1
[2020/02/27 09:15:18.120703, 2] ssh_packet_global_request:  Received SSH_MSG_GLOBAL_REQUEST packet
[2020/02/27 09:15:18.120757, 2] ssh_packet_global_request:  Received keepalive@openssh.com 1
[2020/02/27 09:15:20.123172, 2] ssh_packet_global_request:  Received SSH_MSG_GLOBAL_REQUEST packet
[2020/02/27 09:15:20.123234, 2] ssh_packet_global_request:  Received keepalive@openssh.com 1

I'd like to know where is function ssh_packet_global_request called? I looked through the code but couldn't find it.

Thank you very much!

[michalvasko]

The server is only receiving the requests, it is not sending any. The reply is sent automatically by libssh.

[satomhxl]

OK, so whether in call-home mode or listen mode, the SSH_MSG_GLOBAL_REQUEST is sent by netconf client. And is there any API in netopeer2 to configure this keep-alive mechanism, or is this completely determined by libssh?

[satomhxl]

And in ssh_callhome.xml, what does the following data do?

<keepalives>
  <idle-time>1</idle-time>
  <max-probes>10</max-probes>
  <probe-interval>5</probe-interval>
</keepalives>

I guess these data will trigger the nc_sock_enable_keepalive function to be executed, and influence the sending of SSH_MSG_GLOBAL_REQUEST, right?

[michalvasko]

There are 2 keepalive mechanisms in the (server) YANG modules, on TCP-level and on transport layer (SSH/TLS), only the former is supported. So, the configuration you posted configures the TCP keepalive.

The SSH global requests are being sent by a client and the server responds because that is how libssh behaves by default. Our netopeer2-cli does not support any keepalive mechanisms.

[satomhxl]

Got it, your answer is very clear, thank you very much.

[satomhxl]

Hello, just to confirm that, in Section 4.1 of RFC 8071, it says

S7  If a persistent connection is desired, the NETCONF/RESTCONF
       server, as the connection initiator, SHOULD actively test the
       aliveness of the connection using a keep-alive mechanism.  For
       TLS-based connections, the NETCONF/RESTCONF server SHOULD send
       HeartbeatRequest messages, as defined by [[RFC6520](https://www.rfc-editor.org/rfc/rfc6520)].  For SSH-
       based connections, per [Section 4 of [RFC4254]](https://www.rfc-editor.org/rfc/rfc4254#section-4), the server SHOULD
       send an SSH_MSG_GLOBAL_REQUEST message with a purposely
       nonexistent "request name" value (e.g., keepalive@ietf.org) and
       the "want reply" value set to '1'.

But in netopeer2-server, it does not actively send SSH_MSG_GLOBAL_REQUEST message to keep SSH connection alive, so it does not comply with the requirements above, right?

[michalvasko]

Whether it sends those messages or not, it always complies because they only should be sent. Also, instead of each of these mechanisms, TCP-based keep-alive is sent. Once libssh supports sending such messages (in API), it can be added to libnetconf2.

[satomhxl]

OK, so this is my understanding:

1. NETCONF clients implemented using libssh can send SSH_MSG_GLOBAL_REQUEST to the netconf server, to achieve SSH-based keep-alive. But in netopeer2-cli, this is not considered.
2. In Section 4.1 of RFC 8071, a suggestion is made to let the netconf server initiate keep-alive messages towards netconf client. However, the libssh/openssl library used by libnetconf2 does not provide needed API, so TCP-based keepalive mechanism is used to achieve the same effect.

Correct me if I'm wrong, thank you.

[michalvasko]

Pretty accurate. Just a note that the current configuration YANG modules define both SSH/TLS and TCP-layer keep-alives so you could also configure both or none. We simply do not support SSH nor TLS keep-alives.