SFTP (SSH2) doesn't support ed25519?

[scott-smith]

I have been using an ecdsa key pair to authenticate my SSH connections from my desktop to my local servers. I was able to SSH into a local server as root via a terminal without any password challenge.

I set up SFTP(SSH2) 'root' user profiles for each of my servers in Beyond Compare (specifying the SSH private key file and a blank password), and that worked great.

Recently I upgraded to a ed25519 key pair, and while I can still SSH via terminal into those same accounts, Beyond Compare no longer connects.

Even though the password field is blank and the correct SSH private key file is specified in the profile, I still get an 'Invalid Login' dialog, and the following in the log window:

01/29/2017 12:28:33 PM Connecting to matrix
01/29/2017 12:28:33 PM Server key [DSS 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx]
01/29/2017 12:28:33 PM No more authentication methods available
01/29/2017 12:28:33 PM Connection closed.
01/29/2017 12:28:33 PM Connection failed: Connection lost (error code is 115)
01/29/2017 12:28:36 PM Unable to load sftp://root@matrix/: Connection lost (error code is 115)

Is this due to a lack of support for ed25519, and if so, is there an update coming that will address this?

Thanks!

--- ADDITIONAL INFO: ---

Beyond Compare 4 64-bit Edition v4.1.9 build 21719 on Debian Jessie

I have OpenSSH 7.4 installed, and I'm running ssh-agent with my X-session. I was using a passphrase along with the ed25519 key initially, but I eventually removed it from the key, thinking that was what was causing the issue with BeyondCompare. I still have no ability to connect with the ed25519 key, even without a passphrase, so ssh-agent is probably not relevant here.

[Aaron]

Hello,

Thanks. We can confirm that ed25519 keys aren't supported by our current library. If there are any other keys set up in ssh-agent or the Profile settings, BC4 will attempt to use them (and prompt for Passphrase if needed), and if none of them work we'll then prompt for Password if that authentication method is available.

Enhancing our key support is something on our radar, but would require the library to update its support or finding another solution.

[rctgamer3]

Are there any plans to make ed25519 keys supported, by upgrading the library sooner, rather than later? (Curious: what library is BC dependant on?)
Every couple of months or so, this article, https://blog.g3rt.nl/upgrade-your-ssh-keys.html , resurfaces on HN and other sites. I would definitely use Beyond Compare more if I could use my ed25519 key pair. Having to use another client or a different key pair is annoying.

[Aaron]

Thanks for the feedback. This isn't a feature we've been able to tackle yet, but this is a great resource link and I'll add it to our wishlist entry on the subject.

[MyXelf]

Ping!

[Chris]

Thanks, ed25519 support is still on the todo list for a future version of Beyond Compare. Releasing a 64-bit Mac version (BC 4.3) and the first few rounds of bug fixes has dominated our development schedule. Once 64-bit Mac settles down we plan to get back to other items on our todo list.

[rctgamer3]

Please prioritise this. OpenSSH v8.2 was released today and further deprecates "ssh-rsa". ED25519 support, as recommended by them still seemingly hasn't been implemented yet in Beyond Compare.

https://www.openssh.com/releasenotes.html#8.2

Future deprecation notice
=========================
It is now possible to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K.
For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release. This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs.

The better alternatives include:

• The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.
• The ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5.
• The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These have been supported by OpenSSH since release 5.7.

[Aaron]

Thanks for that news post. I'll add that info and bump our tracker entry on the subject.

[chrishaas]

I hate to post "me too", but... me too!

We started the process of rolling keys across almost 100 sites last year but didn't realize until very recently that BC didn't support ed25519, so now we're having to go back into those on a case-by-case basis and re-adding our old keys, and in some cases, generating new RSA keys for newer users that only have ever had ed25519 keys deployed. We actually hoped to completely phase-out RSA this year but that plan will need to be put on hold for a bit.

On a related note, it would really help if on the SFTP profile side there would be an option (checkbox or dedicated protocol in dropdown) for "Key-only". None of our servers allow password-based authentication after hardening and the password prompt sometimes trips people up because they aren't sure if they should enter the key's password or their account's password.

[Aaron]

No worries. The feedback is appreciated.

For the SFTP 'key only', we can look into a feature like that. Currently, failed authentications fall through, since the server might still support password authentication even if the key is rejected.

[Len Chisholm]

Another me-too request, please! Having carefully configured a pair of servers with ed25519 certificate-only SSH logins, I tried for some time to connect with BC4 before Googling and finding this thread. I also was confused by the password prompt appearing, which didn't make it clear it was the certificate login which had been rejected and it was offering a fallback option - which leads to the certificate passphrase being sent over the net.

[Chris]

Thanks Len, ed25519 support is still on the todo list.

[615Don]

I also need this feature. Sadly disappointed about it being missing.

[lxocram]

I'd like to bump this issue up. At my workplace we're forced to use ed25519 now. Password fallback is not an option.

[Aaron]

Thanks for the feedback. In the meantime, are you on a system that supports Putty's Pageant that can be used for the key authentication?