Repository navigation
ssh agent - "Key identity ownership conflict. Refusing to add." #5895
Description
Overview
I have two databases. I recently added new ssh keys (all ED25519) to them. Two ssh keys to one database and one to the other. Today I realized that some of my ssh keys were not being removed from the ssh-agent on Linux when the database is closed, as I went to login and the ssh key was present in the ssh-agent but all databases were closed in KeepassXC.
I used ssh-add -D to remove all keys from the ssh-agent. I then unlocked the databases but only the three new ssh keys from the two database were added to ssh-agent. None of the other ssh keys that should have been added from KeepassXC were added.
Note: All keys that have this issue have the following three check-boxes checked:
[x] Add key to agent when database is opened/unlocked
[x] Remove key from agent when database is closed/locked
[x] Require user confirmation when key is used
When using the right-click menu or the Ctrl + H shortcut key the ssh keys with this issue ares not added and no error message is displayed.
When the ssh key database entry is opened and one goes to the SSH Agent section. If one then uses the Add to agent button the ssh key is not added and the error message: "Key identity ownership conflict. Refusing to add." is displayed at the top in a red banner.
Steps to Reproduce
NOTE: I am not totally certain of the step to reproduce. This happened over time and I am trying to remember all the things that I did in case they are meaning full to this issue
- Create multiple ssh key entries using RSA keys in two open database.
- Clone the RSA ssh key entries without their history and replace the ssh keys with new ED25519 keys
- Clone other password entries without history and turn them into ED25519 ssh key entries
- Close the databases and see if all KeepassXC ssh keys are removed.
- If not remove them using the command line
ssh-add -Don Linux. - Open the database and see if all KeepassXC ssh keys are added to the agent.
Expected Behavior
Keys that are marked to be added when a database is opened or unlocked should added and keys that are marked to be removed when the database is closed or locked should be removed.
Actual Behavior
Keys that are marked to be added when a database is opened or unlocked are not all added and keys that are marked to be removed when the database is closed or locked are not all removed.
Context
I have checked the UUIDs on the old and the cloned entries and they appear to have different UUIDs.
-
This appears to be related to work on issue SSH agent keys get removed even when other databases are closed #4532 and the code to close that issue was committed in pull request SSH Agent: Track which database owns a key for remove-on-lock #4545.
-
The code that creates the error message in the red banner is in this line of code.
-
It appears that this code is checking for the UUID in the database but does not find it so it refuses to add the ssh key.
-
I am also noticing that when I open an entry to edit it I am experiencing a longer wait time than previously, before the edit window displays.
-
I am also guessing that the same issue that does not allow the ssh keys in KeepassXC to be added is also causing them to not be removed as well.
KeePassXC - Version 2.6.2
Revision: e9b9582
Qt 5.5.1
Debugging mode is disabled.
Operating system: Ubuntu 16.04.7 LTS
CPU architecture: x86_64
Kernel: linux 4.4.0-119-generic
Enabled extensions:
- Auto-Type
- Browser Integration
- SSH Agent
- KeeShare (signed and unsigned sharing)
- YubiKey
- Secret Service Integration
Cryptographic libraries:
libgcrypt 1.8.1
Operating System: Linux
Desktop Env: Unity
Windowing System: X11
Activity
[-]ssh agent - Key identity ownership conflict. Refusing to add.[/-][+]ssh agent - "Key identity ownership conflict. Refusing to add."[/+]hifi commentedon Jan 6, 2021
This should only happen if you have the same key in two different databases that are opened simultaneously. Have you checked that all of the keys you have are unique? The fact that you mentioned cloning do suggest that it's possible you have the same key in both.
The slowness of opening the entry edit should also happen only if your key is heavily encrypted and it takes a while to decrypt as it's not offloaded to a thread. If not, something else is going on.
frederickjh commentedon Jan 7, 2021
@hifi I double checked and all the keys are unique. KeepassXC refusing to add a key to the agent was also happening when I had only one database open.
Not sure what happened but I was having this issue. After your reply I tried to see what possible cause I could locate. I created a new test database and tested several scenarios. As I was doing a save in the test database KeepassXC locked up, turned grey and never responded after that. Tried the termination signal several times with out a response then finally send the kill signal. Not sure that has ever happened before with KeepassXC.
In any case after restarting KeepassXC, now no matter what databases I have open the SSH keys that are set to load on open /unlock and remove on close/ lock work correctly. Previously to the restart, I had tried closing all database and reopening them, but it looks like the restart of KeepassXC was what solved it. Load times when editing entries are also back to normal open times.
You can close this or leave it open if you think others might also have this issue in the future. Not sure if there is anything more that can be done to pin this down or if it was a one-off bug.
frederickjh commentedon Jan 7, 2021
It might be a good idea to add this information to the error message that is displayed.
PolyMMA commentedon Jan 19, 2021
I just experienced the same thing as described above.
ssh-add -Lshowed no loaded key. No freeze though.After locking, and restarting the software, it worked like a charm.
frederickjh commentedon Jan 19, 2021
This has happened to me again too. What I see is that the keys are not removed from the agent and then KeepassXC refuses to add them. Even if one removes them from the
ssh-agentoutside KeepassXC usingssh-add -D. Interestingly no warning messages are shown when unlocking or locking a dadabase if ssh keys cannot be added or removed. This is only shown in the edit screen when using the buttons there to add or remove a ssh key. Maybe warnings should be shown when locking or unlocking a database if there is a failure.Not sure if this is happening when the computer goes to sleep, but I will realize that the keys are in the
ssh-agentafter I come back to the computer and KeepassXC has no open or unlocked databases. At that point to get KeepassXC adding and removing ssh keys to the agent, I dossh-add -Dto remove the keys and close and restart KeepassXC. I will endevour to figure out when the keys are getting left in thessh-agentto see if i can find a set of step that will duplicate this.PolyMMA commentedon Jan 20, 2021
After some more testing I can also confirm that there is an issue with handling the SSH keys after suspending and waking the system. Upon waking the system, running "Add key to SSH agent" (or via Ctrl+H) did not load the key to SSH-agent and was not visible using
ssh-add -L. Restarting the program and unlocking again solved the issue like before and SSH-key was loaded to the agent.[Edited, added 2021-01-21]
Also, when the DB is locked manually, the key in SSH agent is not cleared. Tried this after reboot without any system suspending. Though the system did lock after some time of inactivity.
[Edited, added 2021-01-21]
Just realized that I have the gnome-keyring-deamon running and that might be the cause of the issues. Will investigate more. KeePassXC>Settings>Secret Service Integration gives the following error:
inxi output:
tviard75 commentedon Feb 9, 2021
I can also confirm the issue. Downgraded to 2.6.0 and it works as expected.
hifi commentedon Feb 21, 2021
2.6.4 should have this fixed. Does anyone with this issue still have it with 2.6.4?
frederickjh commentedon Feb 22, 2021
@hifi I just tested on my computer.
Fresh start of computer
started KeePassXC
Checked the ssh agent to see what keys were loaded, none.
Logged into one database on KeePassXC
Checked the ssh agent to see what keys were loaded, keys set to auto load were loaded.
Put computer into suspend
Brought computer out of suspend
Checked the ssh agent to see what keys were loaded, keys set to auto load were still loaded.
Switched to KeePassXC window and was surprised to see that the database was still unlocked!
I checked my setting and found that Lock databases when session is locked or lid is closed is checked.
I then locked the database.
All the auto remove keys were removed from the ssh-agent.
Unlocked the database and all the auto-add keys were added to the ssh-agent.
So, I think that while this issue maybe solved a new issue may have been created of the databases not locking when the computer goes into suspend. I need to check the issue queue to see if there is an issue open regarding this. However, for me these results are not conclusive as KeePassXC did not lock the databases on suspend so it is hard to tell if just locking the database manually has the same effect.
frederickjh commentedon Feb 22, 2021
@hifi I did not find another issue regarding the databases not locking on suspend. Should I open a new issue regarding this?
droidmonkey commentedon Feb 22, 2021
My database locks just fine on suapend, we didn't touch that code. For this purpose you can just lock the databases using the toolbar button. There is no functional difference.
tviard75 commentedon Mar 5, 2021
I just tried with 2.6.4 on Linux Ubuntu 20.04.2 LTS.
So this issue is fixed for me.
Also locking session, locks also keypass db for me.
Cheers,
Thomas
frederickjh commentedon Mar 5, 2021
I am going to close this as the issue at hand has been fixed. The databases not locking may have been an issue with the windows manager I am running as it does not seem to be happening any more.
ioistired commentedon Sep 8, 2021
I am still experiencing this in v2.6.6.
dkebler commentedon Apr 28, 2024
Sorry to necro this closed issue but was experiencing the same here in 2024 and google search took me here.
What I have discovered is that a key with encoding
ecdsa-sha2-nistp521has this issue but notssh-ed25519so maybe this issue is related to the key encryption.mateuszdrab commentedon Jul 2, 2026
Still seeing it in version 2.7.12. Usually solved after restarting keepassxc.
cblanken commentedon Jul 17, 2026
Just confirming I am also still seeing this in KeepassXC 2.7.12 like mateuszdrab.
Clearing the agent via KeepassXC or directly with
ssh-add -Ddoesn't resolve it. The same error remained after locking the database and re-opening it. Exiting and re-launching the KeepassXC application was the only solution I found.underclockeddev commentedon Sep 25, 2026
I had the same issue, here's a proposed fix #13705