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.
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.
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.
I think, this feature should be or standalone utility (which I prefer) or a library with a well defined api.
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
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.
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.
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.
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...
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?