[This is a bug which applies equally to ssh-keygen and softhsm; this one is reported to ssh-keygen] 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. It should have continued normally and listed the available keys in slot 0.
As I browse through the code, it looks like the algorithm is made the way it doesn't fail if it reads at least one key. From the fpaste I see it didn't event found the first key in the first slot. It looks like it must be marked some other way than expected by openssh.
Ok, it seems that the issue is the following. The only object in the token is a private key and openssh does look for stored public keys. Some tokens automatically store a public key when you store a private key, but others (softhsm) not. Possible fixes: 1. openssh looks for private keys as well as public keys in the token, and if found extract the public key from the private . 2. When generating with p11tool, copy the printed public key and store in the token explicitly (have not tried and may not work) 3. When generating with p11tool, copy the printed public key, generate a certificate out of it and store in the token explicitly. That works, but is utterly ugly.
*** Bug 1241874 has been marked as a duplicate of this bug. ***
I'm not quite sure, but p11tool writes, that there is object called "Public key": $ p11tool --list-all --login "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a65483728c0ce9b;token=test" Token 'test' with URL 'pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a65483728c0ce9b;token=test' requires user PIN Enter PIN: Object 0: URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a65483728c0ce9b;token=test;object-type=public Type: Public key Label: Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; ID: Object 1: URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a65483728c0ce9b;token=test;object-type=private Type: Private key Label: Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_SENSITIVE; ID: Otherwise: > 1. openssh looks for private keys as well as public keys in the token, and if found extract the public key from the private . It shouldn't be preferred way to get private keys out of the token (even soft, shouldn't it?). 2. When generating with p11tool, copy the printed public key and store in the token explicitly (have not tried and may not work) This would be great to try. 3. When generating with p11tool, copy the printed public key, generate a certificate out of it and store in the token explicitly. That works, but is utterly ugly. This is how the Yubikey does it if I understand it well I wasn't yet trying to connect with softhsm. During the first step (optional) is send public key just to make sure if it is even possible to authenticate to remote account. For the second step, signing, you don't need the public key, so I think it can work even without having public key on smart card, but you need to get public key at least somehow.
(In reply to Jakub Jelen from comment #4) > I'm not quite sure, but p11tool writes, that there is object called "Public > key": > $ p11tool --list-all --login > "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project; > serial=6a65483728c0ce9b;token=test" > Token 'test' with URL > 'pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project; > serial=6a65483728c0ce9b;token=test' requires user PIN > Object 0: > URL: > pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project; > serial=6a65483728c0ce9b;token=test;object-type=public > Type: Public key > Label: > Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; > ID: In my case I generated the private key without CKA_PRIVATE so I could see the private key but not the public key which was automatically created with CKA_PRIVATE. In that case, if openssh doesn't see that public key, the issue is that it needs to login first and for some reason it doesn't (that's what the CKA_PRIVATE flag mean).
OK. Thank you for your help with this issue. I can't create keys without CKA_PRIVATE. If I force ssh-keygen to login to SC, it fails because the ID is zero ... not very convenient. Another bug for openssh attached.
The above mentioned upstream bugs (2427, 2429) were covered in openssh-7.0 release. It is out for some time and will be available in Fedora 23. The only thing missing is reading public key from private one, which has its own upstream bug and requires some more consideration, but it is not part of this report. Closing now.