Talk:KDE Wallet

kwallet-pam does not unlock KDE Wallet with SDDM

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

kwallet-pam for non-graphical login

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)

Set SSH_ASKPASS_REQUIRE to prefer causes autostart script to fail

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 [1]. Need to set DISPLAY environment variable with ssh-agent. TheBill2001 (talk) 07:44, 12 March 2024 (UTC)

Move Chromium based profile from Gnome-keyring to KWallet.

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.

KSecretPrompter

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)

KeepSecret

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)

PAM configuration seems not to be necessary

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)

I did some researches, and shows the PAM configuration should be necessary:

• Set kdewallet with password same as my user`s one, reboot the system and everything is fine.
• Set kdewallet to some password not same as my user, reboot the system, I need to input password when using VSCode.
• Reset kdewallet password, reboot the system, everything is fine again.
• Copy /usr/lib/pam.d/plasmalogin to /etc/pam.d and remove two lines that include pam_kwallet5.so, reboot the system, I need to input password when using VSCode.

So I think the PAM configuration is necessary but not need to be done manually with SDDM and PLM. CoinSkydiver804 (talk) 10:00, 31 August 2026 (UTC)

UPDATE: Sorry, I misunderstood the wiki page. My tests only shows the pam configure is necessary for auto unlock of kwallet. CoinSkydiver804 (talk) 13:50, 1 September 2026 (UTC)

After digging into the source code of kwallet-pam and kwallet, the configuration of kwalletd seems being done in cmake scripts. Here`s the clue:

• In kwallet-pam, kwalletd argument defaults to KWALLETD_BIN_PATH
• In kwallet-pam cmake script, if KWALLETD_BIN_PATH is not defined, then KF6::KWallet will be imported, and then passed into the code as macro
• In kwallet, the KWALLETD_BIN_PATH is defined as /usr/bin/ksecretd(actually KDE_INSTALL_BINDIR/ksecretd, KDE_INSTALL_BINDIR is from extended-cmake-module)

In conclusion, now kwalletd is defaults to ksecretd now, no configure is needed. But for non-graphical session or tty login, force-run might still needed. CoinSkydiver804 (talk) 04:34, 2 September 2026 (UTC)

Looking at kwallet, it seems to me this topic discusses automation provided by kwallet-pam, which is not a kwallet dependency. For the other login-managers (like SDDM), the packages provide the PAM files, for PLM the additional package is required and some of you may have had it, others not. Yet, it is only touched on later in KDE_Wallet#Unlock KDE Wallet automatically on login. If this is correct, the section should be merged and (hopefully condensed to necessities again). --Indigo (talk) 18:45, 2 September 2026 (UTC)

KWalletd6 as proxy for KeePassXC with Secret Service

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)