openssh unix dev - Nov 2025 - Addition of pkcs11 provider triggers ssh break: PRNG is not seeded

Hi all,

I had a sudden case of ssh failing as follows:

Little-Net-8818:~ minfrin$ ssh --version
PRNG is not seeded

The trigger was adding the following pkcs11 provider configuration to openssl:

Little-Net-8818:~ minfrin$ cat /opt/local/etc/openssl/openssl.cnf.d/pkcs11.conf

[provider_sect]
pkcs11 = pkcs11_sect

[pkcs11_sect]
module = /opt/local/libexec/openssl3/lib/ossl-modules/pkcs11.dylib
pkcs11-module-path = /Library/OpenSC/lib/opensc-pkcs11.so
#pkcs11-module-token-pin = /etc/ssl/pinfile.txt
activate = 1

The workaround was removing the pkcs11 provider config above.

Am I right in understanding this is an error handling problem? Ideally we should
get the reason why the PRNG is not seeded, rather than just the statement.

Also, it seems weird that crypto is being set up (which then fails) before
--version is processed.

Is there something more than this going on, why would openssl work fine when a
pkcs11 provider is present but ssh not, is this a known issue or should I go off
and dig some more?

Regards,
Graham
--

On Wed, 5 Nov 2025, Graham Leggett via openssh-unix-dev wrote:
> Hi all,
> 
> I had a sudden case of ssh failing as follows:
> 
> Little-Net-8818:~ minfrin$ ssh --version
> PRNG is not seeded
Under the default build-time configuration options, OpenSSH depends on
libcrypto for randomness (e.g. via the RAND_bytes(3) API).

At startup, ssh and the other OpenSSH tools check the status of
the libcrypto PRNG using RAND_status(3) and will exit with this
error if the PRNG isn't ready.
> The trigger was adding the following pkcs11 provider configuration to
openssl:
> 
> Little-Net-8818:~ minfrin$ cat
/opt/local/etc/openssl/openssl.cnf.d/pkcs11.conf
> 
> [provider_sect]
> pkcs11 = pkcs11_sect
> 
> [pkcs11_sect]
> module = /opt/local/libexec/openssl3/lib/ossl-modules/pkcs11.dylib
> pkcs11-module-path = /Library/OpenSC/lib/opensc-pkcs11.so
> #pkcs11-module-token-pin = /etc/ssl/pinfile.txt
> activate = 1
> 
> The workaround was removing the pkcs11 provider config above.
>
> Am I right in understanding this is an error handling problem? Ideally
> we should get the reason why the PRNG is not seeded, rather than just
> the statement.
libcrypto doesn't tell us _why_ its PRNG isn't ready, only _whether_
it's ready.
> Also, it seems weird that crypto is being set up (which then fails)
> before --version is processed.
It's a self-test that is performed very early because we need to know
whether a critical facility (cryptographic randomness) is available
before we do anything that needs it.

BTW, --version isn't a valid flag for ssh; you probably want -V
> Is there something more than this going on, why would openssl work
> fine when a pkcs11 provider is present but ssh not, is this a known
> issue or should I go off and dig some more?
I'm not familiar with OpenSSL's provider system but I suspect that:

1) you're overriding the default libcrypto provider with the one you
   define in pkcs11_sect,
2) that one of the facilities the default provides supports the
   RAND_*() PRNG, and that
3) the pkcs11 provider doesn't include the same support

The OpenSSL mailing lists might be a good place to ask, though I
expect there might be some people here who are more familiar with
its provider system than I am too.

-d