looks like you mistype the password, I can’t tell anything more 
if you use a file to unlock it in addition to the password, make sure you gave the path
Thanks for the reply
I have reconfirmed that it is not a mistype password and there is no file attached to the database
maybe I can recreate the previous working state which was keepassxc 2.7.6 and try that?
will appreciate newbie guidance
You should open a ticket on keepassxc bug tracker, the issue is unlikely to be related to Qubes OS here, I can’t help you more.
2 Likes
Thanks again
1 Like
Thanks for this hint. I was getting the same errors connecting and was able to make it reliable by increasing the 500 ms message timeout in background/client.js
I still use the old version. This timeout thing, could it reliably be fixed without rebuilding the xpi?
Me Neanderthal, me just have one .kdbx file in offline vault Qube with long main password. Me copy-paste passwords when need from KeePassXC GUI to other qubes. Me do this every time for 3 years. Me reasonably secure monkey because no mistakes this way.
4 Likes
Moved everything on client qubes from netcat to systemd sockets, will update updated the tutorial soon.
1 Like
I have a question. Don’t know if this is the best place for make this question, but here are: This has security advantages if compared to just keep your passwords on a offline qube like vault and just copying them with Qubes global clipboard?
No. But it has usability advantages.
Hello, novice user here. I’ve tried following your instructions unsuccessfully.
Firstly, I think you might have forgotten to add,
[Install]
WantedBy=sockets.target
to remote-keepassxc.socket, otherwise systemctl cannot start it.
Please correct me if I’m wrong here.
What I don’t understand is that ListenStream=/run/user/%U/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer in the remote-keepassxc.socket is pointing to the browser server file of the KeePassXC that is running locally in the client vm. How is it communicating with the browser server of the “vault” vm?
Do I need to run KeePassXC on the client vm?
Thank you for the guide and I hope you can clarify this.
2 Likes
Yes you are right, will update, forgot to copy this line.
It listens there and launches qrexec request to vault once it receives a connection from browser plugin, as defined by socket instanced service.
2 Likes
I haven’t been able to get this to work, and I’m not sure what my mistake is here.
I’m working on the template and I’ve followed your instructions confirming all the links in those files are correct.
I’ve added org.keepassxc.keepassxc_browser.json at /usr/lib64/mozilla,
and remote-keepassxc@.service / remote-keepassxc.socket at /etc/systemd/user
The remote-keepassxc.socket is “Listening on remote-keepassxc.socket - Remote socket to KeePassXC at Vault.”
The Firefox extension is initially giving me the error “Message encryption failed. Is KeePassXC running?”, and after clicking on it a few times it says “Key exchange was not successful”.
Are there any troubleshooting steps you can suggest that can help me figure out what the issue is?
what is in qrexec log? didn’t you forget to create connection policy in dom0? If it is “ask”, does connection request pop up?
I did create the policy in dom0 with ask, but no prompts for connection and the qrexec-policy log is empty.
Then request does not come through, something is wrong in a way your plugin communicates to the backend. What does systemctl status on the client qube tell you? What is in the system journal?
systemctl status qubes-qrexec-agent is running but “some journal files were not opened due to insufficient permissions.”
Edit. I removed the system log because it was too long and distracting.
I was able to run /usr/bin/qrexec-client-vm vault qubes.keepassXC from the command (along with a dom0 notification about the access request).
It seem like the service is not triggered by the socket. I’ll have to circle back to my original question about org.keepassxc.KeePassXC.BrowserServer. This is created when I launch KeePassXC from the client vm and disapears after restart (of the template).
I’m still not sure how this is used for communication with the vault.
Should I be running KeePassXC in the client vm?
No, just the browser plugin. Strange, strange. I think I copied my working setup verbatim. Maybe you do and it causes a conflict, or there is stale socket, or whatever?
I finally figured out what the issue was. I had to manually copy,
/home/user/.mozilla/native-messaging-hosts/ org.keepassxc.keepassxc_browser.json to that location.
I think org.keepassxc.keepassxc_browser.json needs to be in /usr/lib64/mozilla/native-messaging-hosts for template application.
Yep. I believe it could be in ~/.mozilla as well, but maybe I am wrong. I install it template-wide typically.