Overview

When using the command line to backup configuration files, one of the possible ways to do it is to use SCP (Secure Copy) to backup configuration files in either binary or text format to a remote host. SCP is based on the SSH (Secure Shell) protocol; the most common Client used is OpenSSH, an open source Client implemented on major Linux distributions.

Sometimes, when copying a configuration file using the command configuration upload [filename] scp:// ... ... (or a variation thereof), the Exinda throws back the following echoed lines:

%no kex alg
lost connection

Root Cause

The error no kex alg stands for no key exchange algorithms. This error occurs when the Client and Server in an SCP connection (the Client being the one that initiated the request, in this case, the Exinda) cannot agree on a security suite to generate the security keys that would be used for this transfer.

SSH requires the Client and Server to generate the same security keys using a Cryptographic Protocol to encrypt (and then decrypt) traffic during transmission. To do this, the Client and Server both advertise what Cryptographic Protocols they can use during the handshaking process with the other party, and they negotiate to pick the strongest one they both have in common. If there is no common key exchange algorithm, the communication ends without any further information being exchanged, because they would not be able to generate the same keys.

When this communication ceases because no common key exchange algorithms are found, the error no kex alg is echoed back to the Exinda.

Resolution

At this time, there is no outright resolution for this problem.

It is technically intended behavior and is seen when the backup server has extreme security requirements due to enterprise usage. It is possible that lowering the security requirements on the backup server would alleviate this problem, but is not feasible in a lot of environments.

Workaround

One possible workaround is to initiate a transfer from the opposite side (i.e., have the backup Server initiate the SCP connection and thus make it the Client instead of the server) and pull the configuration file from the Exinda instead of having the Exinda push it out. This is due to the fact that the Server in an exchange such as this always requires more stringent rules for clients accessing it.

For example, the backup server acting as Server requires high-level key exchange protocols, and the Client supports the same protocols but at a lesser key size. The Server won't accept lesser key sizes. However, when switching it around, the new Server (previous Client) advertises its protocols at the lesser key size, and the new Client (previous Server) will be able to agree because it has those as client key exchange algorithms and thus the connection can be made.

This workaround can be performed with the assistance of Exinda Support.