I'm assuming that practically everybody who is a developer on ssh-keygen knows about this. This is not a bug, right?
It's basically bad usability, where the default is unsafe, and in order to make it safe, you have to know what you're doing. Or is it like the author writes in 'TFA' that "we're stuck with it", because it used to be a default in OpenSSL?
Some people will say, "if you're using ssh-keygen we can expect that you know what you're doing". But this is a wrong assumption that gets people into trouble. I'd even say a minority of people who invoke ssh-keygen really know what's going on in detail and what providing a flag like "-t ed25519" actually does. I certainly don't, and I've had to generate quite a few ssh keys so far.
The new format has been around for a pretty long while (2013). I think it makes sense to upgrade to -o. While it's obvious to developers (I hope!) it's not obvious to most end users I think :)
not only does it seem like this is a better default, this option is awfully well-hidden on my system; doesn't show up in the short help or the example usage in the man page; gotta scroll down to find it in the exhaustive list of flags
I believe you can change to the new format (still not ed25519 though). After generating your keypair in the AWS console, do "ssh-keygen -p -o -f aws.pem" and add a strong passphrase generated from a password manager.
It's basically bad usability, where the default is unsafe, and in order to make it safe, you have to know what you're doing. Or is it like the author writes in 'TFA' that "we're stuck with it", because it used to be a default in OpenSSL?
Some people will say, "if you're using ssh-keygen we can expect that you know what you're doing". But this is a wrong assumption that gets people into trouble. I'd even say a minority of people who invoke ssh-keygen really know what's going on in detail and what providing a flag like "-t ed25519" actually does. I certainly don't, and I've had to generate quite a few ssh keys so far.