Bug 3006

Summary:

ssh and ssh-keygen always ask for PIN

Product:

Portable OpenSSH

Reporter:

Jakub Jelen <jjelen>

Component:

Smartcard

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED FIXED

Severity:

enhancement

CC:

djm

Priority:

Version:

8.0p1

Hardware:

Other

OS:

Linux

Bug Depends on:

Bug Blocks:

2988

Attachments:

Description	Flags
Proposed patch	none

Description Jakub Jelen 2019-05-10 19:18:35 AEST

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

Comment 1 Damien Miller 2019-05-31 14:05:48 AEST

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?

Comment 2 Jakub Jelen 2019-05-31 18:46:12 AEST

(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

Comment 3 Jakub Jelen 2019-09-11 22:21:17 AEST

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.

Comment 4 Damien Miller 2019-10-01 20:23:26 AEST

patch applied; will be in OpenSSH 8.1, due soon.

Comment 5 Damien Miller 2021-04-23 14:59:54 AEST

closing resolved bugs as of 8.6p1 release