ssh agent integration doesnt add ed25519 keys

[kniteli]

I'm on Arch Linux with OpenSSH. I'm having no problem getting RSA keys added to ssh-agent correctly, but ed25519 keys silently fail on open, and when I manually click the "add to agent" button it fails to decrypt. If I physically copy paste the key it decrypts, so it's not an issue there.

Expected Behavior

ed25519 key should be added to ssh-agent on opening database

Current Behavior

Keepassxc doesn't add key to ssh-agent, nor does it mention anything about failing to decrypt unless I manually press "add to agent" button. In neither case is the key added to ssh-agent despite the passphrase being correct.

Steps to Reproduce (for bugs)

1. Generate key: ssh-keygen -a 100 -t ed25519
2. Use keepassxc to generate the password, use special characters + extended ASCII
3. Add key and password to database entry with "add to agent on database open" and "remove from agent on database close" checked (no others).

Context

Just trying out modern algos, I'll probably just stick with RSA until this is resolved.

Debug Info

KeePassXC - Version 2.3.3
Revision: 0a155d8

Libraries:

• Qt 5.11.1
• libgcrypt 1.8.3

Operating system: Arch Linux
CPU architecture: x86_64
Kernel: linux 4.17.4-1-ARCH

Enabled extensions:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[kniteli]

Ok, I wanted to try one more thing since typing a password seemed too simple an interface to have a serious bug. My original key used symbols and extended ascii. I created a new key without either of those (just the standard alphanumeric set) and keepassxc now correctly adds the key to ssh-agent, and it appears in ssh-add -l

[droidmonkey]

Good report, definitely a bug there. Does this extended ascii password also break RSA keys?

[kniteli]

RSA keys worked fine with the extended ASCII characters.

[hifi]

Thanks for the report. I will need to take a look where these characters are lost.

[hifi]

@kniteli Could you please test if #2117 fixes your issue? If it doesn't could you please provide a test database that has an embedded RSA and Ed25519 key where decrypting RSA works but Ed25519 doesn't?

Not exactly sure what "extended ASCII" means here. We need to interpret the passphrase in some encoding when convert them into raw bytes and which is used for someone's key depends on the encoding of the terminal they used to type those characters in I suppose. UTF-8 seems like a safer bet than Latin-1, though.