Method to set key exchange ciphers (or add more) when using flux bootstrap

[NandGates]

We have hardened our server (bitbucket on-premise) so that only "safe" curves and ciphers are used for key exchange.

Now, when we run flux bootstrap we get the following message (when using kind for simplicity):

flux bootstrap git --url=ssh://[redacted].git --branch=master --components source-controller,kustomize-controller,notification-controller -- namespace flux-system-v2 --path clusters/kind-local --reconcile

► cloning branch "master" from Git repository "ssh://[redacted]:22/dmskm/dd-fluxv2-poc.git" ✗ failed to clone repository: ssh: handshake failed: ssh: no common algorithm for key exchange; client offered: [curve25519-sha256@libssh.org ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group14-sha1], server offered: [diffie-hellman-group-exchange-sha256 diffie-hellman-group18-sha512 diffie-hellman-group17-sha512 diffie-hellman-group16-sha512 diffie-hellman-group15-sha512 diffie-hellman-group14-sha256]

It appears flux only supports the following key exchange ciphers and we could not find a way to alter it:

• curve25519-sha256@libssh.org
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• ecdh-sha2-nistp521
• diffie-hellman-group14-sha1

All of these NIST curves, as well as DH group 14, are marked as weak on SafeCurves (https://safecurves.cr.yp.to/) except the openssh extension to Curve25519 (curve25519-sha256@libssh.org)

We have found a ticket with Atlassian (https://jira.atlassian.com/browse/BSERV-10175) which discusses this and where they state that openssh-specific ciphers (eg sha256@libssh.org) are not supported so this is not an option for us.

It would be fantastic if we could get some more control over the ciphers which are supported by flux, such as enabling some more diffie-hellman groups, so we can retain our compliance while still using flux.

Any advice is appreciated as we have been using flux v1 for a very long time without incident and are very keen to migrate to v2.

[hiddeco]

To be able to give you configurable options, there must be support for more KEX algorithms first. Looking at the underlying Go library that is used for SSH connections golang/crypto, there are not many Diffie Hellman groups that are supported, except for diffie-hellman-group-exchange-sha1 and diffie-hellman-group-exchange-sha256: https://github.com/golang/crypto/blob/57b3e21c3d5606066a87e63cfe07ec6b9f0db000/ssh/kex.go#L30-L34

[NandGates]

Hi @hiddeco,

Thanks for the super rapid reply! It seems diffie-hellman-group-exchange-sha256 is secure but not in the list of KEX in the flux list, is there a way to configure or set that through the cli/config?

Happy to mark this as an answer because you technically answered my question, this one is for bonus points 🙂

[hiddeco]

We would either need to create the option to configure alternative KEX algorithms (and validate provided values to check if we actually have an implementation), or configure the diffie-hellman-group-exchange-sha256 as a default accepted algorithm.

Given that during the handshake the used algorithm during KEX is determined based on the offered (and preferred) options from both client and server, and taking into account that expansion of the supported algorithms in golang/crypto is close to non-existing, the latter option may be best.

We would then add diffie-hellman-group-exchange-sha256 as the least preferred option, which means this (relatively slow) KEX algorithm is only picked if the server does not have any other matches.

WDYT?

[NandGates]

Completely agree with your assessment that if the upstream library doesn't support it, there's little value in what I presume is significantly more effort to allow arbitrary inputs for KEX algorithms.

If you were happy to add this to the default list given it is part of the upstream library, that would be amazing!

Thank you for your responsiveness, it's brilliant and much appreciated 🙏

[hiddeco]

Created #1320