Nick Bogdanov
2021-Feb-04 01:32 UTC
Still no way to specify a PKCS#11 URI on openssh-portable?
I have been gradually migrating my setup to use hardware-backed keystores, and was surprised to find that while openssh allows me to specify a PKCS11Provider, it seems to cope very poorly with any situation where the token has more than a few keys on it. To illustrate the problem I took an old Yubikey 4 and populated all of the PIV slots with random RSA keys: echo "days = 1" > template.txt certtool --generate-privkey --key-type=ecdsa --outfile=key.pem certtool --generate-self-signed --load-privkey=key.pem --outfile dummy.pem --template=template.txt for SLOT in 9a 9c 9d 9e 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 f9; do \ yubico-piv-tool -a generate -s $SLOT -A RSA2048 -o pub.pem && \ yubico-piv-tool -a import-certificate -i dummy.pem -s $SLOT; \ done Then I watched to see how openssh would react: ssh -vvv -I /path/to/libykcs11.so user at host openssh took about 5 seconds to enumerate ~26 public keys on the token (versus 1 second with an empty token), offered the first 6 public keys in the list to the remote host, and then aborted with "Too many authentication failures." Furthermore, I didn't see a way to automatically enter the PIN; other applications let me add a "pin-value" parameter to the PKCS#11 URI. I see that RHEL8 has incorporated Jakub Jelen's work so that `ssh -i <pkcs11_uri>` just works like magic. There is also an open Bug #2817 tracking this change, which only has positive comments on it. This seems like the cleanest approach to me as it makes PKCS#11 in openssh accept URIs the same way other programs do. What still needs to be done before this can be merged to mainline?