It’s going to be anything that supports WebAuthn/FIDO2 credentials.
There are PAM modules you can install and configure for Linux and OSX.
Browser support is slightly different depending on the browser, but support for credential creation and assertion using a U2F Token (passkey) is supported by Edge, Chrome, and Firefox.
Very important caveat, this is only for roaming authenticators like Yubikeys (https://webauthn.me/browser-support). There is not (that I'm aware of) any support for platform authenticators on Linux (which is what most users will be thinking of when they use the word "passkey").
Roaming authentication is well supported on Linux, and you can cross-device sign in using your iOS/Android phone (assuming you haven't DeGoogled it), but the Mac/Windows experience of just having the computer itself act as an authenticator isn't supported. You're still going to need to use a locked down, proprietary device to log in, it's just that the proprietary device can help you log in on your Open device.
> Why can my Linux box not act as an authenticator
That is a really good question.
For whatever reason, I'm not aware of a single Open Source platform authenticator for any platform. It seems to me like that would be a pretty big priority for an Open standard, but what do I know?
Google has said they have "no plans" to support platform authentication on Linux[0]. I don't know if this is just them saying they don't plan to build a platform authenticator themselves, or if they're saying that if a Linux box advertises that it has a platform authenticator, they're not going to trust it.
Either way, passkeys basically require you to either buy a Yubikey/dongle (which will not support cloud sync) or to use a proprietary OS as your authenticator.
It's probably because biometrics support (via fingerprint sensors et al) isn't a standard part of the Linux desktop/notebook "platform"; and so most Linux devices would just be prompting you for a password to unlock your passkey anyway (like prompting for an SSH passphrase to unlock an SSH key) — at which point, why bother, if the whole goal was just to eliminate the possibility of being phished?
Becuase you would not be entering your password into the browser, or a web site, you'd be entering your password to a seperate password manager, presumedly with an OS-level dialog which would would be using the backend protocol to verify/hash against the origin domain and supply the right key.
iCloud syncing already has this problem though. If I lose an iPhone and I buy a new iPhone and sign into an iCloud account, my passkeys will get synced.
So I'm not sure I believe that really strong stances on potential phishing attacks are the real reason here. Passkeys with cloud sync are phishable.
> why bother
A single master password would still be a massive increase in security and would still eliminate a ton of phishing attacks. The cool parts of passkey aren't really the biometrics, the cool parts are how they get shared with websites. That's where the real phishing protection comes from.
> If I lose an iPhone and I buy a new iPhone and sign into an iCloud account
Have you done that recently? What a godforsaken pain in the ass it is, especially if you don't have another Apple device handy that you are already signed in to.
It has been a fairly long while since I've needed to sync an iCloud account to a new computer. I'm mainly going off of https://support.apple.com/en-us/HT204974 so it definitely could be oversimplifying the requirements.
Though even ignoring SMS and recovery codes, I'm not sure that using a second Apple device as 2FA would change anything; we generally don't consider one-time codes to be unphishable.
But again, that's only me looking at the docs. Is there something I'm missing about the process that would block a phisher from using an iCloud password plus an SMS hijacking attack or phished one-time code to log in and set one of their devices as trusted?
Is any Linux distribution, let's say Ubuntu or Fedora a "major platform"? Is Firefox a "major browser"?