Security features like this works, until it doesn't.
When I installed WireGuard on macOS, I was happy to discover that it stores private keys in the system keychain. Accessing the private key requires Touch ID.
Then one day after a system upgrade, the WireGuard app crashed on startup with:
[APP] Unable to open config from keychain: -25300
Then the app deleted all profiles because they are all "orphaned", apparently for "keychain consistency" [0].
From then on, I just use a text editor to edit my WireGuard configuration files, and import them to the app. The bug still exists to this day [1].
> You linked a commit and a Reddit post. Is there a proper Github issue as well?
It's funny you mentioned that. The GitHub repository is a mirror of https://git.zx2c4.com/wireguard-apple. You cannot create issues there. You're supposed to send a bug report to the mailing list, which is enough friction that none of us did so far.
Edit (March 2025):
Wireguard, to my surprise, has no bug tracking system like Jira or issue tracking area such as GitHub.
If you want to see this fixed, the only way to instigate change is to write team@wireguard.com and jason@zx2c4.com.
So many of the keychain APIs are "deprecated" (read: marked as "we will nuke this API whenever we want") and have been for a decade or more, but have no replacement either.
A lot of the Security Framework came from Classic, hell, the idea of a keychain came from Classic! Just a mess.
The author says he doesn’t like the idea of having keys sitting on his file system ready to be snatched by bad actors.
That’s why they should be passphrase protected.
You use ssh agent to store the keys in memory and for convenience you can store the passphrases in keychain. MacOS OpenSSH has the UseKeychain config directive for that.
I use Yubikey/FIDO2 myself, but not because private keys cannot be protected on a file system.
Secure Enclave is still more secure in that it should be impossible to access the private key. Password protected keys are still vulnerable to malware that can read the keyboard, trick you in to typing the password, or that have exploits in macOS to read the memory.
These days I'm mainly doing development inside VM's. Previously I was embedding Github key to each VM, but since I setup Secure Enclave (with Secretive), I'm only forwarding it's agent to VM and each git action on origin now requires approval using fingerprint reader. I think this a good way to prevent malware from gaining access to github
PAT are vulnerable, once stolen they can be used from anywhere until their (usually) long term expiry.
Better use short lived tokens with auto refresh. For example OAuth tokens. They can be used for the same use cases like PAT, but they expire after a max of 2 hours.
Those access token can still be stolen just the same. The Secure Enclave is better because you can ask it to authorise the action, but you can never get the key out of it, so the latest malicious npm package can’t send off your access tokens or ssh keys.
It's often the case that we make much effort into securing the key but expose it via an open agent socket at a well known path or use an open control master path for multiplexing.
Certain automation and dev tools like Ansible make it a pain to work if agent key requires a confirmation.
Weirdly enough, this is _why_ I ended up using Secretive: I needed a second ssh-agent because selecting which keys are forwarded per-host is very fiddly, and while standard ssh-agent kinda supports it, 1Password doesn't. Anyway, _a_ solution for this is having separate SSH agents, and Secretive is another agent on top of 1Password.
I used yubikeys for ssh for years. First via the older clunky gpg as ssh key feature. Then via the FIDO api. My biggest issue was the chicken and egg issue when using this setup on a new machine or god forbid in a container etc. windows and WLS wasn’t super thrilled either.
I switched to 1Password ssh because I actually like the fact that I can simply share my keys. It’s still not perfect. Agent forwarding needs an extra configuration and depending how many keys you have and how verbose your ssh config gets it becomes also very finicky.
This solution feels for me like a slight setback because it’s a macOS only solution. If you have a Linux or windows machine next to a Mac you have to deal with the insecure key file on your hard drive again either via yubi keys or software solutions.
But I think I would take this over a yubikey. I really disliked the fact that one usb port was constantly in use.
The way I think of it is YubiKeys should be used to basically provision a computer with an approved device specific key. Whether it's a passkey or SE/TPM secured SSH/GPG/TLS key: the Yubikey holds the credential everyone trusts and therefore can be used from any device to gain access and enroll a new approved key.
Sure and pop in whenever I do a git commit? I also sign my commits. I used GPG (different key on the same hardware key) and now via SSH key. I had both a compact and bigger key. I got the compact key because my very first yubikey nearly broke. I lifted my Mac while it was connected and it cracked in the middle. I bought a compact one next which can stay inside and that one you don’t want to take out. It’s so small you’ll lose it. I know because that happened to my backup key … (that was actually the idea for the bigger one I bought but I lost the damn thing during the setup phase)
But having the yubikey bound to your Mac at all times is also stupid because it doesn’t come with a fingerprint or other biometric sensor. The idea is that you use this thing as a token not that you leave the key in the lock at all times. For that alone I would favor the enclave solution.
I was looking in to this just earlier today. The native macos version worries me a little because it seems someone just happened to discover it in MacOS, rather than it being a documented feature. The worry being Apple could change or remove it later locking you out of your keys since they never advertised this as a thing you could do.
I've been using Secretive (a nice software wrapper for these) for a few days for my Github keys (where 1Password holds the rest of my SSH keys). It works nicely, but obviously you can't back up a key that started life in a secure enclave, so you'll need alternative access arrangements for anything you setup that way.
2nd this. Found out about it when this type of thing came up about a week ago. I had a hard time getting the stock stuff going but Secretive made it easy to set up and I love using it.
When I installed WireGuard on macOS, I was happy to discover that it stores private keys in the system keychain. Accessing the private key requires Touch ID.
Then one day after a system upgrade, the WireGuard app crashed on startup with:
Then the app deleted all profiles because they are all "orphaned", apparently for "keychain consistency" [0].From then on, I just use a text editor to edit my WireGuard configuration files, and import them to the app. The bug still exists to this day [1].
[0] https://github.com/WireGuard/wireguard-apple/commit/dfb685f2...
[1] https://www.reddit.com/r/WireGuard/comments/wyt828/osx_wireg...
You linked a commit and a Reddit post. Is there a proper Github issue as well?
It's funny you mentioned that. The GitHub repository is a mirror of https://git.zx2c4.com/wireguard-apple. You cannot create issues there. You're supposed to send a bug report to the mailing list, which is enough friction that none of us did so far.
Emailed per https://news.ycombinator.com/item?id=50450200
Definitely still a bug right? Linked them to your parent comment.
Edit: oops sorry team, think you're on it (4d ago): https://github.com/whyredfire/wireguard-apple/commit/0bac142...
Guess it can serve as feedback on the friction when issues can't simply be opened though!
Thanks! Yes, it is still a bug.
> Edit: oops sorry team, think you're on it (4d ago)
I don't think @zx2c4 has seen this PR, and the author of the PR has not sent a bug report yet, so it's probably fine :P
A lot of the Security Framework came from Classic, hell, the idea of a keychain came from Classic! Just a mess.
The author says he doesn’t like the idea of having keys sitting on his file system ready to be snatched by bad actors.
That’s why they should be passphrase protected.
You use ssh agent to store the keys in memory and for convenience you can store the passphrases in keychain. MacOS OpenSSH has the UseKeychain config directive for that.
I use Yubikey/FIDO2 myself, but not because private keys cannot be protected on a file system.
Assuming the attacker has user rights (which it needs to read the key) it could also read the passphrase, right?
I’ve grown to appreciate ssh should only be used with git for signing commits and as a deploy key (eg in a CI system).
I always use https for day to day git operations. My keys reside in gopass and are extracted by gopass-git-credential when needed by git.
I use that within devcontainers
https://github.com/gopasspw/git-credential-gopass
Better use short lived tokens with auto refresh. For example OAuth tokens. They can be used for the same use cases like PAT, but they expire after a max of 2 hours.
It's often the case that we make much effort into securing the key but expose it via an open agent socket at a well known path or use an open control master path for multiplexing.
Certain automation and dev tools like Ansible make it a pain to work if agent key requires a confirmation.
But I think I would take this over a yubikey. I really disliked the fact that one usb port was constantly in use.
SSH private keys should be passphrase protected.
You don’t have to do that if you use FIDO2 with a Yubikey.
The idea is precisely that you keep them permanently connected in the laptop.
Work on macOS 26 and later.
Definitely a recco from me as well. -- git hub here: https://github.com/maxgoedjen/secretive
Unless you specifically mean (f)TPMs/secure envlaves.