ECDSA fails to negotiate authentication method / Key Manager reports wrong key size/type

Running build 3878 on Win 10

SFTP connect fails using ecdsa-sha2-nistp521 (and probably other FIPS)
Furthermore FlashFXP reports the key size as 512 bits (instead of 521) and the type as DSA (instead if ECDSA)

Will the later is only cosmetic the first one is a real show stopper, since FlashFXP isn't connecting at all.

Reproduce (assumes Server is setup, authorized_keys added/working):
1. Import ecdsa-sha2-nistp521 private key into the key manager (needs to be in openssh/old format, new, ssh.com and PuTTY format doesn't seem to work)
2. Change auth method to key based and select the imported private key
3. Save and connect

Does FlashFXP even support ECDSA yet?
imho OpenSSL 1.0.2d can handle it

I have confirmed there appears to be several issues related to ECDSA key pairs.

I am currently investigating these issues and I will reply back once I know more.

Please try this update and let me know if it resolves the problem

FlashFXP52_3880_Setup.exe

You will need to re-import the ECDSA key to have it show up correctly and not as DSA.

Working
Key Type and Size now also get properly reported

Just for the record
_If_ you import your public key the connection will immediately fail after being established:

[10:30:49] [R] Connecting to sub.domain.com -> DNS=sub.domain.com IP=123.123.123.123 PORT=22
[10:30:49] [R] Connected to sub.domain.com
[10:30:49] [R] Connection failed
[10:30:49] [R] Delaying for 10 seconds before reconnect attempt #1

As long as you only import the private key you are good.

Thanks for the quick fix
Regards
Cheers

Thats Great!

Thank you for confirming the fix.

The problem was an internal error check (within SBB) that aborted loading the ECDSA private key data so the key data was incomplete.

Originally Posted by rodney.hjoern

_If_ you import your public key the connection will immediately fail after being established:

As long as you only import the private key you are good.

I am not sure why or how this could be related, unless there is some other underlying issue (memory corruption, overrun, error) importing this specific public key?

When connecting to a SFTP server that uses Public Key authentication just the Private Key is loaded. In fact the public key is is not needed by the client at all, we just provide a way for the user to enter it so that they have a way to keep the Public/Private key pair stored all in one place.

I tried countless times to reproduce this and I have not been able to, perhaps you could test with a few other key pairs to help me narrow down the problem, or if its just a one time thing.

When importing are you setting a password and/or enabling strong private key protection?

That's why i am curious why its not working, since it doesn't really make any sense at all

I tried it with a RSA EC2 key pair (in PuTTY format) and here it is working with the public key imported.

Since i cannot import my ECDSA key in PuTTY format, the Key Manager errors with a "Invalid Algorithm" message, and have to use OpenSSH this might be related to the key format used?

Originally Posted by rodney.hjoern

Since i cannot import my ECDSA key in PuTTY format, the Key Manager errors with a "Invalid Algorithm" message, and have to use OpenSSH this might be related to the key format used?

Only the OpenSSH key format supports loading EC keys.

PuTTY just recently updated their PPK format to support ECDSA and it's still only available in the latest dev release. It will take some time for these changes to filter down to the SecureBlackBox library we use for key management.

I know
I am already using the GDI fork

Anyway
Thanks for the quick help
Have a nice weekend