Underlying SSH2 implementation in netopeer2-server does not support SSH_MSG_GLOBAL_REQUEST according to the SSH standard

[IamPatrik]

Hi,
When trying to use SSH keep-alive on the netopeer2-server, the server replies with SSH2_MSG_UNIMPLEMENTED.

The keep-alive message is normally sent as a SSH_MSG_GLOBAL_REQUEST according to RFC 4254 sect. 4, https://tools.ietf.org/html/rfc4254#section-4 .
According to the RFC, global messages must be replied in case want-reply is set to "true", as stated below:

Note that both the client and server MAY send global requests at any time, and the receiver MUST respond appropriately.

To reproduce the bug, please connect to the server with the following command,

ssh -vvv -p 830 -o ServerAliveInterval=2 -o ServerAliveCountMax=3 root@<host> -s netconf

You will then see the following,

debug3: send packet: type 80
debug3: receive packet: type 3
debug1: Received SSH2_MSG_UNIMPLEMENTED for 12

Netopeer server version:
netopeer2-server 0.7.12
Protocol version and server version according to OpenSSH:
debug1: Remote protocol version 2.0, remote software version libssh_0.7.5

BR
Patrik

[michalvasko]

Hi Patrik,
firstly, you are using an old netopeer2 version which we do not really support anymore. But even if you used the current one, this will not work. The reason and all the details are mentioned in CESNET/libnetconf2#201.

Regards,
Michal

[IamPatrik]

Hi Michal,
thank you for the answer and the linked issue. However, is there a reason, apart for libssh, why you choose not to follow the SSH standard for SSH_MSG_GLOBAL_REQUEST? Not sure if blaming libssh is the correct way to go here...
This will also cause some problems with related client libraries like, apache MINA SSHD, as they will not support anything outside of the standard.
BR
Patrik

[michalvasko]

Hi,

Not sure if blaming libssh is the correct way to go here...

Well, the only other solution would be to add the required functions into libssh ourselves and we are simply not able to do that now. What else would you expect? Also, the same problem is in OpenSSL where the heartbeat functionality is actually disabled on purpose.

Also note that the standard does not strictly require the server to send the keepalives, so the clients should be aware of that. We are sending TCP keep-alives, it is the best we can do.

Regards,
Michal

[IamPatrik]

I think there is a bit of a misunderstanding here. Even if sending keep-alives is optional, it is not optional to support SSH_MSG_GLOBAL_REQUEST. So a client sending periodical SSH_MSG_GLOBAL_REQUESTs should be considered safe, as the server must reply with SSH_MSG_REQUEST_FAILURE, should the request not be supported, which is in itself a sufficient reply.

Now, I only use netopeer2-server for verifiation and because I think this is generally a good product and convenient to start up on a virtual machine. The netconf servers I normally target in production is OpenSSH and dropbear.

I wrote this just to inform you that you was not compliant on SSH, as I thought you wanted to know this. Anyway, do with this information as you want.
BR
Patrik

[michalvasko]

Hi Patrik,
oh, I reread your original problem again and only now understood it properly. I have assumed it is about Call Home keep-alive because there were several similar questions lately, sorry.

Okay, so I have tested it with the current netopeer2-server and libnetconf2 with libssh 0.8.7, this is the server output

[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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 1

and this the ssh(1) output

debug3: send packet: type 80
debug3: receive packet: type 81
debug3: send packet: type 80
debug3: receive packet: type 81
debug3: send packet: type 80
debug3: receive packet: type 81
debug3: send packet: type 80
debug3: receive packet: type 81

so I would say it works fine, right?

Regards,
Michal

[IamPatrik]

Hi,
Yes, based on your answer I consider this problem fixed in a later version of Netopeer2-server. thanks you for the help.

As for the "problem":
It has nothing to do with call-home really. I am replacing the SSH implementation for a NETCONF client, as the current implementation is based on a library no longer being maintained (though I know a guy was working on call-home support some time ago, so it is probably supported).

I am initiating the connection from my end, but I still want the connection to be persistent. In case of restarts, link breaks and other disturbances I need to reinitiate the connection, thus I need fast feedback on when the connection goes down. The default is based on a number of things, such as socket implementions and such, so I need to send keep-alives to make the feedback deterministic.
BR
Patrik