3 ms·
>You might ask yourself how OpenSSH ended up with this. The sad answer is the OpenSSL command line tool had it as a default, and now we’re stuck with it. Given
by simias 8y ago
>You might ask yourself how OpenSSH ended up with this. The sad answer is the OpenSSL command line tool had it as a default, and now we’re stuck with it.
Given that (as far as I know) the decryption is handled only on the client side, why does an old default matter? Does it break any kind of compatibility to change that? Why only use the better algorithm for EC keys?
And even if it did break compatibility it's not like it usually stops the OpenSSH folks, old ciphers and hash functions are deprecated regularly (I have to whitelist a bunch of ciphers at work to connect to legacy systems running an old dropbear).
- tialaramex 8y agoSome people move private keys. You shouldn't, but people do. And so they expect that an encrypted private key file from their brand new Mac will work when pasted into a five year old CentOS install.
- simias 8y agoSeems like simply issuing a warning on key creation "this key uses a newer, safer encryption scheme but as a result might not be directly portable to older versions of openssh, if that's an issue use <someflag> to use the older, weaker scheme instead" would probably solve the problem in 99% of the cases. After a few years you might remove the warning and move on. For this type of applications security should trump backward compatibility, especially when in this case the breakage is fairly limited and easy to work around.