Douglas E. Engert wrote: > > > Nicolas Williams wrote: >> On Mon, Oct 06, 2008 at 01:44:34PM -0700, Anthony Scarpino wrote: >>>> Note that sc_pkcs11_get_mechanism_list is called with p11card=0x0. >>>> Ticket #181 gets around this. >>>> >>>> I have not tracked down the sshd and login problems yet. >>>> I am assuming that is related to no mechanism list. >>> Just a wild stab here.. If metaslot is enabled, it will retrieve a >>> list of mechanisms from all the providers. You may try disabling >>> metaslot, 'cryptoadm disable metaslot', to see if that helps.. > > Tried that still fails. No messages in syslog either.
I'd recommend using truss on the application.. For example, something like 'truss -p <sshd pid> -u libpkcs11:: opensc-pkcs11::'. You may need to add a fork option to truss as I'm not exactly sure how sshd does it's daemon insides.. > >>> >>>> Note that sshd should not be using the console user's >>>> smartcard for any crypto! >>> OpenSC and the smartcard are providers in PKCS#11. If it is >>> providing crypto to the system, it is available to be used. Granted >>> no one would ever want a smartcard to do the crypto ops, but there is >>> nothing in PKCS#11 to stop it.. >> >> Is there any way to provide a provider preference order so that >> smartcards are never used for crypto other than in relation to >> non-extractable keys? > > Good question. And to associate a provider with a user or session, > i.e. smart card at the console is only for the user at the console. > For private keys on a keystore you'd have to provide a PIN, so I'd say that's the easiest way.. That would limit the access to the keystore to a particular session that did a C_Login.. crypto operations are whatever the provider is exporting.. If it has it's own DES implementation and does not show that mechanism in the mechanism list, then it wouldn't be used.. Tony
