| Summary: | ssh-keygen should allow to login before reading public key from smart card | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Jakub Jelen <jjelen> | ||||||||
| Component: | Smartcard | Assignee: | Assigned to nobody <unassigned-bugs> | ||||||||
| Status: | CLOSED FIXED | ||||||||||
| Severity: | enhancement | CC: | djm, peter.sj.magnusson | ||||||||
| Priority: | P5 | Keywords: | pkcs11 | ||||||||
| Version: | 6.9p1 | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | Linux | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 2988 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Jakub Jelen
2015-07-16 18:25:21 AEST
Wouldn't all the tools that use PKCS#11 need an additional switch? I.e. ssh and ssh-add in addition to ssh-keygen. Is this behaviour common in real tokens? My experience is quite limited, but I've not seen tokens refuse to provide at least the public key or cert without login. Yes. ssh-add would require same change. I forgot.
I didn't get so far with ssh. But it does Login, because it requires to unlock the private key to sign challenge. I'm not familiar with the pkcs11 code in ssh yet, but I don't think it opens session twice, once for public key and then for signing challenge.
> Is this behaviour common in real tokens?
I was told that it is not uncommon, but I also don't have experience about this. I will ask collegue if he can estimate or provide some examples.
These cards exists for example as National IDs (example Belgium from colleague's experience [1]). Unfortunately, wiki does not explicitly mention mechanism of handling public key. But it can be found for example in this article [2]. It is often enforced as a policy by generator/distributor of the cards rather then by user, in nation-wide or corporate scenarios. Solution with switch would be probably more familiar, but it would be great to have one switch, unlike it differs with switches shared pkcs11 library: ssh -I *.so ssh-keygen -D *.so ssh-add -s *.so I can think of -U as "Unlock", which is unused on all three of them. Handling this inside ssh tools would reqeuire some design decisions how to make it clear, secure and transparent even for readers keypads. [1] https://en.wikipedia.org/wiki/Electronic_identity_card#Belgium [2] http://wiki.yobi.be/wiki/Belgian_eID#pkcs11-tool This issue could be resolved by the PKCS#11 URIs (bug #2817), which allow the specify the PIN or PIN source (not yet implemented in the referenced bug), which might be a hint for the tool to perform Login before trying to list objects. But over the recent years, I did not see almost any cards that would have this issue so I don't think this is very important now. Created attachment 3130 [details] Try to login, if the first attempt does not return any keys After discussion in bug #2652, we have a real use case as I proposed over two years ago and therefore we need to figure out how to solve this problem (in the #2652 complicated by the use of "pinpad" reader keyboard). The initial proposal of introducing a new command line option to both ssh-keygen and ssh seems too intrusive. The ssh-add does NOT need any modification, because it already does the login while adding a card (it is the only time when agent has a PIN). It can be simply verified with the following reproducer with softhsm2: $ SOPIN="12345678" $ echo "directories.tokendir = .tokens/" > .softhsm2.conf $ mkdir ".tokens" $ export SOFTHSM2_CONF=".softhsm2.conf" $ PIN="123456" $ softhsm2-util --init-token --slot 0 --label "SC test" --so-pin="$SOPIN" --pin="$PIN" $ P11LIB="/usr/lib64/pkcs11/libsofthsm2.so" $ pkcs11-tool --keypairgen --key-type=RSA:2048 --login --pin=$PIN --module="$P11LIB" --label="test" --id=01 --private $ pkcs11-tool -O --module=$P11LIB <<< does not list any objects $ pkcs11-tool -O --module=$P11LIB --pin=$PIN <<< lists objects $ eval `ssh-agent` $ ssh-add -s /usr/lib64/pkcs11/libsofthsm2.so $ ssh-add -l <<< lists the added keys What needs to be fixed are the ssh and ssh-keygen. As we see, the most common configurations are cards which have either all the public objects visible or none of them. The simplest solution that might be needed for the applications is to try to login, if a card returns zero keys without it. Created attachment 3133 [details]
Similar patch created while getting yubihsm_pkcs11.so to work with openssh
Duplicate work, didn't realize this was allready worked on while debugging yubihsm support. Provided for reference if anything in my version is of interrest to incorporate.
Shouldn't token that refuse to show pubkeys without login assert CKF_LOGIN_REQUIRED? We already have code that attempts to deal with that (though there are apparently some problems there). Created attachment 3279 [details]
revised diff
Maybe something like this could be used to attempt login if no keys were found. I'm not sure about the heuristic for activating it though, as soon as it finds any key it will skip later attempts a login and so would fail to find keys on tokens that mix login-required and not.
This looks reasonable and somehow follows what I was initially proposing. Tested with my patch (Regression) from mailing list (filled as a new bug #3006) and with reproducer in comment #5 and with real card. patch applied; will be in openssh-8.1 closing resolved bugs as of 8.6p1 release |