Apparently, the use of pam_kwallet-git does not work if the wallet is encrypted with a GnuPG key. --Fahrgast (talk) 15:10, 28 January 2015 (UTC)

It is possible use a blank password too to open the wallet automatically according with [1] J0n4t (talk) 19:35, 21 July 2016 (UTC)

I offer these comments with some trepidation: Kwallet can be unlocked automatically when using a GnuPG key, but it's complicated. . . complicated enough that I don't quite recall all the details of how it's done. Hence, my trepidation. However, I am using this on one of my machines. The basics are that kwallet is configured to use a GnuGP key, and gnome-keyring is configured to unlock my GnuGP keys automatically. Editing files in /etc/pam.d/ is required, and unfortunately, this is where my knowledge and recollection is lacking. I'm pretty sure that login, sddm-autologin, and passwd in that folder all required editing. I was following someone else's instructions at the time and unfortunately cannot locate them again. I can say that my kwallet configuration is definitely using a GnuGP key, and my Network Manager wifi configuration is set to encrypt my stored wifi password, my GnuGP keys are unlocked automatically by gnome-keyring, and when I log on, my system connects automatically to wifi without my having to key in a wifi password or a kwallet password. If anyone has interest in pursuing this, and possesses a better understanding of PAM than I do, I'm willing to share the contents of my PAM files. If there are any further tricks required, I don't recall what they were unfortunately.

L userx (talk) 02:27, 20 March 2019 (UTC)

kwalletmanager in repo is for kde4, and use different path from kde5 ( ./.local/share/kwalletd/kdewallet.kwl ) and also seems to be incompatible (copied/linked kwl file giver password error). kwalletmanager-git works fine, but is still lacking gpg.

May be helpful: workaround for this bug (or feature) is here

With kwallet 6.22.0-1 the token transmission changes a bit

Now we have to adjust our PAM profiles like this

 #%PAM-1.0
 auth optional pam_kwallet5.so force_run kwalletd=/usr/bin/ksecretd
 session optional pam_kwallet5.so force_run auto_start kwalletd=/usr/bin/ksecretd
 

this solution works for me, please confirm

Can we please get a guide for this? I've added the lines to /etc/pam.d/login but it's not unlocking. Other guides have lines added to /etc/pam.d/passwd but for some reason the file looks different on other distros, or maybe I'm seeing old tutorials. MisterMustafa (talk) 21:06, 27 March 2017 (UTC)

the order of the PAM modules is important. the following is just exemplary to clarify PAM stack order. with kwallet 6.22.0-1, the first grabbing of PAM_AUTHTOK has to happen right after successful authentication (auth stack/phase), something like:

auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok

auth       [default=die]               pam_faillock.so      authfail

auth       optional              pam_kwallet5.so force_run kwalletd=/usr/bin/ksecretd

later in session phase the token has to be transmitted within systemd session:

-session   optional                    pam_systemd.so

session    optional                    pam_kwallet5.so force_run auto_start kwalletd=/usr/bin/ksecretd Arkades (talk) 11:32, 24 January 2026 (UTC)

It seems that setting SSH_ASKPASS_REQUIRE=prefer causes ssh-add autostart to fail on two of my machines. ssh-add did not use ksshaskpass in this instance. I have to set SSH_ASKPASS_REQUIRE=force only for the autostart script. Did I do something wrong? TheBill2001 (talk) 07:37, 12 March 2024 (UTC)

It seems to be a Wayland issue [2]. Need to set DISPLAY environment variable with ssh-agent. TheBill2001 (talk) 07:44, 12 March 2024 (UTC)

Set up KWallet PAM for first! Otherwise you will break a Chrome Storage.

Open Seahorse: Seahorse is a graphical interface for managing encryption keys and passwords.

Locate Chrome/Chromium/Brave Safe Storage and Its Key: In Seahorse, find the "Safe Storage" entry associated with your browser (e.g., Chrome, Chromium, Brave).

Rename the Browser Configuration Folder: Navigate to your home directory and locate the browser's configuration folder. For Chrome, this is typically ~/.config/google-chrome. Rename this folder to something like google-chrome-backup to back up your current profile.

Open a New Instance of Chrome: Launch Chrome again, which will create a new configuration/profile folder automatically.

Close Chrome: After the new instance has been created, close the browser.

Open KWalletManager5: KWalletManager5 is a password manager for Plasma. Open it to manage your wallet.

Replace the Chrome Safe Storage Key: In KWalletManager5, locate the Safe Storage key for Chrome. Replace the existing key with the one you backed up or intend to use.

Remove the New Browser Profile: Delete the newly created ~/.config/google-chrome folder to remove the temporary profile.

Restore the Original Browser Profile: Rename your backup folder (google-chrome-backup) back to google-chrome to restore your original browser profile.

This seems to be the future of secret management for kde. will only leave links for now as nothing is available yet, but at least something will show up on searches.

https://invent.kde.org/plasma/plasma-workspace/-/tree/master/ksecretprompter

https://aur.archlinux.org/packages/oo7-server

18:32, 14 February 2026 (UTC) Gcb (talk) 18:32, 14 February 2026 (UTC)

The comment above mentions ksecretprompter, there is a GUI tool called keepsecret, that I believe is related. It is also in development. I think it's worth a link or mention on the page, because it allows users to view secrets stored using libsecret as well as the KWallet format (eg. passwords stored using GNOME Evolution).

Rockingcool (talk) 00:29, 2 March 2026 (UTC)

https://wiki.archlinux.org/title/KDE_Wallet#Configure_PAM_on_Plasma_6_(KF6)

From my personal usage it seems I did not have to configure any PAM module whatsoever, even with Plasma Login Manager. That section should probably be deleted or de-prioritized, since SDDM and/or Plasma Login Manager (which will typically be what the user will be using) don't seem to require such configuration. TheSleuth (talk) 06:10, 30 March 2026 (UTC)

for me it is the same. On X11 no difference with the config or not, no unlock. On Wayland no problem whatsoever. So i think too this is unnecessary. Kazel (talk) 08:03, 30 March 2026 (UTC)

also, not like mentioned in the article, the config does not exist in the sddm package Kazel (talk) 08:04, 30 March 2026 (UTC)

At least on Hyprland I did have to configure the PAM module manually with Plasma Login Manager. I also use KDE Plasma and it didn't require this step, so Plasma seems to handle it automatically. Mint (talk) 07:48, 17 April 2026 (UTC)

i would like to mention that my setup worked for years with automatic unlocking. It was an update that broke it. Kazel (talk) 03:35, 6 June 2026 (UTC)

TL;DR: Have KDE Wallet enabled but as a proxy to forward all requests to KeePassXC's Secret Service Feature.

First up - I'm new here and created this account because this issue can now finally be solved and it took way to much time to get it working for myself. So I want to save others the hassel and put the information in a place where most people likely see it - this wiki :). If this information is relevant, please help me to update the wiki page.

With KDE Wallet refactored into two components, kwalletd6 and ksecretd, it is possible to deactivate the ksecretd service (KDE's own password manager/store) and configure kwalletd6 to use the freedesktop secret dbus service with e.g. KeePassXC.

The problem: It does not work out-of-the-box and there are multiple open issues on various sites that have parts of the solution but seem to be unable to get it working even though the KDE project merged one or more fixes to solve the issue. E.g. https://github.com/keepassxreboot/keepassxc/issues/12755

Rough Procedure:

1. Disable ksecretd (basically the old kdewallet functionality) by adding to or creating the snippet: ~.config/kwalletrc [KSecretD] as mentioned here, which somehow misses the path to the config: https://github.com/KDE/kwallet Note there is the option to migrate the existing content of the wallet - I did not try it.
2. Kill the ksecretd process (with htop, systemmonitor, reboot, ..)
3. With no secret service provider running, KeePassXC enables you to activate its secret service feature. Just activate it for now without any backing databases selected.
4. The visible problem: Now comes the funny part. So far kdewallet will eventually (after being restarted I think) find this new service and even list it in kwalletmanager's settings page, if a DB was found for credantial storage. But any request seems to time out since the kwalletd6 proxy just freezes or requests to create a new DB in KeePassXC and then erroring out. The internal problem: For some reason it seems to expect the passwort storage to still be named "kdewallet" (This might also be relevant for non KeePassXC solutions). A solution: Got the idea from here: https://bugs.kde.org/show_bug.cgi?id=504312#c27, so thanks michaelk83. KeePassXC takes this name from the database's name. Seemingly not the database filename nor the published database group but the name of the database itself must match. I have tested only the database's name. Thus one must create(, rename?) or already posess a KeepassXC database called "kdewallet" and enable the secret service in settings + make a subgroup (can be root) of the "kdewallet"-named database available in its database's settings.
5. Now it is easiest to turn off the wifi (systemwide in the plasma-nm-applet) for a clean test case by preventing it to immediately try and grab credentials on reboot.
6. Reboot.
7. Unlock the "kdewallet"-DB in KeepassXC.
8. Navigate to plasma's system settings to find the KWalletManager's page (For some reason the standalone app sometimes crashes to an error message), which is named something along the lines (translated) of "KDE password storage" and find the "default password storage"-dropdown. This should now present the selected option "kdewallet". Check that the lowest option "password service" is still unchecked (ksecretd should still not run). If it looks fine just do not touch it I guess.
9. Now we are ready to test everything with a KDE app making use of the KWalletD6 interface. E.g. connect to a password secured wifi through the plasma-nm-applet.
10. It should provide the usual password prompt or if qrca is used to scan a QR code, directly connect creating and accessing the desired entry within KeePassXC, which looks something like the following: Title field: Network Management/{SOMEHASH};802-11-wireless-security Password field: {"psk":"WIFIPASSWORD"}
11. Enjoy a working solution that sould be able to be synced between your devices. It is possible to have one database in KeePassXC open another without further manual intervention (Check here https://keepassxc.org/docs/KeePassXC_UserGuide#_automatic_database_opening).

Feel free to link this information to the various git issues and help requests, where it likely applies and where I do not have accounts. Maybe it gets fixed and until then this can be used as a workaround that should still work after sensible upstream fixes have been applied (like not expecting the name to be "kdewallet"). To all people enabling this solution in the first place: Thank you very much for your work. 0x2a (talk) 16:10, 17 April 2026 (UTC)

Likely related posts:

"Not possible": https://bbs.archlinux.org/viewtopic.php?id=287302

"Works partial, wants new DBs": https://github.com/keepassxreboot/keepassxc/discussions/12445

"Prompt for new DB using KWalletD with KeePassXC": https://github.com/keepassxreboot/keepassxc/issues/12755

"Dolphin integration broken- related?": https://forum.manjaro.org/t/replacing-kwallet-by-keepassxc/173028

"KWalletD timing out": https://forums.opensuse.org/t/kwalletmanager-crashing-with-fresh-install/192056

"KWalletD with KeepassXC not working for Wifi": https://bugs.kde.org/show_bug.cgi?id=504312

"Solved: Problems saving - this might introduced a relevant fix": https://github.com/keepassxreboot/keepassxc/issues/3679#issuecomment-2816667332

"plasma-nm unable to get secrets through KWalletD from KeePassXC": https://unix.stackexchange.com/questions/805426/unable-to-retrieve-secrets-when-requesting-secrets-from-kwallet 0x2a (talk) 16:27, 17 April 2026 (UTC)