Still no way to specify a PKCS#11 URI on openssh-portable?

Nick Bogdanov nickrbogdanov at
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
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; \

Then I watched to see how openssh would react:

    ssh -vvv -I /path/to/ 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 mailing list