Best practice for generating SSH keys?

These seem to be the current best options, thoughts?

ssh-keygen -t ed25519 -o -a 100 # Higher security
ssh-keygen -t rsa -b 4096 -o -a 100 # Higher compatibility

Current ssh-keygen defaults for t b a: -t rsa -b 3072 -a 100

-o isn’t in the man page, it insures the private-key is using the new OpenSSH format though that’s probably for older versions of ssh-keygen, likewise with -a 100.

-a (better description): The number of KDF (Key Derivation Function) rounds. Higher numbers result in slower passphrase verification, increasing the resistance to brute-force password cracking should the private-key be stolen


encryption - What are ssh-keygen best practices? - Information Security Stack Exchange
encryption - What's the difference between and - Stack Overflow
Secure Secure Shell
Upgrade Your SSH Key to Ed25519. If you’re a DevOps engineer or a web… | by Risan Bagja | Code | Medium


I’m not a cryptography expert but that checks out with every piece of wisdom I’ve seen online. That and generating your keys on an air-gapped computer (which has always seemed like overkill to me.)

I was a little concerned about the default for -b (bits) being 2048 for RSA instead of 4096 which implied ssh-keygen might similarly undervalue ed25519 without a -b but…

“For this key type, the -o option is implied and does not have to be provided. Also, a bit size is not needed, as it is always 256 bits for this key type.”
Using Ed25519 for OpenSSH keys (instead of DSA/RSA/ECDSA) - Linux Audit

-o and -b don’t need to be there for ed25519

As of OpenSSH 8.2, you can now unlock your SSH keys with a a hardware token such as a Yubikey.