no matching key exchange method found

[ChrisL16]

On more recent versions of BIGIP, the Key Exchange Algorithms when acting as a SFTP client have been reduced resulting in smaller probability of matching Key Exchange algorithms on remote SSH/SFTP servers.

See: https://support.f5.com/csp/article/K09353251

As a workaround I have replaced line 206 in f5.automated_backup.v3.1.10.tmpl.tcl with the following line: exec echo -e "scp_function()\n{\n\tf5masterkey=\$(f5mku -K)\n\tusername=\$(echo \"ENCRYPTEDUSERNAME\" | openssl aes-256-ecb -salt -a -A -d -k \${f5masterkey})\n\tserver=\$(echo \"ENCRYPTEDSERVER\" | openssl aes-256-ecb -salt -a -A -d -k \${f5masterkey})\n\tdirectory=\$(echo \"ENCRYPTEDDIRECTORY\" | openssl aes-256-ecb -salt -a -A -d -k \${f5masterkey})\n\techo \"ENCRYPTEDPRIVATEKEY\" | openssl aes-256-ecb -salt -a -A -d -k \${f5masterkey} > /var/tmp/TMSHAPPNAME_scp.key\n\n\tchmod 600 /var/tmp/TMSHAPPNAME_scp.key\n\tscp -i /var/tmp/TMSHAPPNAME_scp.key SCPCIPHER SCPSTRICTHOSTKEYCHECKING -o KexAlgorithms=diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 BACKUPDIRECTORY/${fname_noext}BACKUPFILENAMEEXTENSION_WITHDOT* \${username}@\${server}:\${directory} 2>> /var/tmp/scriptd.out\n\tscp_result=\$?\n\trm -f /var/tmp/TMSHAPPNAME_scp.key\n\treturn \$scp_result\n}\n\nscp_function" > $scriptfile

This solution is tested in bigip version 15.1.2. Would it be possible to add an option for "-o KexAlgorithms" to the iApp?

br Christoph

[tabernarious]

Just to be sure, changing the cipher does not help?

I'll take a look. This should not be too hard to implement as an option.

[ChrisL16]

Unfortunately, changing the cipher does not help. The issue is related to "-o KexAlgorithms".

[ChrisL16]

are there any news on that? do you need more information?

[tabernarious]

@chrislan16 , I believe this is working. Please try v3.2.2 which is available in the branch sftp_KexAlgorithms:

https://github.com/tabernarious/f5-automated-backup-iapp/tree/sftp_KexAlgorithms

Let me know if the instructions are clear enough.

[tabernarious]

32 merged into main branch

[ChrisL16]

sorry for my late response. I did a test today and I get following error when I try to create a newbackup shedule:

script did not successfully complete: (can't read "::destination_parameters__sftp_sshprivatekey": no such variable
while executing
"exec echo "$::destination_parameters__sftp_sshprivatekey" | sed -e "s/BEGIN RSA PRIVATE KEY/BEGIN;RSA;PRIVATE;KEY/g" -e "s/END RSA PRIVATE KEY/END;RSA..."
invoked from within
"if { $freq != "Disable" } {
# Ensure a default $filename_format is set
if { $::destination_parameters__filenam..." line:48)

any ideas what's going wrong?

[tabernarious]

@chrislan16 , Please try v3.2.3. I found a typo in the code related to adding support for keys with "BEGIN OPENSSH PRIVATE KEY" headers.

[ChrisL16]

Now I can create a new backup shedule, but it seems the additional SSH options are not in use. I use '-o KexAlgorithms=diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1' (without quotes) but see following line in script.out log: no matching key exchange method found: client ecdh-sha2-nistp256,ecdh-sha2-nistp384,ext-info-c server curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

[ChrisL16]

are there any news on this?

[tabernarious]

@chrislan16 , Sorry for the very delayed response. I switched jobs and am no longer working with F5 tech. But, I did figure out what was wrong. I was incorrectly inserting the SCPSSHOPTIONS string into the script (it was correct for SFTP but not SCP). Look in the 'test' branch for v3.2.4 which should have the fix. Let me know if that works.

[tabernarious]

This should be fixed now in v3.2.4. I'll close this issue if I don't hear from you in the next week or two.

[ChrisL16]

@tabernarious, Sorry for the very delayed response. I have successfully tested v3.2.4. Thank you for help!

[tabernarious]

@chrislan16 , You're so welcome. I'm glad it's finally working!