How do I unlock KeePassXC at login?

[droidmonkey]

If you are using Linux your can use secret-tool such as:
secret-tool lookup name keepass | keepassxc --pw-stdin --keyfile /path/to/keyfile /path/to/database.kdbx

[michaelk83]

This solution assumes that the KPXC password is stored in a 3rd party Secret Service keyring such as Gnome-keyring. That's what secret-tool reads. This won't work if KPXC is the Secret Service keyring (via "Enable Secret Service integration" option), since that'll cause a circular dependency: you'd need to unlock KPXC to read the password to unlock KPXC.

In the latter case, you can still use a keyfile without an additional password (I think):
keepassxc --keyfile /path/to/keyfile /path/to/database.kdbx

There was some discussion of implementing a PAM module for this (in issue #6055 and others), but nothing implemented yet. The team's consensus is that using (only) one's login password to unlock KPXC is poor practice.

(Thought this was worth mentioning given that this Q&A is aimed at the end users.)

[62f]

Doesn't exit to prompt in Alpine

Details

```~ # apk search secret-tool libsecret-0.20.5-r0 ~ # apk add libsecret (1/3) Installing libgpg-error (1.45-r0) (2/3) Installing libgcrypt (1.10.1-r0) (3/3) Installing libsecret (0.20.5-r0) Executing busybox-1.35.0-r17.trigger OK: 174 MiB in 127 packages ~ # secret-tool lookup name keepass | ke epassxc --pw-stdin --keyfile /path/to/ke yfile /path/to/database.kdbx secret-tool: Cannot spawn a message bus without a machine-id: Unable to load /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file “/var/lib/dbus/machine-id”: No such file or directory qt.qpa.xcb: could not connect to display qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted ```

[GrabbenD]

@michaelk83 I've arrived at identical conclusions as yours while exploring methods of auto-unlocking secrets database for GIT/ZED/Github Desktop (for future readers, various approaches were discussed here: #6055).

Years later, have you settled at a better solution apart from this flow?

1. KeePassXC used as the Keyring Provider & Password Manager (to avoid introducing extra steps like AutoOpen or secret-tool/libsecret which keeps the implementation minimal).

2. Secrets get auto-unlocked through keyfile using a separate database (to reduce the risk of exposing contents of main database).

3. Login Credentials are held in a dedicated (e.g. password protected) database.

4. dbus-monitor & dbus-send to implement auto-lock functionality like here/example (but this might be futile until Per Database Autolock is supported).

[michaelk83]

I don't unlock my database unless needed, and auto- or manually lock promptly after. The web accounts I use on a daily basis are either kept logged in, or SSO via my Google account. I only need my database for higher-risk accounts, which I don't access all that often.

I don't actually need Secret Service at the moment, since my PC is on ethernet LAN (so no WiFi password), and I don't have anything else on it that would require credentials. But if I did, I'd probably put that in a separate local database, with the same password as my user login. That wouldn't be enough for the higher risk stuff, but should be fine for low risk local apps.

For unlocking on login, there's an experimental PAM implementation now. And you can still to auto-unlock with a keyfile, without a password.

Your trick of using SystemD for this is actually pretty neat. With some adjustments, you could have the unlocker run as root to read a root:root 600 keyfile, yet still launch and unlock KeePassXC as the normal user. That would actually be a useful tool to publish on github. (edit: Ah, I see this is the unlocker from @fertkir that he mentioned below, already published. But it uses Secret Service to store the DB passwords, rather than a root keyfile.)

[sdre15]

If you are using Linux your can use secret-tool such as:
secret-tool lookup name keepass | keepassxc --pw-stdin --keyfile /path/to/keyfile /path/to/database.kdbx

How would you do this for keepassxc-cli. It doesn't look like there's an argument flag for this in the man page .

[droidmonkey]

pipe the password to keepassxc-cli open <db_path>. You might have to include a newline.

[sdre15]

I pipe in the password, however the shell just exists right away and doesn't allow me to input anything into the unlocked database shell.

[droidmonkey]

Sounds more like a problem with how you are launching the shell.

[sdre15]

I type in echo "[PASSWORD]" | keepassxc-cli open --key-file "[KEYFILE PATH]" [DATABASE_PATH]

Output:
Passwords>%
[Exits immediately]
$

[droidmonkey]

Interesting, will have to look into that

[fertkir]

I've created a script which unlocks KeePassXC at login using password from keyring:
https://github.com/fertkir/linux-utils/tree/main/keepassxc-unlocker

[fertkir]

@droidmonkey, correct me if I'm wrong, but you're equally vulnerable if you use Gnome keyring, for example, to store your ssh key password. If you have Gnome keyring unlocked on login, any program can get passwords from it.

[droidmonkey]

Yes that is exactly correct. We offer an alternative to gnome keyring (that is the secret service api) which also allows for user confirmation before granting access and you can lock your database in between uses.

[michaelk83]

We offer an alternative to gnome keyring (that is the secret service api) which also allows for user confirmation before granting access

Except, you can't use it to retrieve the passphrase to auto-unlock the very database where that passphrase is stored (as I noted earlier). You could put that passphrase in a separate database, but then you may as well just use the AutoOpen feature, and you'd still need to unlock that separate database first, somehow.

Back to Gnome keyring, you could somewhat reduce the vulnerability by having it auto-lock after a while (if they support that), but that rather defeats the purpose of the auto-unlock, at least for some use cases. Still could be useful for the initial logins during startup, or to initialize QuickUnlock, once that is implemented on Linux.

[droidmonkey]

Except, you can't use it to retrieve the passphrase to auto-unlock the very database where that passphrase is stored (as I noted earlier).

I wasn't suggesting to do that

[michaelk83]

Also, you can't run Gnome keyring and KeePassXC' Secret Service integration at the same time. So if you want to use Gnome keyring to auto-unlock KeePassXC, then you can't use KeePassXC' Secret Service integration; and vice versa.

[Kyr4l]

If you are using Linux your can use secret-tool such as: secret-tool lookup name keepass | keepassxc --pw-stdin --keyfile /path/to/keyfile /path/to/database.kdbx

can someone please help me with this ? i've been looking for hours for a solution and i can't find antyhing that actually works
i've added a folder in my kdewallet named keepass with a password entry but whater i do secret-tool won't return anything. i'm so tired i don't understand how this awful tool works

[62f]

You’re still using openSUSE? Don’t SUSE still have an Optional paywall support? Cool avatar, BtW.

[Kyr4l]

i use tumbleweed yes

Don’t SUSE still have an Optional paywall support

paywall support ? what ?

[murlakatamenka]

paywall support ? what ?

https://github.com/dylanaraps/pywal

[tux-peng]

kwallet-query -r keepass kdewallet -f Passwords | keepassxc --pw-stdin ~/OneDrive/Passwords.kdbx

[PBujakiewicz]

While waiting for version 2.8 with fingerprint unlocking capabilities, I created a script for Windows users. You can find it here: KeePassXC-AutoUnlock-Login-Windows.

[jakob1379]

If you're using a desktop environment (DE) and just want KeePassXC to unlock the database without relying on temporary unlocks (as with keepassxc-cli), and you're using KPXC's Secret Service integration, a straightforward method is:

secret-tool search --all * >/dev/null 2>&1

This command unlocks the database while discarding any output.

The current discussion on this issue seems to be overcomplicating things given the assumptions above. This method avoids the circular dependency problem and doesn't require storing passwords in third-party keyrings.

[michaelk83]

This command alone doesn't actually unlock anything. At most, it will ask the user to manually enter the credentials for the Secret Service database. This thread is about unlocking without further user input.

[erenfro]

I've done gone ahead and done this little project to automate this, at least using system keychains (that means KeePassXC can't be Secret Service provider), and came up with this: https://github.com/erenfro/keepassxc-unlocker

[amano-kenji]

What about mapping a keyboard shortcut to a command that copies keepassxc password from keyring to clipboard?

After you press the keyboard shortcut, you can paste it into keepassxc password prompt.

This keyboard shortcut is also useful for entering sudo password.

I don't understand why you would want to use keepassxc as libsecret provider. A secret service provider is messed up by applications. I want my keepassxc database to be clean.

I tried to love the combination of pam_gnupg and pass, but it is very slow to search pass.

keepassxc-unlocker script is very complex. On the other hand, a simple command is very simple.

[Mayurifag]

Heyo guys have you come with any convenient solution on your setup? I am using KeepassXC like many years and its boring to type that master password and I thought how may I solve it for myself.

I do not like solutions of using system keyring for many reasons including stated already and what I am thinking of is that since I use ejson, might there any way I can use key from there to keep the secret hidden. Just did not come with good ideas yet.

[amano-kenji]

I just use gnome keyring for the master password for now. I'd rather have something quickly because I don't have a lot of time to fiddle with technicalities.