~/src/openssh-portable (master)> git describe
V_8_8_P1-67-g343ae252

This is an older bug, however, and has been in (at least) a couple of released versions of openssh, including 8.7p1 and 8.8p1.

In the cockpit CI/testing framework we use ssh to access our VM images.  The commandline that we use for accessing the VM is something like this:

        ssh -p 2201
            -o StrictHostKeyChecking=no
            -o UserKnownHostsFile=/dev/null
            -o IdentitiesOnly=yes
            -o BatchMode=yes
            -o LogLevel=ERROR
            -l root 127.0.0.2
            -i /var/home/lis/src/bots/main/machine/identity
            true

Additionally, in my ssh_config, I have a PKCS11 token configured:

        PKCS11Provider /lib64/opensc-pkcs11.so

When the above commandline runs, I see this output on stderr:

pin required
C_FindObjectsInit failed: 179
C_FindObjectsFinal failed: 179
C_FindObjectsInit failed: 179
C_FindObjectsFinal failed: 179


That turns out to be caused by the fact that my PKCS11 token has a PIN and that the pin-reading code (reasonably) doesn't work in BatchMode.  However, the VM in question doesn't contain my PKCS11 token's public key in authorized_keys, and sshing to this VM would never actually ask for the PIN.

The code in question is found in pkcs11_open_session() in ssh-pkcs11.c:

        login_required = si->token.flags & CKF_LOGIN_REQUIRED;

        /* fail early before opening session */
        if (login_required && !pkcs11_interactive &&
            (pin == NULL || strlen(pin) == 0)) {
                error("pin required");
                return (-SSH_PKCS11_ERR_PIN_REQUIRED);
        }


Here are some commandlines run against the current git version of openssh-portable.  I use -F/dev/null to show that this is independent of my config.

No problems:
~/src/openssh-portable (master)> ./ssh -F/dev/null -i ~/.config/ssh/cockpit-identity -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@127.0.0.2 -p 2201
Warning: Permanently added '[127.0.0.2]:2201' (ED25519) to the list of known hosts.
[root@fedora-35-127-0-0-2-2201 ~]# 


Also no problems, with BatchMode enabled:
~/src/openssh-portable (master)> ./ssh -F/dev/null -i ~/.config/ssh/cockpit-identity -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@127.0.0.2 -p 2201 -o BatchMode=yes
Warning: Permanently added '[127.0.0.2]:2201' (ED25519) to the list of known hosts.
[root@fedora-35-127-0-0-2-2201 ~]# 


Also no problems, with PKCS11Provider specified:
~/src/openssh-portable (master)> ./ssh -F/dev/null -i ~/.config/ssh/cockpit-identity -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@127.0.0.2 -p 2201 -o PKCS11Provider=/lib64/opensc-pkcs11.so
Warning: Permanently added '[127.0.0.2]:2201' (ED25519) to the list of known hosts.
[root@fedora-35-127-0-0-2-2201 ~]# 


But the combination is problematic:
~/src/openssh-portable (master)> ./ssh -F/dev/null -i ~/.config/ssh/cockpit-identity -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@127.0.0.2 -p 2201 -o PKCS11Provider=/lib64/opensc-pkcs11.so -o BatchMode=yes
pin required
Warning: Permanently added '[127.0.0.2]:2201' (ED25519) to the list of known hosts.
[root@fedora-35-127-0-0-2-2201 ~]# 


Note that in any of the above cases, I never would have actually been asked for the PIN, and the PIN is never required to access the VM.  The "pin required" error output is superfluous.


Note also: the current git version of openssh-portable only outputs "pin required", and not the other messages (despite them being present in the source).  The other messages are present on the ssh package on my distribution, Fedora 35:

openssh-8.7p1-2.fc35.x86_64

I've checked the git tag V_8_7_P1 and it also only prints "pin required", so it seems that Fedora is including some patch which is making this problem even worse.  I'll chase that up separately.


There is also a (potential) additional bug here.  The

  -o IdentitiesOnly=yes

option included on the commandline doesn't seem to "help" this problem, despite the manpage documenting this option as using only explicitly-configured keys, "...even if ssh-agent or a PKCS11Provider or SecurityKeyProvider offers more identities".  With -o IdentitiesOnly=yes specified it's surprising that we enter the PKCS11 code at all.