No PIN asked for with libpam-poldi

[Franck Routier (Personnel)]

Thanks for helping me interpret this logs !
So I activited logs one component after the other, and finally the 
problem was simply in libpam-poldi configuration...
The opening parenthesis (before "public-key" keyword) was missing in the 
key file :

public-key
(rsa etc...

Well... embarrassing :-)
But it least I progressed in the understanding of this stack !

Thanks again,
Franck

Le 12/11/2025 à 22:32, Ingo Klöcker a écrit :
> On Mittwoch, 12. November 2025 22:07:15 Mitteleuropäische Normalzeit Franck
> Routier (Personnel) via Gnupg-users wrote:
>> I managed to get some logs from gpg-agent. No sure how to interpret this
>> however. No obvious error I can spot (but I don't know what to look for):
>>
> [...]
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK Pleased to meet
>> you, process 16072
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- SCD GETINFO socket_name
>> 2025-11-12 22:00:31 gpg-agent[16056] no running /usr/lib/gnupg/scdaemon
>> daemon - starting it
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: agent_flush_cache (pincache only)
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK GNU Privacy
>> Guard's Smartcard server ready
>> 2025-11-12 22:00:31 gpg-agent[16056] first connection to daemon
>> /usr/lib/gnupg/scdaemon established
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
>> /run/user/1000/gnupg/S.scdaemon
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: additional connections at
>> '/run/user/1000/gnupg/S.scdaemon'
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> OPTION event-signal=12
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
>> /run/user/1000/gnupg/S.scdaemon
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> D
>> /run/user/1000/gnupg/S.scdaemon
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- BYE
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK closing connection
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> RESTART
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>>
>> Trying to sudo at 22:00:31
>> Before is just normal gpg-agent start (?).
>>
>> Any idea ?
> What we see above for chan_12 looks like the communication between libpam-
> poldi (?) and gpg-agent. libpam-poldi asks scdaemon via gpg-agent for its
> socket (SCD GETINFO socket_name). Then for chan_13 we see how gpg-agent talks
> to scdaemon (that it first started) to ask scdaemon for its socket (GETINFO
> socket_name) which replies with /run/user/1000/gnupg/S.scdaemon and OK. I
> don't understand the "additional connections ..." message and the other chat
> on chan_13. In any case, on chan_12 gpg-agent sends the socket back to libpam-
> poldi which then ends the connection with BYE.
>
> My guess is that libpam-poldi asked gpg-agent for the socket of scdaemon so
> that it can subsequently talk to scdaemon directly. You might want to add
> 'debug ipc' to scdaemon.conf to capture the communication of scdaemon with
> other processes.
>
> Regards,
> Ingo
>
>> Le 07/11/2025 à 18:36, Franck Routier (Personnel) via Gnupg-users a écrit :
>>>> Typo? In any case, avoid the weird debug-level setting. Use "debug ipc"
>>>> instead. Also set log-file so that the logs don't end up in some random
>>>> place (or nowhere).
>>> Yes typo. I removed it alltogether for now:
>>>
>>> pinentry-program /usr/bin/pinentry-qt
>>> enable-ssh-support
>>> ttyname $GPG_TTY
>>> default-cache-ttl 60
>>> max-cache-ttl 120
>>>
>>>> Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to
>>>> start because there's no window manager running. Try using
>>>> pinentry-curses or pinentry-tty instead of pinentry-qt if you are anyway
>>>> using the terminal.>
>>> In fact gpg-agent seems to be able to call pinentry-qt, as when I use
>>> pass or browserpass, it works and I get a pretty pinentry window...
>>>
>>> That said, switching to pinentry-tty does not solve the problem with pam.
>>> In fact I can see pinentry-tty working with pass and failing with sudo
>>> in the same terminal session:
>>>
>>> $ pass perso/ameli.fr
>>> Please unlock the card
>>> Number: 10 955 601
>>> Holder: Franck Routier
>>> PIN:
>>> *************************
>>> $ sudo su
>>> Insert authentication card for user `franck'
>>> Trying authentication as user `franck'...
>>> [sudo] password for franck:
>>>
>>> Franck
>>>
>>> _______________________________________________
>>> Gnupg-users mailing list
>>> Gnupg-users at gnupg.org
>>> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/ca0f6712/attachment-0001.html>