For some reason, NSS won't always return a privk structure back to the client. The card still works nicely for signing (and hence authentication), but OpenSSH makes a bunch of assumptions on the privk being there. 1. ssh-keygen won't work. Preferably this tool would be modified to just read the public key, also removing the need to enter a PIN code. 2. Segfault upon completed authentication. This is more critical. The problem is line 201 in key.c: if (k->nss->privk->wincx != NULL) { Replacing it with this line gets things up and running: if (k->nss->privk != NULL && k->nss->privk->wincx != NULL) { I have no idea if I'm causing any leaks by this, but it avoids the crash at least.
Btw, I am looking into why this is happening. But feel free to dig in your end as well. :)
There is something weird in this analysis - the card cannot work fine for signing if NSS doesn't return privk for it. So for usable card the privk must be returned. But probably there are multiple keys on the card and for some (unusable) the privk is not returned and for some others it is. I'd suspect that not the privk but pubk conversion is failing. Of course the bug in the code you mention is real and your change is 100% correct.
openssh-4.7p1-4.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openssh'
(In reply to comment #2) > There is something weird in this analysis - the card cannot work fine for > signing if NSS doesn't return privk for it. So for usable card the privk must be > returned. But probably there are multiple keys on the card and for some > (unusable) the privk is not returned and for some others it is. I'd suspect that > not the privk but pubk conversion is failing. > You certainly earn your paycheck. Your guess was completely accurate. :) One key is successfully extracted, and ssh crashes when getting a second one. The call that fails is SECKEY_ConvertToPublicKey(privk); and the program then crashes when calling key_free(k);. > Of course the bug in the code you mention is real and your change is 100% correct. > Quite. But ssh-keygen is still confused by this card, claiming it cannot find anything useful. I used pkcs15-tool (from OpenSC) to extract the key, so it's very do-able. PS. I still haven't seen a reply from you on that mail I sent. I hope you got it this time.
So are there actually 2 private keys on the card or not? Could you try to insert some debug logs into the nsskeys.c:nss_find_privkeys() code and see what it extracts from the card and why it doesn't find the keys useful?
Yes, there seems to be four of them bound to the first PIN (which is how I assume OpenSC decided to group them for one token). I'll try to find some time to do some printf debugging.
openssh-4.7p1-4.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.