Still no way to specify a PKCS#11 URI on openssh-portable?
nickrbogdanov at gmail.com
Thu Feb 4 12:32:31 AEDT 2021
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
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; \
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?
More information about the openssh-unix-dev