YubiKeys were the only solution that fit these requirements, so I went with those. I have been using them for the last ten years or so and I've been very happy with this solution. See https://github.com/drduh/YubiKey-Guide for a description of how to make your RSA keys stored on YubiKeys work with GPG and SSH at the same time.
This is why I'm skeptical that the approach can scale reliably, even though I'm relying on it today. (Yes, PATs would fix this, but the enclave model is what I'm trying to retain for now.) What I've done instead is wrote a small daemon that sets the SSH authentication socket and does agent forwarding. This works when I'm traveling with laptop...but not yet from my mobile phone.
Example:
Laptop Remote Mac
┌─────────────────────┐ ┌──────────────────────────┐
│ Secretive │ │ ssh / git commit -S │
│ (Secure Enclave) │ │ │ │
│ ▲ │ ForwardAgent │ ▼ │
│ └── ssh ─────┼─────────────────►│ ~/.ssh/agent.sock │
│ │ │ (stable proxy) │
└─────────────────────┘ │ │ │ │
│ ▼ ▼ │
│ forwarded local │
│ laptop Secretive │
│ agent (if you sit │
│ at this Mac)│
└──────────────────────────┘
I'm not using the secure enclave, but I've been using YubiKeys for many years, and now that AI has arrived, I consider the above to be a good thing.
This means, for example, that unless I am physically present with my key inserted, activated, and touched on every operation, an AI agent cannot access any of my production servers. As I do not want AI agents to access my production servers, this is a very good protection technique. I am assuming that no matter how well you try to sandbox and restrict your AI agents running on your local machine, they might eventually be able to access any file in the file system.
1. The Secure Enclave being inaccessible when you're not present is a feature, not a bug. If you need to run headless then its not the correct solution to your problem and you'll have to find another.
2. You don't need an SSH agent proxy, you can use a `match` block in your `ssh_config` with something like `host * exec "test -z $SSH_TTY` to check whether you're operating over an SSH connection and select Secretive's SSH agent if you're using the machine locally.
I’m a happy user!
SSH keys in plaintext was one of the first thing that bagel [0] our developer endpoint secret detection focused on. Then we embedded bagel as a library in our developer endpoint protection [1].
[0] https://boostsecurityio.github.io/bagel/ [1] https://boostsecurityio.github.io/dazio/docs/install/
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?
Update: I tried it out and stand corrected. ssh-add doesn’t store it in the user-readable keychain. So the passphrase is protected. (And also not recoverable by the user).
I found I was getting fingerprint fatigue. Do I need a fingerprint request every time my dev server wants to connect to dev Supabase? No. That's expected, and zero risk. There's no data there.
I worried that a nefarious request would be auto-approved by me. When you see 20 requests a day, your muscle memory just reaches for the sensor.
So I have a separate 1Password vault that a service account [0] can read. That token is in my environment as OP_SERVICE_ACCOUNT_TOKEN, which the `op` tool understands.
It also has access to a vault with 'AI-safe' keys that I want Claude to be able to access without asking me.
Now, these requests work invisibly. And when I see a fingerprint popup, it's unusual, and I don't auto-approve by habit.
I also keep an item called '_One-day keys' in a separate vault. (The underscore just pushing it to the top of the list for easy access.)
It has prod keys, mostly restricted read-only. If required, I move that over to the open vault. Claude knows this item and has instructions to remind me to move it back out when it's finished what it was doing.
It's effectively an open source version of a YubiKey, the hardware itself is all open source and it handles ed255519 SSH keys really well.
inb4 they're not the same, I know, I really like what the TKey team is doing.
It is not one of the cryptographically safe curves, likely intentionally so.
> https://news.ycombinator.com/item?id=46025721
One of the problems I constantly face is that the SSH configuration is not portable when I use these esoteric things. Even with Secretive (which plugs a simple SSH socket), remote agent forwarding sometimes fail. (ie. Due to the old version on the server or configuration issue, or something else setting SSH_AUTH_SOCK...)
Moreover, it is not possible to drop these files into a file-sharing folder, like OneDrive or iCloudDrive or SMB share, and share them with many hosts at the same time. (Especially when different operating systems are involved...)
I found the hacker way simplest and easiest; put a basic Makefile with bunch of rules, have a "central" host/machine to distribute the keys and configuration from that point on...
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.
It’s a mind shift worth considering.
You then can accept that your ssh keys are different per hardware token (because the private key cannot be extracted).
No more sharing of private keys in your password manager.
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
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 would be nice if GitHub or GitLab could limit a token to a given IP, but with how proxies and dynamic ips work I would imagine it would be a hassle to get it working correctly for everyone, but it’s better than nothing.
Host github.com
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_ed25519
This is the most recent one I found via Googling, I have not actually used this product:
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.
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.
I think this is incorrect and the "ssh:" at the end is indeed a comment.
Work on macOS 26 and later.
No more passwords to enter anywhere, and whatever an (AI) agent or malware is trying to do will require a human interaction at least, and not work when the screen is locked. The public keys authorized for this are distributed to the fleet via puppet, so we get control over who gets to sudo permissions and can easily provision or decommission machines.
Pretty stoked about it so far.
Definitely a recco from me as well. -- git hub here: https://github.com/maxgoedjen/secretive
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...
A lot of the Security Framework came from Classic, hell, the idea of a keychain came from Classic! Just a mess.
For platforms where development is unhindered by arbitrary obstacles like these and others, wireguard works fine. :)
And features built for normal people
The overlap is very rare
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
Its unfortunate no updates for Wireguard macOS have been pushed out for 3 years, App Store is still showing 1.0.16 as the latest version – as also confirmed on the Wireguard website at the latest version.
No doubt macOS APIs have moved on a lot in 3 years and so perhaps bugs that are being seen are simply a reflection of the lack of updates to keep up with API changes ? Just thinking aloud here, I don't know if the concept of OS API changes are applicable to this particular PR / bug.
I appreciate when both options exist, because I've passed on reporting so many bugs, because I refuse to create a Microsoft account to do it.
In fact, I don't understand how sending an email is high friction.
99% of the time it's perfectly fine to just email the maintainer with a bug report and maybe a patch.
> In fact, I don't understand how sending an email is high friction.
Judging from the fact that after so many years, such a widespread (as seen in the Reddit post and here) issue still hasn't resulted in a single bug report in the mailing list, I'd say most people (including myself) do indeed consider using a mailing list to be higher friction.
If I'm not mistaken, unless you're already CC'ed by a participant, you'd have to subscribe to the whole mailing list just to receive notifications for a single thread. For an "issue" on a Git forge, participation is usually as easy as upvoting and then clicking the "Subscribe" button.
In the current age, its useful because AI will submit tickets using the CLI that don't use the form, so I can immediately close and lock them and go on living my life.