I wrote this; happy to answer questions.
That said: Ed25519 is a local optimum: the bigger win is to not have long-held credentials at all, and instead use an SSH CA or something like Gravitational Teleport. Doesn't work for GitHub though.
Basically, you use long-held credentials to generate short-term credentials, and then use the short-term credentials themselves to access whatever server or service you need.
Master user records in an identity/SSO system. We use ADFS.
Use a protocol which provides a portable “signed”, temporary credential. We use SAML but OIDC also works.
Have a command-line client which auths to the SSO and then relays an identity proof to a trusted component (lambda, cloud function, dedicated instance, whatever your policy says is ok). The identity proof is just a saml assertion or oidc token.
Have trusted component validate the identity proof from SSO and generate time limited credentials (we issue ssh, kube and iam). Our client then auto-xfers those creds up to jumpbox but you could drop them on workstation instead if your policy allows.
Though it might work with a second, more limited (not-so-)SSO system for specific users and environments.
A jumpbox with 2FA might be workable. Servers only accept logins from the jumpboxes, but you don't have to get 2FA working on them. Essentially it's an internal VPN gateway. (Be on the lookout for the knobheads in IT that set up parallel login mechanisms without 2FA, like mounting the file share, virtual desktop logins from the hypervisor, Kerberos auth.)
FYI it supports [0]: ansix9p256r1, ansix9p384r1, ansix9p521r1 and brainpoolP256r1, brainpoolP384r1, brainpoolP512r1
[0] https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3...
That’s due to Curve25519 having a non-unit co factor. There’s a half dozen other weird properties of the curve chosen for smal efficiency gains or whatnot which also might lead to security holes in any application which is not the single signer or 2 party key agreement use case.
I get that this isn't a good practice, but plain brute-forcing a 20 character pw (~120 bits of entropy as alphanumeric, same as md5 hash size) is still impracticle even if it's a low cost md5 calculation.
You’re right that you can imagine passwords that you still can’t enumerate. But suggesting that people have a non-reused memorized 120 bit password is, uh, optimistic.
And this should be one of the top priority passwords, so it's not too hard to imagine it being in a password manager or using a similar quality.
Also the 120 bits was an example and a good amount more than necessary. A 12 character password isn't exactly standard but it's not ridiculous to expect. Once you exclude the passwords that are so bad even bcrypt can't save them, the number of users where the password algorithm makes a difference starts to look a lot smaller than 100%.
In other words I wanted to know, if my SSH keys with md5 algorithm are fine, if I use a high entropy pw (which I do, especially for my ssh keys).
Sure some people will use short and reused passwords for ssh keys, but the persons using password protected ssh keys are way more informed about security than your average user. Password statistics are usually based on pw database leaks of your average user and/or sites that are not worth protecting.
There is an interesting short paper about password meters (I'm traveling without a laptoo right now, but can link it later) that found out people cared more about the strength of their password, if the login it's protecting is more important.
Combining these two points I think the percentage of ssh key users that use at least 12 character passwords is rather high, but of course I have no evidence. I spoke however about prod pws with some devs at my company and the answers ranged from 12 to ~20 chars and completely randomized 40chars in pw managers. Nothing especially short. You can also copy your ssh key pw from a pw manager.
You still make a good point in your article and using MD5 is not ideal, but I was missing information for the evaluation of risk I'm in. High enough entropy passwords seem not only better than plaintext, but actually still safe to me when MD5 is used.
Anyway, it doesn't matter that your password is ygGucg,guc52f when your colleague's is bigbum99.
Also there are some ways to create memorable and long passwords. E.g. I'm using short pictureable phrases and their translation in another language, sometimes adding a numeral if required. Example: "2YellowChopsticksZweiGelbeEssstäbchen" (even with spaces if allowed)
Very easy to remember for me, very high entropy, decent entropy if the pattern is known and requires a hand-crafted dictionary attack that even needs decent translation. E.g. in the example above chopsticks has two common German translations and the ä can also be written ae. Bonus points if you use it for a language you are currently learning.
Though I have thought of having a mechanical typing device, actuators for each key, that would just type them for me. But it would be conspicuous.
I do use keepass for all the hundreds of other passwords where possible.
How can I tell if my file is vulnerable once leaked?
You can't tell if it's leaked or not unless osmeone starts using it. You can tell if it's in the safe format right now by looking at the first few lines of the file.
Switch to the newer format, roll your keys regularly, improve your logging, honeypot with the old keys, put AppArmor/SELinux controls on the .ssh directory.