I personally don't see the point in them at all, in implementation and reality you get basically zero use out of the things.

Services that support them either have them locked down so hard that if you lose a single Yubikey (there's often no backup second key option), you're very screwed. Others go the other option, and have too easy to reset systems, SMS fallbacks, or other total bypasses of the security tokens.

For SSH and GPG, authentication keys are generally the least of your concern. The content you're controlling are much more valuable than the authentication itself. Can an attacker just wait until you SSH somewhere, and leverage that access? Can they wait until you'd press the button for another benign purpose and use that authentication in a malicious way? The answer is almost always yes, which reduces the value of these sort of devices substantially. They don't protect against local compromise, in which case a keyfile sitting on your local host is just as secure and a lot more convenient.

Well their main use is to mitigate remote compromise. But I suppose if for some reason someone compromises a private key remotely (???), they don't have your physical 2nd key to complete auth. Or if you want encryption at rest with something stronger than a passphrase. For weird cases like "disk backup was compromised" it also helps, because most people don't encrypt backups at the client. But in general, actual protection seems vanishingly small past remote attacks.

So I think in general private keys aren't improved with a token, since a compromised private key is supposed to be a local compromise.

I don't really see a situation in which someone has local file read access on your machine, but doesn't otherwise have you completely owned.

A regular keylogger won't no longer work with a hardware token for example. Yes, having your PC compromised is bad but it would be even worse if the keys can be stolen and used elsewhere, it just rises the bar significantly for getting persistent access (re-establishment without the token is really hard) in my opinion.

I think they can be pretty beneficial in corporate environments where you can exert some control over the IDP and turning it on/off isn't super difficult (like visiting a physical help desk)

In addition, these places tend to have less technical users and "plug it in and press during login" isn't terribly difficult

I genuinely don't understand downvoting a series of very realistic comments about what using a Yubikey is actually achieving in these situations.

I agree, I bought a yubi key ages ago and have tried to set it up for ssh, windows auth and various online services but I find it either just doesnt work, or works poorly enough that I don't use it and instead rely on classic TOTP instead.

Usually these are configured to be the private key, not unlock the one on your computer. This prevents your key being hijacked (every signing operation requires a physical button press on the key) and prevents its theft.

If an attacker can exfiltrate your private key they can probably keylog your passphrase & your VPN details

PIV/GPG smartcard solves he former and 2FA solves the latter so something like a yubikey/nitrokey gives you both in one device

Anecdotally I do have a friend who had his private key & passwords pilfered which was noticed when someone tried logging in from some other country.

So, taking "personal" to mean specifically that they belong to an individual as opposed to a service account, yes, that definitely has happened in real security incidents with big consequences.

There's a 2008 Fedora incident of this sort, a Fedora Administrator's private key was "stolen" by bad guys and used to upload replacement packages which is well documented e.g. https://lwn.net/Articles/326170/.

I think we should assume that this has also happened plenty of times to organisations which have a default posture of not telling you about incidents at all unless required by law.