SSH Agent: Make adding keys on database unlock asynchronous

[hifi]

If for some reason a database has ssh keys with slow decryption times or a lot of keys the UI will hang until they are decrypted and sent to agent.

Create a worker thread on unlock signal handler with encrypted keys that will handle decryption and insertion to added keys map.

[hr3x8]

I second this. It would be a great feature. I do have a lot of ed25519 keys for various purposes and each takes about ~7-10sec to add. For now I've disabled most of the keys with exception of one frequently used one and for that one I've disabled removing from agent as to not have to wait to unlock the database for key to be added back.

Async key add to have database open immediately yet adding keys to ssh agent be queued in background would be amazing!! I do foresee some design concerns over what happens with (long) async process in event database is locked, changed, saved, or keepassxc quit. For this I would suggest a global setting/warning in which even all keys will be removed from the agent (ssh-add -D).

[TJuberg]

I just started using keepassxc to manage my SSH keys and I immediately encountered this.

On the one hand the added convenience and security of being able to add and remove keys on lock/unlock is very nice, but the penalty of having to wait several seconds to be able to access passwords is inconvenient.

Probably a bit off topic for this request, but I am also uncertain why it would take so long to add the SSH keys to the agent to cause this delay. The database itself clearly is decrypted fast enough to not impact speed as evident by not having it add keys to agent, and adding keys to the ssh-agent using traditional means does not carry the same speed penalty as keepassxc seems to incur.

Async for adding keys would be nice to work around this, but I still cant help but wonder if there is something more fundamental causing the root issue (putting aside my clear ignorance of the internal workings of keepassxc and it's interaction with the ssh-agent)

[droidmonkey]

The same slow key in the database is NOT slow outside the database?

Quite frankly you should be storing your private keys in KeePassXC as unencrypted or lightly encrypted (low kdf) since the database itself is providing the protection to the keys. Once the key is added to the ssh-agent, how long it took to decrypt it is nor relevant at all.

[hifi]

The user story for this issue is having keys outside the database with encryption and many KDF rounds making them slow to decrypt in the first place.

As @droidmonkey said if you store the key inside your database you should have it already decrypted as double encrypting it adds no value.

The other extreme case would be to have tens or hundreds of keys where the agent communication just becomes a bottleneck.

[TJuberg]

For my testing I am using 5 relatively fast keys (100 rounds ed25519), but the best measurement I can make is that keepassxc takes approx twice the amount of time to unlock and add the keys to the ssh-agent as a normal ssh-add does.

From what I can tell, having the keys stored in keepassxc vs having them on file makes little difference (about 1 extra second if keys are stored on file vs having them stored in keepassxc)

I accept that storing unencrypted keys probably is better, but unfortunately not always a viable option as some of the keys needs to also be used in isolated environments where keepassxc cannot be run and the passphrase manually entered. But thats a whole different story.

I apologise if I added noise to the user story as it was not my intention, and I fully hope async key add makes it into keepassxc as it would greatly enhance the user experience and versatility in the ssh-agent/ssh-key usecases.