HN

Comments (85)

• Menu

  database64128
  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...
• Menu

  mavam
  One fundamental problem with agentic development is that accessing the secure enclave key requires human presence. If you're running headless and aren't logged in, Secretive (not sure about others) will not be able to access the enclave, even when you only chose "notify" and not "touchid".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)│ └──────────────────────────┘ NB: I'm not using Rex instead of herdr and because Rex uses its own protocol, I always need to have one SSH tunnel to reset the remote agent socket. Not optimal, but it works. All of this feels wrong from a UX perspective, and it feels like I'm holding on too hard on secure enclave for what my use cases are. Feedback appreciated!
• Menu

  jen729w
  I use 1Password's `op` for this, but with an allowance: my dev environment keys.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.[0]: https://www.1password.dev/service-accounts/get-started
• flexorium
  I’ve been a happy user of Secretive for years, including for Git commit signature which it make it a separate key with interaction but not for pull / push. I find the trade off ideal for GitHub.com and have other keys with different setup for servers.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/
• spacelatte
  The `sc_auth` trick was posted about a year ago, since macOS 26 Tahoe added the SSH related functions into the keychain.dylib.> https://news.ycombinator.com/item?id=46025721One 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...
• Menu

  LeBit
  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.
• esskay
  It's a shame that the poster doesn't mention what they ended up using instead in their update. Presumably a hardware key.
• Menu

  dsenkus
  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
• gsliepen
  Secure Enclave, TPM and other such security features are unfortunately so badly documented and need so many hoops to jump through to get them working, with any mistake either causing you to be locked out completely or to not give you the protection you wanted. There really should be a better way to make these technologies usable...
• dylanger
  You should checkout the TKey (https://www.tillitis.se/products/tkey/)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.
• Menu

  computerfriend
  I wish there was a way to cache the touch. As it stands, this is mostly unusable for commit signing in a rebase-heavy workflow.
• Menu

  larusso
  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.
• Menu

  newman314
  The thing I don't like about the Secure Enclave is that it does not yet support ed25519 keys.
• artdigital
  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 usedOn 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.
• Menu

  devsda
  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.
• dev_l1x_be
  Somebody posted a tool here in the last couple of weeks that was doing this (using macos secure storage for local credentials/ keys)
• Menu

  sandeepkd
  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.
• Menu

  Gigachad
  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.
• computerfriend
  > That ssh: at the end is the FIDO2 application ID — it’s part of the key, not a comment.I think this is incorrect and the "ssh:" at the end is indeed a comment.
• cavoirom
  If someone like the native approach or is familiar with SeKey, I created sekey-sh to simplify the process: https://github.com/cavoirom/sekey-shWork on macOS 26 and later.
• Menu

  dostick
  Isn't a GitHub app project Secretive doing that but better?
• Menu

  petesergeant
  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.
• asma33
  .
• sssswsww
  1
• Menu

  bdamm
  We should have had this 20 years ago. It is almost pathological how difficult it is to reliably use hardware keys as ssh credentials.
• sssswsww
  ss
• asma33
  ..
• botanica_labs
  [dead]
• getbrew
  [flagged]