HSM + OpenSC for ssh-keys - using pkcs11-lib without pin?

Nitrokey Generic
#1

Background: I am currently trying to automate some server processes and want that a special user is connecting via ssh from one server to the next. witout HSM I could use keys without a passphrase, so that a public key (only) login is possible. I now try to secure the private key by using the HSM.
I currently run into the trouble, that I can’t provide the user pin for the HSM when I am using the ssh configuration with “PKCS11Provider /usr/local/lib/opensc-pkcs11.so”
I could ignore the errors I get out of the library (C-GetAttributeValue failed: 18 ), but then I need to enter the UserPin. (The connection then works) .

Question: Is there trick to provide also the HSM User Pin to the library ? Maybe a special setting in opensc.conf ?

[Update] The errors “C-GetAttributeValue failed:18” are from keys on the HSM that could not be used with OpenSSH - strange behaviour of the opensc-pkcs11.so lib (should not throw an error)

#2

The is no such mechanism to preset the PIN. You could need to create your own version of OpenSC to has such a mechanism implemented.

#3

Thanks for the confirmation. I was afraid hearing that. Also some features are not working ( e.g. limitations of no of keys to read. ) :banana: software

#4

It is possible. Import the pkcs11 library in to the SSH agent rather than specifying directly in the ssh client config. It requires a manual touch to get the agent set up but subsequent connection attempts will not prompt e.g.

$ ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
Enter passphrase for PKCS#11:
Card added: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
#5

The pin is a bit of a pain on this system. On a Mac could would be able to let KeyChain safety handle the pin.
There is also a program/script called “keychain” for other OS’s , but has a focus on the pass-phrase for ssh. While the pass-phrases could be handled by the ssh-agent after the first load, the pin is requested every time you reach the pkcs11-lib. So in generic it would need either

  • a library that could handle a pin
  • a HW that would allow to disable the pin (by request - e.g. when called through api )
  • at least a HW that could setup a pin lifettime

Also the OpenSC is not working as described: should not read all keys and then additional complain about keys that will not work ( as they are not designed for ssh - but should not have been read )

To be honest: I have now de-installed all HW keys - the balance between advantage and dis-advantages is today on the second as the supporting software is “Bananas” (ripen on customer side)

#6

(I found this only now, sorry)

I think your major source of problems is ssh software you are using. The error message you have complained earlier comes from openssh https://github.com/openssh/openssh-portable/blob/dee22129bbc61e25b1003adfa2bc584c5406ef2d/ssh-pkcs11.c#L334

There are two issues here:

  • PKCS#11 is a generic crypto library and opensc-pkcs11 library has no idea that it is SSH client that tries to use them. SSH client should understand the keys it is getting and filter out those which are not supported from some reason.
  • PKCS#11 providers and OpenSC are just libraries, they offer no persistent something that manages access to cryptographic tokens. If the operating system offers something better that has persistent state - then yes, it is the way to go to have a token permanently logged in with a PIN given at startup. Given the current openssh+opensc+pkcs11 landscape I’d not expect this to be fixed anywhere except the client application. Maybe ssh agent could modified to do what you require.

In all cases, it might be worth having a look at other SSH implementations like Tectia, maybe their crypto token support is better.