Bug 543358

Summary: [PATCH] Ability to unblock PIN
Product: [Fedora] Fedora Reporter: Pierre Ossman <ossman>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: jchadima, mgrepl, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-12 07:35:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 537411    
Bug Blocks:    
Attachments:
Description Flags
0001-Add-mechanism-to-unblock-a-passphrase-that-has-been.patch none

Description Pierre Ossman 2009-12-02 09:11:20 UTC 
This patch adds the ability to OpenSSH to unblock a PIN if it detects that it has been locked.

There is one big gotcha though. PKCS#11 does not map properly to ISO 7816 (the smart card standard), resulting in the rather absurd situation of it not being possible to implement card unblocking in a clean way on top of most smart cards. I've tested this patch on top of OpenSC with an hack to work around this deficiency in the standard, and the patch here has some quirks (with comments) as a result of that.
Comment 1 Tomas Mraz 2009-12-02 12:45:23 UTC 
I do not quite think this code belongs to openssh. For unblocking PINs there should be a separate utility which does this and then the smartcard can be used with openssh again.
Comment 2 Pierre Ossman 2009-12-02 12:54:08 UTC 
There is a point to avoiding duplication of functionality, yes. For us it was still convenient this way as many cards do not expose information to determine if the card is locked beforehand. It was then natural to embed the unblocking functionality into the application that first got the error. It also means that SSH can continue connecting and you do not need another invokation.
Comment 3 Jan F. Chadima 2009-12-04 11:40:48 UTC 
I think, this feature should be or standalone utility (which I prefer) or a library with a well defined api.
Comment 4 Bug Zapper 2010-03-15 13:24:59 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Jan F. Chadima 2010-05-12 07:35:51 UTC 
the nss keys support is discontinued, there is another ssh-agent module called ssh-pkcs11-helper for the smartcard support. The patch is obsolete now.
Comment 6 Pierre Ossman 2010-05-12 07:54:47 UTC 
I'm confused. Why are you closing the bugs if the NSS support is just temporarily removed? This bug and those like it are still relevant once the patch is ported to the current upstream.
Comment 7 Jan F. Chadima 2010-05-12 11:25:22 UTC 
Nss support is replaced by the upstream one, if no one write the nss again, we will continue with the upstream's solution.  The sources of the pubkey auth are radically changed. The only way how to continue in nss based pubkeys is to provide a ssh-agent's backend. In the case that anybody do it, this backend will be different code from the current nss support with another needs and another "bugs". This is why.
Comment 8 Pierre Ossman 2010-05-12 11:38:43 UTC 
That's a big let-down for us as we need the approach of "ssh" being self contained and able to do everything by itself. If you guys are no longer interested in that design, then I guess we also need to re-evaluate the use of NSS...
Comment 9 Jan F. Chadima 2010-05-12 12:01:22 UTC 
Problem is that upstream does not like nss. They decidedet between nss and openssl and choose the backend based on openssl. I've not yet test it, but from the references it seems it works. It is in all newer fedoras. Can you try it, if it will work for you?