Okay. Sure. We should move behind the kindergarten stage of KDF selection. Still, look at the threat model. We're talking about the encryption of the private key at rest. In ~/.ssh, 0700. If an attacker can even read your private key file, you've probably already lost, encryption or not. That attacker can probably change your .profile to include a keylogger. You lose.
I mean, sure. Change the KDF default to something modern. But the threat we're discussing is marginal, and it's not as if the security of the SSH network protocol, which is paramount, is under threat.
If you care about this class of attack, you probably care about it enough to use an SSH CA anyway.
The blog post explicitly addresses this, but you don’t seem to interact with its point. We have evidence that smash and grab attacks exist, and since they affect more people, you’re more likely to get screwed by something like the recent eslint-scope thing than a targeted attack where the attacker does shit to your .profile.
That said; yes: you should have long-held auth on a hardware token and then use an SSH CA for temporary auth.
I mean, sure. Change the KDF default to something modern. But the threat we're discussing is marginal, and it's not as if the security of the SSH network protocol, which is paramount, is under threat.
If you care about this class of attack, you probably care about it enough to use an SSH CA anyway.