Arch Linux

Fehler beim Öffnen von kwallet mit gpg

Josephus Miller

Hallo,

seit heute morgen begrüßt mich auf dem Desktop statt der Eingabemaske für das gpg-Passwort die Meldung:

Fehler beim Versuch, den mit GPG verschlüsselten Passwortspeicher kdewallet zu entschlüsseln. Verwenden Sie eine Chipkarte, überprüfen Sie, ob sie richtig eingesteckt ist und versuchen es erneut.

Die GPG-Fehlermeldung lautet Entschlüsselung fehlgeschlagen

Ein Klick auf " Erneut versuchen" ändert nichts, ebensowenig läßt sich das Fenster mit "Abbrechen" schließen.

Die Meldungen zu kwallet und gpg:

journalctl -e | grep kwallet
Nov 04 09:55:52 arch-PC dbus-daemon[678]: Activating service name='org.kde.kwalletd5'
Nov 04 09:55:52 arch-PC akonadi_davgroupware_resource[978]: The kwalletd service has been registered
Nov 04 09:55:52 arch-PC akonadi_imap_resource[993]: The kwalletd service has been registered
Nov 04 09:55:52 arch-PC akonadi_imap_resource[989]: The kwalletd service has been registered
Nov 04 09:55:52 arch-PC akonadi_davgroupware_resource[977]: The kwalletd service has been registered
Nov 04 09:55:52 arch-PC akonadi_davgroupware_resource[979]: The kwalletd service has been registered
Nov 04 09:55:52 arch-PC akonadi_davgroupware_resource[974]: The kwalletd service has been registered
Nov 04 09:55:52 arch-PC kwalletd5[1102]: kwalletd5 started
Nov 04 09:55:52 arch-PC akonadi_imap_resource[994]: The kwalletd service has been registered
Nov 04 09:55:52 arch-PC akonadi_imap_resource[995]: The kwalletd service has been registered
Nov 04 09:55:52 arch-PC akonadi_imap_resource[992]: The kwalletd service has been registered
Nov 04 09:55:52 arch-PC kwalletd5[1102]: openAsync for  ":1.47"
Nov 04 09:55:52 arch-PC akonadi_imap_resource[995]: QDBusConnection: name 'org.kde.kwalletd5' had owner '' but we thought it was ':1.60'
Nov 04 09:55:52 arch-PC dbus-daemon[678]: Successfully activated service 'org.kde.kwalletd5'
Nov 04 09:55:52 arch-PC kwalletd5[1102]: Setting useNewHash to true
Nov 04 09:55:53 arch-PC kwalletd5[1102]: Wallet new enough, using new hash
Nov 04 09:55:53 arch-PC kwalletd5[1102]: Error decrypting message:  Entschlüsselung fehlgeschlagen , code  152 , source  GPGME
Nov 04 09:55:55 arch-PC kwalletd5[1102]: Migration agent starting...
Nov 04 09:55:55 arch-PC kwalletd5[1102]: kwalletd not started. Attempting start...
Nov 04 09:55:55 arch-PC kwalletd5[1102]: Couldn't start kwalletd:  QDBusError("org.freedesktop.DBus.Error.Spawn.ChildExited", "Process org.kde.kwalletd exited with status 127")
Nov 04 09:55:55 arch-PC kwalletd5[1102]: KDE4 kwalletd not present, stopping migration agent
Nov 04 09:55:55 arch-PC kwalletd5[1102]: Migration agent stop.
Nov 04 09:55:55 arch-PC kwalletd5[1102]: openAsync for  ":1.49"
Nov 04 09:55:55 arch-PC kwalletd5[1102]: openAsync for  ":1.45"
Nov 04 09:55:55 arch-PC kwalletd5[1102]: openAsync for  ":1.46"
Nov 04 09:55:55 arch-PC akonadi_imap_resource[989]: QDBusConnection: name 'org.kde.kwalletd5' had owner '' but we thought it was ':1.60'
Nov 04 09:55:55 arch-PC akonadi_imap_resource[994]: QDBusConnection: name 'org.kde.kwalletd5' had owner '' but we thought it was ':1.60'
Nov 04 09:55:55 arch-PC kwalletd5[1102]: openAsync for  ":1.50"
Nov 04 09:55:55 arch-PC akonadi_imap_resource[992]: QDBusConnection: name 'org.kde.kwalletd5' had owner '' but we thought it was ':1.60'
Nov 04 09:55:55 arch-PC akonadi_imap_resource[993]: QDBusConnection: name 'org.kde.kwalletd5' had owner '' but we thought it was ':1.60'
Nov 04 09:55:55 arch-PC dbus-daemon[678]: Activating service name='org.kde.kwalletd'
Nov 04 09:55:55 arch-PC dbus-daemon[678]: Activated service 'org.kde.kwalletd' failed: Process org.kde.kwalletd exited with status 127
Nov 04 09:55:55 arch-PC org.kde.kwalletd[678]: /usr/bin/kwalletd: error while loading shared libraries: libgpgme++-pthread.so.2: cannot open shared object file: No such file or directory                                                                                                                                              
Nov 04 09:56:42 arch-PC akonadi_davgroupware_resource[979]: QDBusConnection: name 'org.kde.kwalletd5' had owner '' but we thought it was ':1.60'                    
Nov 04 09:56:42 arch-PC akonadi_davgroupware_resource[978]: QDBusConnection: name 'org.kde.kwalletd5' had owner '' but we thought it was ':1.60'                    
Nov 04 09:56:42 arch-PC akonadi_davgroupware_resource[974]: QDBusConnection: name 'org.kde.kwalletd5' had owner '' but we thought it was ':1.60'                    
Nov 04 09:56:42 arch-PC akonadi_davgroupware_resource[977]: QDBusConnection: name 'org.kde.kwalletd5' had owner '' but we thought it was ':1.60'

Ich habe hier eine recht frische Installation mit KDE5. Gestern kam an sich kein relevantes Update:

[2015-11-03 09:54] [PACMAN] Running 'pacman -Syu'$
[2015-11-03 09:54] [PACMAN] synchronizing package lists$
[2015-11-03 09:54] [PACMAN] starting full system upgrade$
[2015-11-03 09:55] [ALPM] transaction started$
[2015-11-03 09:55] [ALPM] upgraded cpupower (4.2-2 -> 4.3-1)$
[2015-11-03 09:55] [ALPM] installed vid.stab (1.1-1)$
[2015-11-03 09:55] [ALPM] upgraded ffmpeg (1:2.8.1-2 -> 1:2.8.1-3)$
[2015-11-03 09:55] [ALPM] upgraded unzip (6.0-10 -> 6.0-11)$
[2015-11-03 09:55] [ALPM] transaction completed$

Ich habe zwar einen neuen gpg-Schlüssel angelegt, aber auch das dürfte nicht damit zu tun haben.

Wäre schön wenn jemand eine Idee hat...

k.osmo

Hallo,
zwar weiß ich nicht, ob da tatsächlich ein Zusammenhang besteht; ich würde zunächst aber mal prüfen, welche deiner Schlüssel zur Authentifizierung genutzt werden dürfen. Der Befehl

$ gpg -K --list-options show-usage <key-id>

sollte da einen Hinweis geben (für jede relevante <key-id> ausführen).

man gpg schriebshow-usage

Show usage information for keys and subkeys in the standard key listing. This is a list of letters indicating the allowed usage for a key (E=encryption, S=signing, C=certification, A=authentication). Defaults to no.

Bei mir ist der entsprechende Schlüssel, und nur dieser, mit [SCA] gekennzeichnet. Nur dieser Schlüssel wird bei mir zur Authentifizierung für kdewallet verwendet. Allerdings nur bei Bedarf, ohne Autostart via kwallet-pam… Akonadi habe ich außerdem abgeschaltet.
Grüße, k.osmo

Josephus Miller

Hallo,

bei mir hat keiner der Schlüssel ein A, es sind allerdings auch nur die für die per gpg erstellten zu sehen, also einer Mailadresse zugeordnet. Das Passwort für den Passwortspeicher wurde unabhängig davon erstellt, als ich die Mailkonten von kmail eingerichtet habe. Ein Schlüsselpaar in gpg habe ich erst später erstellt, und diese gestern wieder gelöscht. Möglicherweise war dies der Auslöser, was mich aber wundern würde. Ich werde mal einen Unterschlüssel zur Authentisierung erstellen und es testen.

Allerdings vermute ich nachdem ich den Wikipedia-Artikel zu gpg überflogen habe, dass das Problem beim gpg-agent liegt

k.osmo

Icecube63 schriebDas Passwort für den Passwortspeicher wurde unabhängig davon erstellt, als ich die Mailkonten von kmail eingerichtet habe.

Wo sollte der gpg-Schlüssel für den Passwortspeicher denn liegen, wenn nicht in /home/<Benutzer>/.gnupg/?

Ein Schlüsselpaar in gpg habe ich erst später erstellt, und diese gestern wieder gelöscht. Möglicherweise war dies der Auslöser, was mich aber wundern würde. Ich werde mal einen Unterschlüssel zur Authentisierung erstellen und es testen.

Nutzt Du zur Schlüsselverwaltung die Kommandozeile, oder ein grafisches Frontend? Ersteres wäre meine Empfehlung, zumindest zur Gegenprobe.

Josephus Miller

k.osmo schrieb
Icecube63 schriebDas Passwort für den Passwortspeicher wurde unabhängig davon erstellt, als ich die Mailkonten von kmail eingerichtet habe.
Wo sollte der gpg-Schlüssel für den Passwortspeicher denn liegen, wenn nicht in /home/<Benutzer>/.gnupg/?

Das ist schon richtig, nur scheint die Verwaltung anders zu sein, denn angezeigt wird mir da nichts. Und wie gesagt war der Schlüssel hierfür schon vor der Erstellung des Schlüsselpaares da, und wurde auch vorher nicht angezeigt.

Ein Schlüsselpaar in gpg habe ich erst später erstellt, und diese gestern wieder gelöscht. Möglicherweise war dies der Auslöser, was mich aber wundern würde. Ich werde mal einen Unterschlüssel zur Authentisierung erstellen und es testen.
Nutzt Du zur Schlüsselverwaltung die Kommandozeile, oder ein grafisches Frontend? Ersteres wäre meine Empfehlung, zumindest zur Gegenprobe.

Ich nutze die Kommandozeile. Hier gibt es leider die Möglichkeit mit [k]addkey[/] die Authentisierungsfähigkeit anzuwählen nicht mehr, nur noch Signieren/Beglaubigen und Verschlüsseln. Daher kann ich keinen meinen Key nicht entsprechend ändern.

k.osmo

Hmm… also, bei mir ist es zwar schon eine Weile her, dass ich den Passwortspeicher eingerichtet habe, allerdings scheint mir, als könne man einen gpg-Schlüssel nur verwenden, wenn er schon im Vorhinein erzeugt wurde; siehe –>
https://docs.kde.org/stable5/en/kdeutils/kwalletmanager/introduction.html

Dabei ist wichtig, dass der gpg-Schlüssel das Vertrauenslevel [ultimate] hat, sonst wird er gar nicht erst angezeigt.

Vom fehlgeschlagenen Autostart mal abgesehen; kannst Du auf den Passwortspeicher über kwalletmanager zugreifen?

Josephus Miller

Ich bin mir aber sicher dass ich keinen hatte, und es trotzdem ca 10 Tage funktionierte.

Und bei mir werden auch Schlüssel mit unbekanntem Level angezeigt.

Den Manager muss man bei KDE5 extra installieren. Werde ich nachher mal versuchen und schauen was passiert

k.osmo

Icecube63 schriebUnd bei mir werden auch Schlüssel mit unbekanntem Level angezeigt.

Sorry, das war von mir missverständlich formuliert. Ich meinte, wenn Du per kwalletmanager/Systemeinstellungen einen neuen Passwortspeicher, z. B. test, erzeugen willst; nicht die Ausgabe von bspw. gpg -k auf der Kommandozeile.

Josephus Miller

k.osmo schrieb Vom fehlgeschlagenen Autostart mal abgesehen; kannst Du auf den Passwortspeicher über kwalletmanager zugreifen?

Nein. Ich habe den kwalletmanager installiert, ich kann weder einen (neuen) Standardpasswortspeicher anlegen noch die Passwortverwaltung starten. Bei letzterem Fall kommt wieder das Popup mit der Meldung aus dem 1. Beitrag.

Immerhin konnte ich so die Passwortverwaltung abstellen, allerdings muss ich nun alle Mailaccount- und webdav-Passwörter beim Start eingeben, was nicht unbedingt bedienerfreundlich ist.

k.osmo

Hast Du Akonadi schon konfiguriert und in Verwendung?
https://wiki.archlinux.org/index.php/KDE#PIM
https://wiki.archlinux.org/index.php/KDE#Clean_akonadi_configuration_to_fix_KMail

Ansonsten vllt. mal abschalten; damit dürfte /usr/bin/kwalletd5 erst starten, wenn auf den Passwortspeicher zugegriffen wird (mit "systemctl status" prüfen).

$ akonadictl help

Ist immer noch ein Versuch, den Fehler weiter einzugrenzen.

Josephus Miller

k.osmo schriebHast Du Akonadi schon konfiguriert und in Verwendung?
https://wiki.archlinux.org/index.php/KDE#PIM
https://wiki.archlinux.org/index.php/KDE#Clean_akonadi_configuration_to_fix_KMail

Ansonsten vllt. mal abschalten; damit dürfte /usr/bin/kwalletd5 erst starten, wenn auf den Passwortspeicher zugegriffen wird (mit "systemctl status" prüfen).
$ akonadictl help
Ist immer noch ein Versuch, den Fehler weiter einzugrenzen.

Akonadi läuft, allerdings wurde da nicht konfiguriert sondern er läuft (und lief) mit den Standardeinstellungen.

Abgeschaltet habe ich schon, dann startet aber kmail nicht weil kein Zugriff möglich ist. Und wenn kwallet auf den PAsswortspeicher zugreifen will kommt immer die Fehlermeldung.

Ich vermute eine Lösung wäre die von gpg verschlüsselt gespeicherte Passwortdatei zu löschen, allerdings finde ich sie nicht

k.osmo

Icecube63 schriebIch vermute eine Lösung wäre die von gpg verschlüsselt gespeicherte Passwortdatei zu löschen, allerdings finde ich sie nicht

Bei mir liegen die *.kwl-Dateien unter .local/share/kwalletd/.

Josephus Miller

k.osmo schrieb
Icecube63 schriebIch vermute eine Lösung wäre die von gpg verschlüsselt gespeicherte Passwortdatei zu löschen, allerdings finde ich sie nicht
Bei mir liegen die *.kwl-Dateien unter .local/share/kwalletd/.

Genau das wars, nach dem Löschen konnte ich kwallet neu einrichten und einen - nun vorhandenen - gpg-Schlüssel auswählen.

Danke!

k.osmo

Wieder was gelernt. 🙂 Bis zum nächsten Mal! 😉