Bug 2530

Summary: Client does not differentiate between more keys on Smart card, signs always with first one
Product: Portable OpenSSH Reporter: Jakub Jelen <jjelen>
Component: SmartcardAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED INVALID    
Severity: enhancement CC: djm
Priority: P5    
Version: 7.1p1   
Hardware: Other   
OS: Linux   

Description Jakub Jelen 2016-01-22 23:01:29 AEDT 
Based on the report in our bugzilla [1] (though on older version and with different use case), I can reproduce the same behaviour with two different key pairs on smartcard (opencryptoki softtoken), when only the second is accepted.

This is caused by the fact, that when the public key is read from the card, its CKA_ID is not stored alongside with the public key and ssh later does not know which key use for signing (use the first one implicitly, since it is first result of search).

So far, the key is identified by its pkcs11 provider library [2] and by flag SSHKEY_FLAG_EXT [3], which is obviously not enough (see the self-explaining comment /* XXX */ [2]).

Fortunately, similar question was asked before by different people and there is RFC7512 describing PKCS#11 URI scheme, which quite suits these needs. It can overgrow into ugly monstrosity, but for our case should be enough to note the id (CKA_ID) in scheme.

Integration of this idea into openssh would require some changes, which are more complex to do them without discussion as a patch for bugzilla. If you feel this would be useful, I would like to hear upstream acknowledgement.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1280422
[2] https://github.com/openssh/openssh-portable/blob/master/ssh.c#L1994
[3] https://github.com/openssh/openssh-portable/blob/master/ssh-pkcs11.c#L541
[4] https://tools.ietf.org/html/rfc7512
Comment 1 Damien Miller 2016-02-11 12:46:07 AEDT 
The upstream bug link looks wrong, it points to "Review Request: rpg - RPM Package Generator" that doesn't appear ssh-related to all
Comment 2 Jakub Jelen 2016-02-11 19:19:08 AEDT 
Sorry, the link should be [1]. I have no idea how did it happened.

The original case, as it is described above, seems to be working with upstream version. For the first time I managed to create two keys with the same ID, which is obviously wrong configuration.
I didn't want to comment again until I will get the answer from our tester who reported the issue with certificates. It might be the same problem and then this is not a bug or something different and I will update you as soon as I will know more.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1299994
Comment 3 Jakub Jelen 2016-09-02 21:54:04 AEST 
Sorry, this is not a bug in openssh. The report was very vague and it showed up as a problem in different part of the chain.
Comment 4 Damien Miller 2021-04-23 15:09:15 AEST 
closing resolved bugs as of 8.6p1 release