Enabling provider globally interferes with sshd

[grawity]

Not sure if this is a known/expected result or not (and it's really more of an OpenSSH and/or glib issue than a tpm2-provider issue), but I guess it should at least be documented:

Yesterday I tried enabling the tpm2 provider globally via /etc/ssl/openssl.cnf, adding:

[provider_sect]
default = default_sect
tpm2 = tpm2_sect

[default_sect]
activate = 1

[tpm2_sect]
activate = 1

After doing so, sshd started rejecting logins and complaining about syntax errors in various configuration files. It seems that loading the provider causes a GDBus worker thread to be spawned (as it connects to tpm2-abrmd), but then the sshd process closes all file descriptors – including the D-Bus socket opened by gdbus – and proceeds to open various other files at the same file descriptor that the gdbus thread is still reading from.

The result of that is: if UsePAM is enabled, then various PAM modules open a config file, try to read it, and think that a chunk of the config is missing (because the gdbus thread has read it); if UsePAM is disabled, the gdbus thread spins at 100% CPU trying to read from an invalid fd.

[juliaalbers]

I have the same problem.
I am trying to connect the python websockets library to the tpm. The whole thing in a docker container under ubuntu 22.04 with the OpenSSL version 3.0.2. Since I have not found a way to customize the provider in the websockets or ssl library, I wanted to customize the config as above.
However, the CPU is utilized to 100% and the ssh connection is no longer possible.

Any idea how to solve this problem?

[gotthardp]

You can set the OPENSSL_CONF variable to use the config with TPM enabled only for the python script that needs TPM. Could this be a workaround?

[juliaalbers]

Yes, thank you. Setting the environment variable fixed the problem for me.