Possibly, it could be done with pam_exec http://linux-pam.org/Linux-PAM-html/sag-pam_exec.html
developing a simple executable (or even small shell script).

It may be simpler if we can enhance scdaemon to have an option for PKAUTH, say, --challenge-response, so that it generates a challenge and verify signature internally.

Here is an experimental shell script for testing:

It doesn't support all possible use cases, but some, when popup of pinentry is OK.

It is not good for login manager and screen lock (when unlock), because use of GUI pinentry is not relevant.

Improvements are needed for:

• Not using gpg-connect-agent (through gpg-agent), but connect scdaemon directly, by assuan protocol
• It should accept "INQUIRE" of assuan protocol, for PIN interaction
• Then, user interaction (asking PIN, or asking selection of keys) should be done stdio/stdout, so that it can be through PAM

BTW, there are various use cases for authentication(s), it is better to focus on the part of device and crypto (USB Token and scdaemon).

The rest should be handled by PAM configuration.

• if it can skip usual passphrase authentication
• if it's two factor authentication (that is, along with usual passphrase authentication)
• if it can be used for a session by single time input of passphrase (PIN of USB token == login passphrase); enable USB token at the start of a session

More things to be considered:

• How to connect scdaemon
• How to invoke scdaemon

If it is compatible to Poldi, it is:

• It depends on use case of authentication
  • For login authentication, it is by system, root
    • Invoke scdaemon spawing a process
  • For sudo/screen lock, it is by a user in question
    • Ask gpg-agent for the socket name to scdaemon
      • if no scdaemon, it is invoked by gpg-agent, by asking the sockent name
    • connect to that socket

I write a prototype in Python using pyassuan:

It is used like:

$ python3 scd_validate.py -v /run/user/1000/gnupg/S.scdaemon
Please unlock the card
-> <USERS PIN INPUT>
$ 

Hit RET means cancelling unlocking the card.

Wrote a pam module which interacts a user for auth:

And updated scd_validate2.py:

This is the one for login authentication (which invokes scdaemon to authenticate, instead of connecting by socket).

Using the pam_exec2.so above, I configured /etc/pam.d/lightdm by:

--- /etc/pam.d/lightdm.bak	2022-05-17 17:52:50.362767660 +0900
+++ /etc/pam.d/lightdm	2022-05-17 17:53:02.090916824 +0900
@@ -7,7 +7,11 @@
 session      required pam_env.so readenv=1
 session      required pam_env.so readenv=1 envfile=/etc/default/locale
 
-@include common-auth
+# @include common-auth
+auth	[success=1 default=ignore]	pam_exec2.so log=/tmp/x1 /usr/bin/python3 /home/gniibe/work/scd_validate5.py -v
+auth	requisite			pam_deny.so
+auth	required			pam_permit.so
+
 
 -auth  optional pam_gnome_keyring.so

Then, it works as expected.

NOTE that when you change the PAM configuration file under /etc/pam.d/, you should have another terminal by root (for example, with a virtual console terminal), so that you can change back it even if failure. (Or else, your system will have no way to recover.)

This is updated version of gpg-auth, which clears the authentication state before trying PKAUTH.
Access is controlled by ~/.ssh/authorized_keys.

The exit status is 0 (true), when success. 1 (false) when somthing wrong.

It works with GnuPG 2.3.5 or later, when a user can use scdaemon through gpg-agent.

This may be useful for a user to restrict use of some program only with the card/token.

With cmatrix command and pinentry-gtk2, I now do experiment with this script:

By the command line:

gnome-terminal --hide-menubar --window --full-screen -- ./exp-lockscreen.sh

it is possible for the full screen terminal to occupy the whole display.

A user can stop cmatrix screen saver, by typing a key. Then, it invokes gpg-auth2.sh script.

I think that if this 'screenlock' runs just after logging-in, it is virtually login with an authentication using a card/token, with no PAM configuration.

I added the last line, to recover tty state:

Note that this doesn't work if pinentry is pinentry-gnome3. pinentry-qt works well, too, because it supports curses fallback.

A concrete example use case in my mind is:

• (Usual display manager (authentication by password or no-password))
• session starts with "locked" state of screen
  • In the beginning, user needs to "unlock" the screen, by scdaemon authentication
• (optionally, if needed) our-own-screen-locker should detect device removal, then, automatically locks the screen
• our-own-screen-locker should detect idling user session, then, disabling the card, automatically locks the screen
• our-own-screen-locker does authentication by scdaemon when it unlocks the screen

I did some research about scree lockers (xtrlock, slock, swaylock, etc.).

I think that writhing Authentication Module would be a good option, for now.
https://github.com/google/xsecurelock

Wrote a shell script for xsecurelock's authproto (helper executable):

In the script, we specify another script (so, please edit the path):

I tested by:

export XSECURELOCK_AUTHPROTO=/home/gniibe/work/gpgauth/authproto-gpg-auth.sh

xsecurelock

Through the dialog by xsecurelock, entering PIN, it authenticates a user by smartcard/token.

I changed gpg-connect-agent (added --unbuffered option) so that we can write shell script interacting gpg-agent.

See https://github.com/google/xsecurelock/blob/master/helpers/authproto.h
for the interaction between xsecurelock and the helper.

Updated (with T6012):

It prompts a user for the insertion of a device, if it's not available.

Updated:

Now, it also supports a reader with pinpad.

Procedure for testing:

1. Install xsecurelock
2. Put authproto-gpg-auth3.sh, handle-confirm.sh and handle-passphrase.sh somewhere. Don't forget to have +x mode.
3. Edit authproto-gpg-auth3.sh so that scripts works (the paths of handle-confirm.sh and handle-passphrase.sh.
4. Set environment variable XSECURELOCK_AUTHPROTO. For example, I do:

$ export XSECURELOCK_AUTHPROTO=/home/gniibe/work/gpgauth/authproto-gpg-auth3.sh

5. Run xsecurelock command

5.1 Touch a key, then dialog shows up.
5.2. It shows a keygrip for key, when it's not yet inserted, to prompt the device insertion. After insertion, type RETURN. Or type ESC to cancel the device with the keygrip.
5.3 It shows the keygrip, then proceeds to PIN input by keyboard (if it's not with pinpad).
5.3.1 (keyboard) Type ESC to cancel the device, if there are multiple candidates, it proceeds to next device.
5.3.2 (keyboard) Type PIN, then it unlocks the screen.
5.4 It shows the keygrip, then proceeds to PIN input by pinpad on a cardreader.
5.4.1 (pinpad) Cancel PIN input by "X" cancel button on a cardreader.
5.4.2 (pinpad) Put PIN by pinpad, then it unlocks the screen.

Not possible in current scheme: Canceling by keyboard when it asks PIN by pinpad.

While playing with your scripts I figured that it would be useful to enhance the KEYINFO command. With
rG989eae648c8f3d2196517e8fc9cce247b21f9629 we could now

"- KEYINFO --list"
"+ KEYINFO --list --need-attr=Use-for-ssh:"

and only ssh keys will be considered. The attribute needs to be set, though. A script to convert sshcontrol to the new attributes would also be nice to have.

Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.

Lines in /etc/pam.d/login can be modified like:

# Standard Un*x authentication.
#@include common-auth
auth [success=1 default=ignore] pam_authproto.so /usr/local/libexec/gpg-auth --use-scdaemon-directly
auth	requisite			pam_deny.so
auth	required			pam_permit.so
auth	optional			pam_cap.so 
# ######################

I tested and it works for me (normal token and card with pinpad reader).

Here are pam_authproto.c with Makefile, so that you can compile it with libpam:

Testing gpg-auth : There are two different use cases

• test with xsecurelock for screen lock
• test with pam-autoproto for login / gdm / etc.

Preparation

• Configure your token/card, so that you can use it with GnuPG
  • Check it's availability by gpg-card or gpg --card-status, if token/card can be seen by GnuPG
  • You should have "authentication key" on your token/card
• Configure your SSH, so that you can login to the host by the "authentication key" on the token/card
  • There should be your key listed in ~/.ssh/authorized_keys
  • You should be able to login by token/card
    • Please test: ssh localhost and make sure it works

Test with xsecurelock

1. Build and install GnuPG (2.3, from master)
   • gpg-auth should be installed
2. Set environment variable XSECURELOCK_AUTHPROTO. For example, I do:
   
   $ export XSECURELOCK_AUTHPROTO=/usr/local/libexec/gpg-auth
3. Run xsecurelock command

3.1 Touch a key, then dialog shows up, asking your PIN for token/card
3.2 (keyboard) if it's not with pinpad cardreader
3.2.1 (keyboard) Type ESC to cancel the token/card, if there are multiple candidates, it proceeds to next device.
3.2.2 (keyboard) Type PIN, then it unlocks the screen.
3.3 (pinpad) if it's with pinpad cardreader
3.3.1 (pinpad) Cancel PIN input by "X" cancel button on a cardreader.
3.3.2 (pinpad) Put PIN by pinpad, then it unlocks the screen.
3.3.3 (pinpad) Note that: you cannot cancel the dialog by keyboard input

If it works, you can configure xsecurelock to use gpg-auth.

Test with login (for example) using PAM

1. gpg-auth should be available
2. pam-authproto should be installed (download, extract by tar, make, make install (modify SECUREDIR if needed))
3. Edit (by root) /etc/pam.d/login or some configuration file for login. Comment out common-auth to be replaced by... like:

# Standard Un*x authentication.
# @include common-auth
auth [success=1 default=ignore] pam_authproto.so /usr/local/libexec/gpg-auth --use-scdaemon-directly
auth	requisite			pam_deny.so
auth	required			pam_permit.so

4. Don't logout from your Graphical Session (if you do some severe mistake, it may be possible you lose a way to login)
5. Release your token/card from control by scdaemon of your session. Simply do:

$ gpgconf --kill scdaemon

6. Using a virtual console (CTRL-ALT-F1 or F2...), try testing login
7. Switch back to the graphical session (CTRL-ALT-F7, for example)
8. Note that you can use gdm and lightdm, but sddm doesn't work well.
   • when you test gdm or lightdm, you should have another session in a virtual console, so that you keep a way to control your computer, even with wrong configuration.