SSH on ElasticXL Sync

[Alex-]

We've been looking at hardening SSH on some new ElasticXL systems, which still leaves a lot of legacy active out of the box.

We have the following.

KEX:

--------------------------------
enabled kex:
--------------------------------
curve25519-sha256
[email protected]
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
[email protected]
--------------------------------

(DH Groups stay in observation mode)

 Ciphers:

--------------------------------
enabled cipher:
--------------------------------
[email protected]
[email protected]
[email protected]
--------------------------------

MAC:

--------------------------------
enabled mac:
--------------------------------
[email protected]
[email protected]
--------------------------------

Which works all good, no flows using SSH are reported as broken, as expected with modern implementations.

However, internal communications over the Sync still uses RSA. Is it supported to rotate the keys and change the protocol or are there other dependencies, or "loss of support" because we'd have tweaked the system in an undocumented way? Our security team would love consistency in cryptographic usage.

[Bob_Zimmerman]

The SSH key file name is technically free text, so you could delete the key from the agent (ssh-add -D), generate a new Curve25519 keypair (ssh-keygen -t ed25519) and stick it in the ~/.ssh/id_rsa{,.pub} files, then put the public key of each member in the ~/.ssh/authorized_keys file on all members.

I see no reason that wouldn't work, but it would be brittle. Any time you add a new member, you would need to repeat the process there. Changing the default key type would definitely be an RFE. I'm personally a lot more concerned about key rotation, since any admin has access to the cleartext private key of each member. There's no documented rotation mechanism, so what do we do when admins leave the company?

Separately, there's also no reason at this time to use hmac-sha2. It's a lot slower for no security benefit. umac-128-etm is much faster and is more than secure enough for next century. For that matter, so is hmac-md5-etm.

[Alex-]

I like cryptography but I'm no cryptographer, so from discussions I had with sources more informed than me in the domain, I understand that umac, while not technically broken, was made for a time before hardware acceleration of cryptographic functions, so it's got quirky maths in the name of speed, and can be subject to timing attacks from determined adversaries.

Regarding MD5, it can be debated according to the use case but the baseline is that no one wants to use it anymore and picking a fight with security auditors isn't in my job description.

I'm indeed concerned about a rotation mechanism for those keys. A mechanism like rotating them at lightshot times or so would have been cool.

And a bit annoyed that in 2026, Ed25519 wasn't picked as default, as this will inevitably appear on some security audits as exceptions to be documented and justified as product design.

But yes, all of this is in RFE territory.