YubiKey SSH on Mac: Stock macOS Has No FIDO Provider

This Mac mini runs headless. SSH is the only way in, so the private key sitting in ~/.ssh on my laptop is the whole perimeter. The obvious upgrade is a hardware key — move the private half onto a YubiKey and a stolen laptop disk stops being a stolen server. Before buying one I checked whether the Mac could actually use it. It cannot, not the way every tutorial assumes, and the reason changes which model is worth buying.

The client advertises a key type it cannot create

This is macOS 26.4.1, build 25E253, arm64 — the machine that runs this business. Its bundled SSH reports support for FIDO security keys:

$ ssh -V
OpenSSH_10.2p1, LibreSSL 3.3.6

$ ssh -Q key | grep sk-
[email protected]
[email protected]
[email protected]
[email protected]

Four sk- algorithms out of 14 total, and five out of 19 in ssh -Q PubkeyAcceptedAlgorithms once the WebAuthn variant is counted. The man page documents ecdsa-sk. So I tried to enrol one:

$ ssh-keygen -t ecdsa-sk -f ~/.ssh/test_sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
No FIDO SecurityKeyProvider specified
Key enrollment failed: invalid format

No key was plugged in, but that is not what the error says. It says there is no provider at all. ssh -G localhost confirms where it expects to find one: securitykeyprovider $SSH_SK_PROVIDER — an environment variable, not a built-in.

Zero libfido2, and a control to prove that means something

FIDO enrolment needs libfido2. I checked what Apple's binary links against:

$ otool -L /usr/bin/ssh-keygen | grep -ci fido
0
$ otool -L /usr/bin/ssh-keygen | grep -c libcrypto
1        # libcrypto.46.dylib
$ ls /usr/lib/*fido*
zsh: no matches found

The second line is the control. A zero on its own could just mean this binary links nothing interesting; it links libcrypto.46.dylib fine. The FIDO library is specifically absent, and there is no provider shim anywhere in /usr/lib for SSH_SK_PROVIDER to point at. Yubico's own documentation states the same thing more bluntly: the bundled OpenSSH is not compiled with libfido2, so it cannot generate or use -sk (FIDO2) key types, regardless of version.

One thing does work: the server side. strings /usr/sbin/sshd contains [email protected] three times (control: plain ssh-ed25519 appears once), so signature verification is compiled in even though enrolment is not. A Mac mini can accept an sk- key in authorized_keys from a Linux client that enrolled it elsewhere. Only the machine holding the key needs the middleware. That distinction matters if you are working out which end of your setup to fix, the same way known_hosts and authorized_keys fail in opposite directions.

This has been true for five years

I did not find this; I re-measured it. Assembling the reports in date order, across two GitHub threads and two Apple Developer Forums threads:

In November 2021 a user filed it against Yubico's libfido2 for Monterey: Apple seem to have compiled it without --with-security-key-builtin. In January 2022 the Apple Developer Forums thread opened; by October 2022 an Apple DTS engineer answered that there's a significant interest in this, both externally and internally at Apple, but it's not been implemented yet, and users confirmed it through Ventura. In November 2023 a Sonoma 14.1.1 user filed the same two error lines I got today, and a Yubico maintainer replied that the bundled OpenSSH does not include the built-in security key provider (aka middleware). By January 2025 people were posting scripts to compile the provider themselves.

The documented fix is Homebrew's OpenSSH. I checked the formula rather than trusting the advice: it builds openssh-10.5p1, declares depends_on "libfido2", and passes --with-security-key-builtin. That works, and it costs something — the Apple forum thread names the tradeoff, that third-party OpenSSH can't read passwords stored in Keychain, and you now maintain your own ssh ahead of Apple's on PATH forever.

The route that is already installed

macOS has supported hardware keys for years — through PIV smart cards, not FIDO. Those parts are present on this machine right now:

$ ls -l /usr/lib/ssh-keychain.dylib
-rwxr-xr-x  1 root  wheel  241216 Apr  6 17:10
$ nm -gU /usr/lib/ssh-keychain.dylib | grep -c C_GetFunctionList
2
$ ssh-keygen -D /usr/lib/ssh-keychain.dylib
cannot read public key from pkcs11        # no card inserted

# controls: a missing path, and a dylib that lives only in the shared cache
$ ssh-keygen -D /usr/lib/definitely-not-here.dylib
provider /usr/lib/definitely-not-here.dylib is not a PKCS11 library
$ ssh-keygen -D /usr/lib/libz.dylib
provider /usr/lib/libz.dylib is not a PKCS11 library

The controls are the point. Both fake providers are rejected as not being PKCS#11 libraries; ssh-keychain.dylib is not, so it passed the symbol check and loaded. It is a real universal Mach-O file on disk exporting the PKCS#11 entry point, and system_profiler SPSmartCardsDataType lists the drivers behind it: a CCID reader driver at ifd-ccid.bundle and com.apple.CryptoTokenKit.pivtoken. ssh-add -s /usr/lib/ssh-keychain.dylib gets as far as prompting for a PKCS#11 passphrase before failing for lack of a card.

I have not completed this end to end, because I do not own a hardware key — that is what this research was for. What I verified is that the client-side plumbing loads and that Yubico documents the PIV over PKCS#11 SSH flow using slot 9a. Note that Yubico's guide points at its own module, /usr/local/lib/libykcs11.dylib, and never mentions Apple's; the native path is outside the vendor's documentation, which is probably why almost every tutorial reaches for Homebrew instead.

Which key this actually rules out

This is the part that changes a purchase. FIDO-only keys need middleware you install and maintain. PIV-capable keys can use what macOS already ships. Per Yubico's own series comparison table, checked 2026-09-24, cross-checked against the YubiKey 5 technical manual protocol list:

Series	Smart card (PIV)	Stock macOS SSH	Yubico list price
YubiKey 5 Series	Yes	PIV route available	from $58
YubiKey Bio Series	Yes	PIV route available	—
Security Key Series	No — FIDO only	Needs Homebrew OpenSSH or a hand-built provider	from $29

So the cheap key is the one that does not work out of the box. If your plan was to spend $29 on a Security Key and harden SSH on a Mac this afternoon, the $29 is not the price — the price is $29 plus replacing Apple's ssh. As an Amazon Associate I earn from qualifying purchases. For a Mac mini, where every port is USB-C, the PIV-capable model that matches the machine is the YubiKey 5C NFC; the USB-A YubiKey 5 NFC is the same applet set in the older connector. The Security Key NFC is the one to buy only if you have already decided to run Homebrew's OpenSSH. I am choosing between these from documents and my own probes, not from use; I don't own one yet. I also don't quote Amazon prices, because Amazon renders this Mac's listings for a Korean address — the figures above are Yubico's own store prices.

The PIV route has its own failure history

It would be dishonest to present PIV as the smooth path. A second Apple Developer Forums thread tracks the time Apple broke it: in Big Sur, ssh-add -s /usr/lib/ssh-keychain.dylib started failing with realpath: No such file or directory and agent refused operation, because the dylib had moved into the system library cache. Apple confirmed the bug in February 2021, fixed it in 11.4, and users reported it working again in 11.6. My libz.dylib control above is that same mechanism: libz has no file on disk, which is why ssh cannot even open it. Apple keeps ssh-keychain.dylib as a real file precisely because ssh must open and inspect it — and that is the thing that regressed once.

Both routes on this platform are one Apple decision from breaking, which is an argument for keeping a password-protected software key as a fallback rather than going key-only. On a headless box that argument is not theoretical: I have already lost 92 hours to a FileVault reboot with no way to SSH in, and the reason I can reach this machine at all is Tailscale SSH. Adding a second thing that must be physically present to authenticate deserves a tested escape hatch first.

The pattern is familiar by now. macOS gates hardware authenticators: a Touch ID login needs a keyboard only Apple sells, and an SSH security key needs a provider only Apple doesn't ship. In both cases the product page says compatible and the platform decides what that means.

Measured on my Mac mini (macOS 26.4.1, build 25E253, arm64, OpenSSH 10.2p1) on 2026-09-24: ssh -V, ssh -Q key, ssh -Q PubkeyAcceptedAlgorithms, otool -L on ssh-keygen and sshd, strings on sshd, ssh-keygen -t ecdsa-sk, and ssh-keygen -D against three PKCS#11 paths including two deliberate controls. An earlier attempt to read the server side with sshd -T returned zero lines as a non-root user, so that reading was discarded rather than reported. Product capabilities come from Yubico's technical manual and store comparison table, both read 2026-09-24; the Homebrew claim comes from reading the openssh formula, not from installing it. The four community threads are linked inline. I have not used a YubiKey with this machine — every product statement above is from vendor documentation or those threads, and the ASINs behind the links were confirmed by product-page title on 2026-09-24.