[This is a bug which applies equally to ssh-keygen and softhsm; this one is reported to softhsm] Description of problem: The softhsm module reports two slots available (0 and 1), even though only 0 exists. That makes ssh fail reading keys from softhsm. How reproducible: $ echo "directories.tokendir = ./db" >softhsm.conf $ echo "objectstore.backend = file" >>softhsm.conf $ mkdir db $ export SOFTHSM2_CONF=./softhsm.conf $ softhsm2-util --init-token --slot 0 --label test --so-pin 1234 --pin 1234 $ pkcs11-tool --module /usr/lib64/pkcs11/libsofthsm2.so -k --login --key-type rsa:1024 $ ssh-keygen -D /usr/lib64/pkcs11/libsofthsm2.so Result: cannot read public key from pkcs11 Expected result: The public key should be listed. The reason of failure is apparent in the following log from pkcs11-spy: http://paste.fedoraproject.org/242600/20663143/ ssh-keygen fails because slot 1 is listed as existing but C_OpenSession() fails on it.
Created attachment 1051376 [details] http://paste.fedoraproject.org/242600/20663143/
As far as I understand PKCS#11 2.40 this seems like a bug in ssh-keygen, not in SoftHSM. Token in slot 1 was not initialized yet and this is properly signalized by SoftHSM: The flag CKF_TOKEN_INITIALIZED in missing in output of C_GetTokenInfo() for the token 1. Applications should not attempt to use uninitialized tokens. This is the same situation as when you plug in a new card into card readed but the PIN for that card is not set yet. For this reason I'm moving the bug to OpenSSH.
Correct. I'm marking it though as duplicate because there is already a bug on openssh for that. *** This bug has been marked as a duplicate of bug 1241873 ***
Then please make sure that the explanation and other changes are copied over :-)
It is not needed because it is not the actual issue. The reason of the failure has been found to be different in openssh.
Petr, what are you writing makes sense. Thank you for clarification. This is new in v2.10 so I hope there will be no problem with compatibility. Filled upstream bug with proposed fix and attached also here.
Jakub, the patch looks okay. PKCS#11 2.10 is from 1999, so it is question if you want to support older spec or not. If you really need to then you can check CK_VERSION value in CK_FUNCTION_LIST structure to see if PKCS#11 version is sufficiently high. IMHO it is unnecessary.