4 ms·
This isn't that complicated. The answer is, simply: ED25519 if you're using modern services that support it. or RSA (4096 or at least 2048 bits) for services
by hal9000-tng 6y ago
This isn't that complicated.
The answer is, simply: ED25519 if you're using modern services that support it.
or RSA (4096 or at least 2048 bits) for services that cannot handle ED25519 (including AWS -- yes, still, even in 2020.)
So you should probably generate both to cover most possible scenarios:
ssh -t ed25519 # for most purposes (not AWS)
ssh -t rsa -b 4096 # for when you're not using something like Userify
- Arnavion 6y ago>services that cannot handle ED25519 (including AWS -- yes, still, even in 2020.) I assume this is about provisioning VMs, and even then only about setting the initial ssh key at provisioning time? I can't imagine why AWS would care what kind of ssh keys a VM uses after it's been provisioned. If so, you can just create a temporary RSA key used to provision the VM, immediately replace it with an ed25519 one and throw away the RSA one. That's what I do with Azure VMs since Azure has the same RSA-only requirement silliness for what amounts to writing a blob of user-provided text to a file.
- lervag 6y agoIt should be "ssh-keygen", not "ssh". ssh-keygen -t ed25519 ssh-keygen -t rsa -b 4096
- hal9000-tng 6y agoOops :) thanks for the catch!