bugzilla-daemon at mindrot.org
2021-Nov-05 14:46 UTC
[Bug 3359] New: -o BatchMode=yes and -o PKCS11Provider (with PIN) result in "pin required" on stderr
https://bugzilla.mindrot.org/show_bug.cgi?id=3359 Bug ID: 3359 Summary: -o BatchMode=yes and -o PKCS11Provider (with PIN) result in "pin required" on stderr Product: Portable OpenSSH Version: 8.8p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: allison.karlitskaya at redhat.com ~/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 at 127.0.0.2 -p 2201 Warning: Permanently added '[127.0.0.2]:2201' (ED25519) to the list of known hosts. [root at 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 at 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 at 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 at 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 at 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 at 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 at 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. -- You are receiving this mail because: You are watching the assignee of the bug.