SummaryWhen trying to transfer a config file from the Exinda to a backup server, SCP fails with a 'no kex alg' error.
OverviewWhen 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 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 there of), the Exinda will throw back the echoed lines:
%no kex alg
Cause'no kex alg' is an error that stands for 'no key exchange algorithms'. This is an error that 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, this error is echoed back to the Exinda.
WorkaroundOne workaround that is possible is to initiate transfer from the opposite side (ie, 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. But when switching it around, the new Server (previous Client) will advertise 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 done with the assistance of Exinda TAC.
ResolutionAt this time, there is no outright resolution for this problem.
It is technically intended behaviour, 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.