Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Most implementations of ssh-keygen made legacy RSA keys no longer the default quite a long time, ago. Now, when your key-generator defaults to "RSA" it's almost always RSAv2. While you can still generate RSAv1 keys, you usually have to specify "give me the old-assed version" (however, if you're on a semi-hardened system, you'll may end up getting an error when attempting to do so).
That said, primary reason I still keep an RSAv2 key around (in addition to other key-types) is because, working with AWS, RSAv2s were the only keys that Amazon let you upload as provisioning-keys. Longstanding gripe. I'm hopeful that, one day, that will change.
Interesting insight, thanks for sharing. Really sad to hear, that especially AWS is only supporting RSA for their machines. They are in the position to shift markets, so why not the security "market" too?
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Couple reasons I can think of:
1) They use the key for more than just Linux instances: Windows EC2s' initial administrator password is derived from the uploaded SSH key. Since you can't even use a passworded key for such, it's unlikely they want to inject logic to handle arbitrary algorightms
2) They're likely of the view "why invest in improving something people really shouldn't be using in the first place."
3) If you are allowing logins to interactive shells on your instance, you're far better off using a key-management system than limiting yourself to one SSH key and one user-account
But, again, we're talking RSAv2 vice RSAv1. RSAv2 isn't exactly what you'd typically classify as "inherently weak" (there's a reason that appropriately-generated RSAv2 keys are still usable on systems that are compliant with FIPS-140-2)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Most implementations of
ssh-keygenmade legacy RSA keys no longer the default quite a long time, ago. Now, when your key-generator defaults to "RSA" it's almost always RSAv2. While you can still generate RSAv1 keys, you usually have to specify "give me the old-assed version" (however, if you're on a semi-hardened system, you'll may end up getting an error when attempting to do so).That said, primary reason I still keep an RSAv2 key around (in addition to other key-types) is because, working with AWS, RSAv2s were the only keys that Amazon let you upload as provisioning-keys. Longstanding gripe. I'm hopeful that, one day, that will change.
Interesting insight, thanks for sharing. Really sad to hear, that especially AWS is only supporting RSA for their machines. They are in the position to shift markets, so why not the security "market" too?
Couple reasons I can think of:
1) They use the key for more than just Linux instances: Windows EC2s' initial administrator password is derived from the uploaded SSH key. Since you can't even use a passworded key for such, it's unlikely they want to inject logic to handle arbitrary algorightms
2) They're likely of the view "why invest in improving something people really shouldn't be using in the first place."
3) If you are allowing logins to interactive shells on your instance, you're far better off using a key-management system than limiting yourself to one SSH key and one user-account
But, again, we're talking RSAv2 vice RSAv1. RSAv2 isn't exactly what you'd typically classify as "inherently weak" (there's a reason that appropriately-generated RSAv2 keys are still usable on systems that are compliant with FIPS-140-2)