Hello, TL;DR. Bad openssl config can break remote access to the system via SSH. OpenSSL 3.0 doesn't provide any crypto primitives itself. It is done via the providers' mechanism. The provider should be loaded and activated to make some algorithms and RNG available. The default provider is a bit special. If no providers are activated explicitly, the default one is activated implicitly. (See details in https://github.com/openssl/openssl/issues/16249). Its activation is commented out in the config file. If anybody tries to activate a legacy provider and doesn't uncomment the default provider activation, the system becomes almost unsuitable for work and not remotely accessible anymore. I am pretty sure that there will be enough people who because either not reading the documentation or just being in a hurry will turn the remote accessibility off. To prevent it, the viable option is explicitly load the default provider in openssh if necessary. We can check if it is necessary in several ways. First, we can check if the default or FIPS provider is already loaded. Second, we could check that any algorithm (I'd prefer some of the AES-CTR family) is available, and load the default provider if not, implying that it the selected algorithm is implemented in the provider carrying also some sort of key exchange algorithm, RNG, etc. I have a tentative patch for this purpose. There also may be an option to add an explicit switch 'FallbackToDefaultProvider yes' to the openssh configuration. Please, any feedback is welcome. -- Dmitry Belyavskiy _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
