Prior OpenSSH 8.0, the ssh and ssh-keygen were able to retrieve public keys from PKCS#11 modules without asking for a PIN. The PIN prompt was delayed to the reading of private key and to the private key operation, once the public key check succeeded. The OpenSSH 8.0 asks for the PIN as soon as it loads the pkcs11 module, which is annoying. It is caused by the commits 7a7fdca and 41923ce attempting to handle unreadable public keys without login, which should be handled rather as described in the bug #2430. I propose to revert these two patches and merge a patch from #2430. For more information, see the mail thread: https://lists.mindrot.org/pipermail/openssh-unix-dev/2019-April/037759.html
So I don't understand what is going wrong here - all the login cases I can see occur either inside blocks that test CKF_LOGIN_REQUIRED or are in the signature path. Is CKF_LOGIN_REQUIRED not a sufficient indicator? Also, wouldn't reverting the patches mentioned in your email undo the changes to support readers with integral pinpads?
(In reply to Damien Miller from comment #1) > So I don't understand what is going wrong here - all the login cases > I can see occur either inside blocks that test CKF_LOGIN_REQUIRED or > are in the signature path. > > Is CKF_LOGIN_REQUIRED not a sufficient indicator? This flag is the source of confusion. It does not say the login is required for all actions, but for *some* cryptographic functions [1]: > True if there are some cryptographic functions that a user MUST be logged in to perform For most of the cards, the login is not needed for listing public keys and certificates (for example from ssh-keygen or from pubkey authentication tries without signature). > Also, wouldn't reverting the patches mentioned in your email undo > the changes to support readers with integral pinpads? No, the support for readers with pinpad is in pkcs11_login() (or in pkcs11_login_slot() after the patch from bug #2430), which either defers the login to the pinpad or asks pin from user. The pkcs11_open_session() should really keep its semantics as described in the comment above it -- if the pin is null, no login should be performed. What was the issue in the bug #2652 was the same issue as in bug #2430 -- the public objects are not visible without login, as shown in the following comment (-l switch in pkcs11-tool is a request to login), regardkess the pinpad: https://bugzilla.mindrot.org/show_bug.cgi?id=2652#c11 I hope it is more clear. If not, please ask further. [1] http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html#_Toc416959687
Created attachment 3327 [details] Proposed patch The bug #2430 is already resolved and therefore I think we can apply the attached patch (which is basically reverting the previously interoduced forced login). Please, let me know whether there is still something unclear.
patch applied; will be in OpenSSH 8.1, due soon.
closing resolved bugs as of 8.6p1 release