With more and more operating systems dropping support for RSA keys at least with default settings I think it is time to move to ED25519 as new default for the key used by REX.
Smart Proxy plugin ansible does not need any adjustments
We need a migration path as the old key should be removed, the new key needs to be deployed, … - Is documentation enough for this?
Please add what I missed
Because he is code owner of REX @aruzicka, he is code owner of the puppet module @ekohl and he may be a good one to answer the question if documentation is enough @maximilian
Just changing the default would make new installations future-proof, will require support for both types at least for some releases and will make old installations fail to connect to current Fedora and Ubuntu installations if not adjusted and future EL installations (EL10+).
Doing a migration without deploying the key on all Hosts will break REX and so perhaps the only way to get the new key deployed. Supporting two keys (or multiple keys) to allow a smoother migration is something I am not sure if it is easy to add to the existing code without making it more complicate than we want.
So I have no idea what would be the best way and I admit I am a bit scared of breaking a production environment.
Does REX today support multiple keys? SSH is perfectly capable of using multiple keys and negotiate support. That can be used for upgrading to a stronger key, or just rotation. So the steps can be:
Create a new key (so there are 2 SSH keys on the Smart Proxy)
The latter might be hard to detect automatically and because you can lock yourself out, I would make the end user responsible but provide them tools to easily determine it.
For Puppet users we have a class that receives the keys via the ENC and since it’s out of band (not using SSH itself) you can always fix it:
Last time I checked on EL10 it didn’t reject rsa keys?
Definitely not something I’d call easy.
Yeah, same. I’d vote for changing the default and providing documentation on how people can switch their existing deployments on their own if they need to.
I suppose the problem is that there’s now just a single configuration setting:
We would need to change that into a list of key files.
I see that now we pass the option here:
I wonder why that is used and not the -i option, which may be repeated. So that could work.
Then you also need to modify it so the public key file becomes public keys and exposes that correctly to Foreman.
Feels to me not trivial, but also not impossible.
Having a supported way to rotate these secrets is IMHO a very nice thing to have and this could allow it to be used in-band, using pure REX. Or even maintain a legacy key for systems that don’t support the modern ED25519 keys.
DEFAULT cryptographic policy rejects TLS ciphers with RSA key exchange
TLS ciphers that use the RSA key exchange are no longer accepted in the DEFAULT system-wide cryptographic policy in RHEL 10. These ciphers do not provide perfect forward secrecy and are not considered as secure as ciphers that use other key exchanges, for example, the Elliptic-curve Diffie-Hellman (ECDH) key exchange.
This change also reduces the exposure to side-channel attacks because the RSA key exchange uses PKCS #1 v1.5 encryption padding, which can cause vulnerability to timing side-channel attacks.
If you need the RSA key exchange for interoperability with legacy systems, you can re-enable it by using the LEGACY system-wide cryptographic policy or by applying a custom subpolicy.
Can be I misunderstand it, but if it is not EL10 other operating systems already do. I switched my personal key to ed25519 since Fedora dropped default support for rsa. And I was quite happy as we enforce it already on our cloud and I had also some customers where it is enforced.
There are some additional things we’d have to figure out. For example right now the key can be passphrase protected. Either we’d have to require that all the keys are unprotected or use the same passphrase or figure out a way how one could pass in multiple passphrases. Still, not impossible, but it would sprawl a bit
Isn’t that talking only about using rsa for key exchange, which isn’t really related to using rsa keypairs?
Ok, than it is not like we get in trouble with EL10, but I have the feeling it is still a good discussion we started here.
And yes, could have easily been the case it was only rsa with not enough bits. Looking at the puppet module we generate the key for REX with system defaults, so could this also be the case here when a system is quite old, updated and never rebuild? Then a renewal and key migration makes sense even if it would not be rsa to ed25519.
If FIPS mode is enforced on Red Hat 9, ed25519 keys is not supported. Been forced to use ecdsa keys on all “FIPS servers” I have. Hopefully FIPS will support ed25519 in the future.
Note that the Ed25519 algorithm is not FIPS-140-compliant, and OpenSSH does not work with Ed25519 keys in FIPS mode.