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].

[0] https://github.com/WireGuard/wireguard-apple/commit/dfb685f2...

[1] https://www.reddit.com/r/WireGuard/comments/wyt828/osx_wireg...

The article starts on an incorrect premise.

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.

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

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.

On macOS use “Secretive”. It’s a small app that can generate keys from Secure Enclave and prompts you with touchid whenever those keys are being used

On iOS/ipad/(also macOS) you can also use the SSH terminal emulator Termius which has support for SE keys built in as well. So I have the set of keys synced to my VPS, this way I know that only my physical devices can log in and nothing else.

What's the general consensus around ssh-agent?

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.

Not sure how many people feel like this, the risk in plain sight is a lot easier to handle than the risk hiding under the layers. You can keep shifting the storage for the key, one way or another you have to open up a channel to access to key or use the key. That channel would then become the vulnerability target.

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.

If someone like the native approach or is familiar with SeKey, I created sekey-sh to simplify the process: https://github.com/cavoirom/sekey-sh

Work on macOS 26 and later.

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.

We should have had this 20 years ago. It is almost pathological how difficult it is to reliably use hardware keys as ssh credentials.

[flagged]