[solved] GnuPG und Smartcard (Nitrokey)

[schmidicom]

Hallo, ich habe bei meinem Laptop (und merkwürdigerweise nur dort) ein Problem mit GnuPG und einem Nitrokey 3C NFC (ein USB-Stick der unter anderem auch eine GnuPG SmartCard ist).

Wenn ich den USB-Stick nach dem hochfahren einstecke muss ich erst den PCSC-Daemon neustarten damit GnuPG das Ding erkennt. Hier mal wie das abläuft:

Code: Select all

schmidicom@shs-pulse ~> gpg2 --card-status
gpg: selecting card failed: Kein passendes Gerät gefunden
gpg: OpenPGP Karte ist nicht vorhanden: Kein passendes Gerät gefunden

Code: Select all

schmidicom@shs-pulse ~ [2]> systemctl status pcscd.service 
● pcscd.service - PC/SC Smart Card Daemon
     Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; preset: enabled)
     Active: active (running) since Sun 2024-06-16 08:16:58 CEST; 29s ago
TriggeredBy: ● pcscd.socket
       Docs: man:pcscd(8)
   Main PID: 2357 (pcscd)
      Tasks: 10 (limit: 33277)
     Memory: 2.5M (peak: 4.1M)
        CPU: 63ms
     CGroup: /system.slice/pcscd.service
             └─2357 /usr/sbin/pcscd --foreground --auto-exit

Jun 16 08:16:58 shs-pulse systemd[1]: Started PC/SC Smart Card Daemon.
Jun 16 08:16:58 shs-pulse (pcscd)[2357]: pcscd.service: Referenced but unset environment variable evaluates to an empty>

Code: Select all

schmidicom@shs-pulse ~> systemctl restart pcscd.service

Code: Select all

schmidicom@shs-pulse ~> gpg2 --card-status
Reader ...........: Nitrokey Nitrokey 3 [CCID/ICCD Interface] 01 00
Application ID ...: CENSORED
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: Nitrokey
Serial number ....: CENSORED
Name of cardholder: CENSORED
Language prefs ...: de
Salutation .......: CENSORED
URL of public key : CENSORED
Login data .......: [nicht gesetzt]
Signature PIN ....: zwingend
Key attributes ...: ed25519 cv25519 ed25519
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 15
KDF setting ......: off
UIF setting ......: Sign=off Decrypt=off Auth=off
Signature key ....: CENSORED
      created ....: 2023-12-24 13:39:14
Encryption key....: CENSORED
      created ....: 2023-12-24 13:39:31
Authentication key: CENSORED
      created ....: 2023-12-25 18:24:01
General key info..: pub  CENSORED
sec>  CENSORED  erzeugt: 2023-12-24  verfällt: 2026-12-23
                                Kartennummer:000F D7E0BFF0
ssb>  CENSORED  erzeugt: 2023-12-24  verfällt: niemals   
                                Kartennummer:000F D7E0BFF0
ssb>  CENSORED  erzeugt: 2023-12-25  verfällt: niemals   
                                Kartennummer:000F D7E0BFF0

Hier noch die Konfiguration:

###+++--- GPGConf ---+++###
enable-ssh-support
###+++--- GPGConf ---+++### Mo 25 Dez 2023 20:23:05 CET
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.

###+++--- GPGConf ---+++###
utf8-strings
keyserver hkps://keys.openpgp.org
###+++--- GPGConf ---+++### Mo 25 Dez 2023 20:23:05 CET
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.

###+++--- GPGConf ---+++###
debug-level basic
log-file socket:///home/schmidicom/.gnupg/log-socket
###+++--- GPGConf ---+++### Mo 25 Dez 2023 20:23:05 CET
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.
disable-ccid

Das "disable-ccid" in der Datei ".gnupg/scdaemon.conf" habe ich drin weil das ganze ohne diese Option garnicht mehr funktioniert hat.
Siehe dazu folgendes: https://github.com/libusb/libusb/issues/1471

Weiss jemand wie ich dieses Problem lösen oder wenigstens umschiffen kann?

[firefly]

Hast du eventuell unterschiedliche useflags gesetzt bei den paketen die relevant sind für den smartcard access auf deinem pc und notebook?
Ansonsten, erstellt pcsc ein logfile in dem es protokolliert was es tut? (Eventuell muss man es aktivieren)
Dann könnte man eventuell sehen was auf dem PC und auf dem notebook unterschiedlich abläuft.
Meine Spekulation ist, dass eventuell der zugriff auf das USB device nicht direkt möglich ist, wenn das Device eingesteckt wird. Aber der pcsc deamon das tun möchte um zu erkennen ob es ein smartcard device ist.
Eventuell ist der USB host chip quirky im Notebook wodurch das die spekulierte verzögerung mit dem das device voll verfügbar ist entstehen könnte.
Tritt das Problem auf dem notebook mit allen USB ports auf oder nur bei bestimmten?

[firefly]

nach einer kurzen suche kann es eventuell sein, dass du auf einem der beiden systemen app-crypt/ccid installiert hast aber auf dem anderen nicht?
Das könnte eventuell erklären wieso du auf dem notebook den ccid support des pcsc deamons deaktivieren musst. Weil entweder das vorhandensein der ccid treiber, welcher via dem ccid paket installiert werden, probleme machen, oder relevant sind damit es funktioniert

Edit ich habe diesen mailing thread gefunden der ein ähnliches problem beschreibt:
http://lists.infradead.org/pipermail/pc ... 01385.html

Les dir das mal durch bezüglich pcsc und gnupg gibt es auch diese information (ist in dem mailing thread auch referenziert): https://blog.apdu.fr/posts/2019/06/gnup ... conflicts/

[schmidicom]

Mein PC und mein Laptop haben fast die selbe Konfiguration (die USE-Flags sind identisch) aber das Package "app-crypt/ccid" unterscheidet die beiden wirklich von einander. Der Grund für diesen Unterschied ist das der Laptop einen eingebauten Smartcard-Reader hat der ohne dieses Package nicht funktioniert weil "sys-apps/pcsc-lite" selbst keine Treiber für USB-Smartcard-Reader mitbringt.
Ist dieses Package nicht installiert wirft "sys-apps/pcsc-lite" beim start auch einen entsprechenden Fehler aus, siehe hier:

Code: Select all

Jun 16 10:34:53 shs-pulse systemd[1]: Started PC/SC Smart Card Daemon.
Jun 16 10:34:53 shs-pulse (pcscd)[779]: pcscd.service: Referenced but unset environment variable evaluates to an empty string: PCSCD_ARGS
Jun 16 10:34:53 shs-pulse pcscd[779]: 00000000 /var/tmp/portage/sys-apps/pcsc-lite-2.0.1-r1/work/pcsc-lite-2.0.1/src/hotplug_libudev.c:121:HPReadBundleValues() Cannot open PC/SC drivers directory: /usr/lib64/readers/usb
Jun 16 10:34:53 shs-pulse pcscd[779]: 00000011 /var/tmp/portage/sys-apps/pcsc-lite-2.0.1-r1/work/pcsc-lite-2.0.1/src/hotplug_libudev.c:122:HPReadBundleValues() Disabling USB support for pcscd.

Ich habe jetzt aber trotzdem mal das Package "app-crypt/ccid" auf dem Laptop deinstalliert und alles getestet und ja so funktioniert GnuPG mit Nitrokey wieder.
Begeistert bin ich davon allerdings nicht wirklich, denn es bedeutet das ich nicht beides funktional halten kann. Fürs erste hat GnuPG zusammen mit Nitrokey aber Priorität, denn das brauche ich täglich während ich den Smartcard-Reader in meinem Laptop eher selten verwende.

Hier noch der Smartcard-Reader von meinem Laptop:

Code: Select all

...
Bus 001 Device 007: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader
...

EDIT:
Und noch als ergänzung, nein "sys-apps/pcsc-lite" erstellt keine Logs und ich wüsste auch nicht wie ich das ändern könnte.

EDIT2:
Und die Idee (von https://blog.apdu.fr/posts/2019/06/gnup ... conflicts/) "app-crypt/gnupg" zu zwingen "sys-apps/pcsc-lite" zu verwenden hatte ich ja bereits ausprobiert und auch das funktioniert nur mit manuellem neustart von "pcscd.service" weil die beiden sich offenbar trotzdem gegenseitig auf die Füsse treten.

FAZIT:
Danke für die Hilfe, denn das GnuPG zusammen mit Nitrokey ohne manuellen eingriff funktioniert ist für mich allein schon deswegen wichtig weil darüber unter anderem meine SSH-Zugriffe laufen.

[firefly]

Wie man logs erstellt ist im mailing thread erklärt...

Und nach meinem verständnis ist ein möglicher grund der, dass gnupg mit seinem eigenen scdeamon exclusiv zugriff auf das gerät haben möchte was eventuell pcsc auch haben möchte und dadurch das problem auftritt.
Sicher dass du auf dem pc überhaupt pcsc-lite brauchst? bzw. den deamon davon?
Denn ohne das ccid paket kann pcsc überahupt nichts mit dem nitrokey anfangen. (https://github.com/LudovicRousseau/CCID ... /tag/1.5.0 ab dieser version wird der nitrokey 3 unterstützt)
Daher wird auf deinem pc wohl eher der gnupg eigene scdaemon genutzt werden für den zugriff statt pcsc. Besonders weil du auf dem pc in der gnupg konfig vermutlich nicht den gnupg eigenen ccid treiber support deaktiviert hast (wie du es auf dem notebook gemacht hast)

Hast du dir überhaupt den kompletten mailing thread durchgelesen?
Denn in folgenden post gibt es hinweise wie man sehen kann welche applikation den reader exlusiv blockiert und eine weitere mögliche lösung.

http://lists.infradead.org/pipermail/pc ... 01391.html
http://lists.infradead.org/pipermail/pc ... 01392.html

[schmidicom]

Mit meinem beschiedenen English bräuchte ich ewig um das alles angemessen durchzugehen. Deshalb, nein habe ich nicht.
Was ich beim schnellen drüber fliegen aus den verlinkten Sachen und deinen Posts herausnehme ist das sich die beiden Dienste "pcscd" und scdeamon" um die gleiche Sache streiten und das reicht mir fürs erste. Ich habe wirklich nicht die Zeit und ehrlich gesagt auch nicht den Nerv diesen Streit zu lösen.

Für mich ist das Problem fürs erste halt damit gelöst, oder eher umgangen, das ich "pcscd" still lege und "scdeamen" sein ding machen lasse.

[schmidicom]

Heute hatte ich etwas Zeit hier noch das eine oder andere auszuprobieren und das hier ist das Ergebnis:

Die beiden Dienste "scdaemon" (aus dem Package "app-crypt/gnupg") und "pcscd" (aus dem Package "sys-apps/pcsc-lite") versuchen, unter Umständen, exklusiv auf eine OpenGP-Smartcard zuzugreifen was gleichzeitig nicht möglich ist. Bestätigen lässt sich das zum Beispiel wenn man beim "pcscd" in der Datei "/etc/default/pcscd" die Option "-d, --debug" hinterlegt und dann dafür sorgt das "scdaemon" gestartet wird bevor "pcscd" anläuft. Dann sieht man im Log von "pcscd" (das Log habe ich leider nicht abgespeichert und deshalb kann ich es jetzt hier auch nicht mitgeben, sorry) das der Dienst nicht mehr in der Lage ist auf die von "scdaemon" in Beschlag genommene OpenGP-Smartcard zuzugreifen.

Das selbe passiert ziemlich sicher auch umgekehrt, nur konnte ich das nicht testen weil "scdeamon" auf meinen Geräten einfach einen feuchten Scheiß auf die eigene Konfiguration "~/.gnupg/scdaemon.conf" gibt und sich damit auch nicht dazu bewegen lässt mehr Logs auszugeben. Und weil sich "scdaemon" so verhält wie es nun eben ist, war es mir auch nicht möglich es mit irgendeiner Option dazu zu bewegen den eigenen CCID-Treiber nicht zu benutzen.

Meine aktuelle Lösung für dieses Problem ist nun die selbe welche auch Fedora, und ziemlich sicher auch RedHat, verwendet.
Ich habe auf all meinen Installationen "app-crypt/gnupg" ohne das USE-Flag "usb" neu gebaut, was dazu führt das der GnuPG eigene CCID-Treiber nicht mehr gebaut/installiert wird und somit der Dienst "scdaemon" gezwungen ist dann "pcscd" zu verwenden. Damit das funktioniert muss natürlich auch ein für "pcscd" geeigneter CCID-Treiber (zum Beispiel "app-crypt/ccid") installiert werden.

Die Lösung von Fedora/RedHat wird auf einigen Webseiten im Bezug auf die Sicherheit als "nicht empfehlenswert" bezeichnet weil "pcscd" einen Cache hat und damit eine "Aufzeichnung" anfertigt/verwendet. Meine Meinung dazu ist folgende:
Was bringt mir an dieser Stelle die Sicherheit wenn dafür abwechselnd das eine oder andere nicht mehr funktioniert? Richtig, nämlich nix. Davon abgesehen verwenden andere Programme ja auch "pcscd" und die haben damit auch kein Problem.

Ich setze das hier damit mal auf "solved".

[firefly]

Laut der docu wird scdaemon üblicherweise via gpg-agent gestartet.
Kann es eventuell sein, dass, aus welchen gründen auch immer, bei dir scdaemon im kontext eines anderen users gestartet wird? Und dadurch die einstellungen in deinem user ignoriert werden?
oder wird eventuell scdaemon mit dem parameter --options <fielpath> gestartet? Wodurch der process die einstellungen aus <filepath> liest anstelle der default datei.

[schmidicom]

Laut der docu wird scdaemon üblicherweise via gpg-agent gestartet.
Kann es eventuell sein, dass, aus welchen gründen auch immer, bei dir scdaemon im kontext eines anderen users gestartet wird? Und dadurch die einstellungen in deinem user ignoriert werden?
oder wird eventuell scdaemon mit dem parameter --options <fielpath> gestartet? Wodurch der process die einstellungen aus <filepath> liest anstelle der default datei.

Ich verwende dafür die User-Socket-Units welche vom Package bereit gestellt werden, das sieht dann so aus:

Code: Select all

● gpg-agent.service - GnuPG cryptographic agent and passphrase cache
     Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; static)
     Active: active (running) since Mon 2024-06-17 17:27:16 CEST; 12s ago
TriggeredBy: ● gpg-agent-ssh.socket
             ● gpg-agent.socket
             ● gpg-agent-extra.socket
             ● gpg-agent-browser.socket
       Docs: man:gpg-agent(1)
   Main PID: 3185 (gpg-agent)
      Tasks: 4 (limit: 33277)
     Memory: 1.9M (peak: 3.1M)
        CPU: 36ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gpg-agent.service
             ├─3185 /usr/bin/gpg-agent --supervised
             └─3187 scdaemon --multi-server

Wenn das dazu führt das die Standard-Konfigurationsdateien ignoriert werden wäre das ziemlich seltsam.

[firefly]

Oder gpg-agent wird im kontext eines anderen users gestartet?
Das wäre noch meine letzte vermutung das unter umständen scdaemon dadurch mehrmals läuft

Die systemd unit spezifiziert nicht den --homedir parameter, welcher verwendet wird, wenn der agent automatisch gestartet wird beim ersten verwenden von dem gpg cli tool.
Bei default nimmt gpg-agent ~/.gnupg an. Die frage ist ob dieser pfad im kontext der systemd unit überhaupt erfolgreich evaluiert werden kann.

[schmidicom]

Bei einem User-Unit kann das ganze nicht unter einem anderen Benutzer ausgeführt werden, das geht nur bei systemweiten Units.

[firefly]

Bei einem User-Unit kann das ganze nicht unter einem anderen Benutzer ausgeführt werden, das geht nur bei systemweiten Units.

Und? Trotzdem kann es sein, dass gpg-agent mehrmals gestartet werden kann...

[schmidicom]

Laut "ps -A" und dem KDE eigenen Systemmonitor wird sowohl "gpg-agent" als auch "scdaemon" nur einmal ausgeführt und das unter meinem Benutzer.
Das sieht dann hierarchisch so aus:

Code: Select all

systemd (root)
--- systemd (user)
     --- gpg-agent (user)
          --- scdaemon (user)

[firefly]

Hmm hab mittlerweile auch nen nitrokey 3 (3A Mini) und konnte das problem so nicht nachstellen.

Was ich nachstellen konnte, ist das gpg den key nicht findet via (gpg --card-status) in folgenden setup:

• gnupg ist mit usb support gebaut
• .gnupg/scdaemon.conf existiert nicht => scdaemon verwendet seinen eigenen ccid treiber
• pcscd ist gestartet
• gpg-agent läuft nicht
• pcsc-lite in der version 2.2.3 installiert (eigenes ebuild)
• app-crypt/ccid in version 1.5.4 installiert
• Key ist nicht angeschlossen

Wenn ich jetzt den Key anstecke und dann

gpg2 --card-status

ausführe, wird der key nicht angezeigt.
Selbst ein restart des pcscd hilft hier nicht.
Nur wenn ich pcscd stoppe und den gpg-agent neu starte (via gpgconf --kill gpg-agent) wird dann via gpg2 --card-status der key angezeigt.

Das ist auch soweit klar, da der pcscd sich den exklusiv zugriff auf den key nimmt und der scdaemon mit seinem eigenen ccid treiber keine zugriff darauf bekommt.

Jetz deaktiviere ich für den scdaemon den internen ccid treiber durch das setzen der option disable-ccid und das ganze via gpgconf

Code: Select all

echo disable-ccid:1:1 | gpgconf --change-options scdaemon

.gnupg/scdaemon.conf sieht dann wie folgt aus:

###+++--- GPGConf ---+++###
disable-ccid
###+++--- GPGConf ---+++### Mi 19 Jun 2024 21:04:52 CEST
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.

danach wurde gpg-agent gestoppt und pscsd gestartet

gpg2 --card-status findet den key.

Der key wird nur nicht gefunden, wenn pcscd in diesem kontext nicht läuft. (Und die socket activation unit auch gestoppt ist)

Kann es eventuell sein, dass pcscd bei dir überhaupt nicht lief, als das problem auftrat?
Nicht das eventuell die socket activation in manchen fällen nicht funktioniert. Z.b. nachdem pcscd sich aufgrund des auto-exit parameters selbst beendet hat.
Wobei es eventuell auch an der verwendeten pcsc-lite version liegen könnte.
Falls du die Lust hast ,könntest du das ganze mal mit der version pcsc-lite 2.2.3 testen ob das problem da immer noch auftritt wenn gnupg mit usb support gebaut ist?

[schmidicom]

Also der einzige Unterschied den ich zwischen deinem Versuch und meinem feststellen kann ist das bei dir die Optionen aus "scdaemon.conf" nicht ignoriert werden, ansonsten ist es doch genau das selbe Verhalten?

Vor der Benutzung von gpg als SSH-Key:

Code: Select all

○ pcscd.service - PC/SC Smart Card Daemon
     Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; preset: enabled)
     Active: inactive (dead)
TriggeredBy: ● pcscd.socket
       Docs: man:pcscd(8)

● pcscd.socket - PC/SC Smart Card Daemon Activation Socket
     Loaded: loaded (/usr/lib/systemd/system/pcscd.socket; enabled; preset: enabled)
     Active: active (listening) since Thu 2024-06-20 06:52:55 CEST; 1h 14min ago
   Triggers: ● pcscd.service
     Listen: /run/pcscd/pcscd.comm (Stream)
     CGroup: /system.slice/pcscd.socket

Jun 20 06:52:55 hq10pc150 systemd[1]: Listening on PC/SC Smart Card Daemon Activation Socket.

Code: Select all

○ gpg-agent.service - GnuPG cryptographic agent and passphrase cache
     Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; static)
     Active: inactive (dead)
TriggeredBy: ● gpg-agent-ssh.socket
             ● gpg-agent-extra.socket
             ● gpg-agent.socket
             ● gpg-agent-browser.socket
       Docs: man:gpg-agent(1)

Direkt nach der Benutzung von gpg als SSH-key:

Code: Select all

● pcscd.service - PC/SC Smart Card Daemon
     Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; preset: enabled)
     Active: active (running) since Thu 2024-06-20 08:10:21 CEST; 1min 2s ago
TriggeredBy: ● pcscd.socket
       Docs: man:pcscd(8)
   Main PID: 6233 (pcscd)
      Tasks: 9 (limit: 38138)
     Memory: 2.6M (peak: 3.9M)
        CPU: 82ms
     CGroup: /system.slice/pcscd.service
             └─6233 /usr/sbin/pcscd --foreground --auto-exit

Jun 20 08:10:21 hq10pc150 systemd[1]: Started PC/SC Smart Card Daemon.
Jun 20 08:10:21 hq10pc150 (pcscd)[6233]: pcscd.service: Referenced but unset environment variable evaluates to an empty string: PCSCD_ARGS

● pcscd.socket - PC/SC Smart Card Daemon Activation Socket
     Loaded: loaded (/usr/lib/systemd/system/pcscd.socket; enabled; preset: enabled)
     Active: active (running) since Thu 2024-06-20 06:52:55 CEST; 1h 18min ago
   Triggers: ● pcscd.service
     Listen: /run/pcscd/pcscd.comm (Stream)
     CGroup: /system.slice/pcscd.socket

Jun 20 06:52:55 hq10pc150 systemd[1]: Listening on PC/SC Smart Card Daemon Activation Socket.

Code: Select all

● gpg-agent.service - GnuPG cryptographic agent and passphrase cache
     Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; static)
     Active: active (running) since Thu 2024-06-20 08:10:21 CEST; 56s ago
TriggeredBy: ● gpg-agent-ssh.socket
             ● gpg-agent-extra.socket
             ● gpg-agent.socket
             ● gpg-agent-browser.socket
       Docs: man:gpg-agent(1)
   Main PID: 6228 (gpg-agent)
      Tasks: 4 (limit: 38138)
     Memory: 41.5M (peak: 61.4M)
        CPU: 402ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gpg-agent.service
             ├─6228 /usr/bin/gpg-agent --supervised
             └─6230 scdaemon --multi-server

Jun 20 08:10:21 hq10pc150 gpg-agent[6228]: using fd 3 for ssh socket (/run/user/1000/gnupg/S.gpg-agent.ssh)
Jun 20 08:10:21 hq10pc150 gpg-agent[6228]: using fd 4 for extra socket (/run/user/1000/gnupg/S.gpg-agent.extra)
Jun 20 08:10:21 hq10pc150 gpg-agent[6228]: using fd 5 for std socket (/run/user/1000/gnupg/S.gpg-agent)
Jun 20 08:10:21 hq10pc150 gpg-agent[6228]: using fd 6 for browser socket (/run/user/1000/gnupg/S.gpg-agent.browser)
Jun 20 08:10:21 hq10pc150 gpg-agent[6228]: listening on: std=5 extra=4 browser=6 ssh=3
Jun 20 08:10:21 hq10pc150 gpg-agent[6230]: scdaemon[6230]: detected reader 'Nitrokey Nitrokey 3 [CCID/ICCD Interface] 00 00'
Jun 20 08:10:22 hq10pc150 gpg-agent[6230]: scdaemon[6230]: sending signal 12 to client 6228
Jun 20 08:10:23 hq10pc150 gpg-agent[6230]: scdaemon[6230]: detected reader 'Nitrokey Nitrokey 3 [CCID/ICCD Interface] 00 00'
Jun 20 08:10:23 hq10pc150 gpg-agent[6230]: scdaemon[6230]: DBG: asking for PIN '||Bitte entsperren Sie die Karte CENSORED: CENSORED'
Jun 20 08:10:23 hq10pc150 gpg-agent[6258]: Caps Lock is locked: false

Und das scdeamon bei mir (aus welchem Grund auch immer) die eigene Konfigurationsdatei ignoriert konnte ich damit "fixen" in dem ich (ganu wie es auch Fedora macht) GnuPG ohne den eigenen CCID-Treiber baue.

[firefly]

Falls die config wirklich ignoriert wird dann lösch die mal und erstelle sie neu (nur mit disable-ccid) via gpgconf.

Ansonsten verwendete ich nicht den user systemd unit von gpg-agent, da gpg-agent automatisch gestartet wird, wenn der gpg prozess genutzt wird.
Eventuell liegt es auch daran.
Daher deaktiviere mal die socket activation unit und mach mal das gleiche wie ich es durchgefphrt habe.

[schmidicom]

Ich habe nur einen Nitrokey mit OpenPG-Smartcard-Funktion und den brauche ich für meine Arbeit in einem funktionsfähigen zustand.
Wenn ich irgendwann mal eine zweite OpenPG-Smartcard habe werde ich das gerne nochmal auf einem Gerät das ich nicht für die tägliche Arbeit brauche ausprobieren aber fürs erste bleibt mein Setup so wie es jetzt ist.