Setting Up SSH Keys on macOS with Touch ID

Posted by civilchaos 1 day ago

Comments

Comment by maratc 1 day ago

> No key files (like ~/.ssh/id_ed25519.pub and friends) littering the file system; and there’s no risk of mistakenly deleting them either.

Or backing them up, or copying them to your new computer. You're just one spilled coffee cup away from losing the key.

Comment by jwr 1 day ago

That was my first thought, too — this might work as one of additional methods of logging in, but not as the only one.

I have been using YubiKeys for many years now, following this guide: https://github.com/drduh/YubiKey-Guide

This means I can have secure private keys for ssh and gpg (cue the crowd saying gpg is insecure without offering good modern alternatives), which I can also back up. And I can set up multiple YubiKeys, which I do.

An additional advantage of this solution is that you can set your YubiKey to require a touch confirmation before performing an operation. This makes it much harder for runaway AI agents to wreak havoc on your servers: there is a physical limitation, which I really like.

Comment by LeBit 1 day ago

I too use (multiple) yubikey to hold my private gpg keys.

But I am not sure I will stick with gpg though.

Even with my system to extend their expiration or renew them. I have found handling them to be a pain.

I use them for 2 things: encrypt/decrypt gopass secrets and sign git commits.

Gopass now has more than decent age support. A yubikey can hold an age key.

Most git forges accept a ssh key to sign commits. A yubikey can hold a ssh key.

So, for my needs, I think I could leave the operational complexities (to me) of gpg and go for alternatives that are simpler.

Comment by 0x457 17 hours ago

You should never have a single ssh key as mean to login anyway. My keys never leave device that created them, but every device has its own pair, plus yubikey-like key.

Comment by zikduruqe 22 hours ago

You don't even need a YubiKey to have an authentication subkey.

Just a random site - https://opensource.com/article/19/4/gpg-subkeys-ssh

Comment by FooBarWidget 1 day ago

I don't get it even after reading the guide. How do you deal with backups when using YubiKeys? The private key is stored on the YubiKey with no ability to export it, ok... then what do you do when you lose the YubiKey?

Are you supposed to have multiple YubiKeys (multiple private keys) and then ensure that all your systems accept the matching multiple pubkeys?

The guide's Backup section is... super vague. It says exporting keys, of which some are private keys, which I thought shouldn't be possible?? And then it goes off about partitioning and filesystems?

Comment by jwr 6 hours ago

> How do you deal with backups when using YubiKeys

You generate your gpg key on a computer, back it up securely, then store it in the YubiKey and delete the unprotected version on the computer.

This allows you to have multiple YubiKeys with the same private key.

However, nothing prevents you from generating private keys on the YubiKey and using multiple Yubikeys. Or doing a combination of the two approaches.

Comment by AdamGibbins 18 hours ago

Yes, you have multiple Yubikey's and store them independently.

Comment by cedws 1 day ago

You aren't supposed to be moving SSH keys. They should stay on the machine they were generated on. The less accessible they are the better.

I really wouldn't rely on an SSH key as the sole way of accessing a machine.

Comment by maratc 15 hours ago

This works for some scenarios but not other ones. I, for one, deal with ephemeral VMs.

Comment by cedws 7 hours ago

Why not use agent forwarding?

Comment by maratc 6 hours ago

Where possible I do, of course, but some compute resources either don't allow to ssh in (e.g. k8s) or are configured to refuse ssh from anyone but root. I can become root on a jump box and ssh from there, but I lose agent forwarding in the process.

Comment by nmattia 1 day ago

I very much prefer to have one key per device! That allows for fine grained access control. In general I wouldn’t export private keys unless really necessary.

Comment by rustyhancock 1 day ago

Yes I don't see how that's helpful.

It's quite opposite of what I'd want.

If you use a trezor hardware wallet (and probably other hardware wallets) you can deterministically regenerate -sk keys.

I use trezors various agents for AGE, FIDO2/passkey, ssh[0].

But you still need the backup some bits of material like stubs for some FIDO keys (not secret material) that need importing into fresh trezor devices.

It's approaching the never lose a key again levels.

Of course, I won't pretend there isn't an obvious issue. What if you lose the seed words or someone gains access. What if the software becomes incompatible, or trezor devices become expensive/change etc.

[0] https://github.com/romanz/trezor-agent

Comment by littlecranky67 1 day ago

cough ledger, cough coldcard cough, supply chain attacks cough cough

Comment by rustyhancock 1 day ago

This attack on ledger was particularly impressive, with LTE modules and eSIMs used to exfiltrate secret material[0].

But ledger is one I wouldn't recommend even without these issues, they've previously stockpiled customer data which leaked and lead sustained targeted attacks on their customers.

They've got some sort of method of getting the secret keys out of the secure elements - which makes you think what's the point at all? Oh so they can sell you a backup service subscription for your keys. Which were meant to never leave your device.

[0] https://www.coindesk.com/tech/2026/10/13/ledger-says-spy-chi...

Comment by citrin_ru 1 day ago

You could generate an additional backup key pair, add to authorized_keys on remote hosts in additional to the stored in enclave key, test then backup and wipe from your macbook (to reduce compromise risk).

Comment by jiehong 1 day ago

Yes, this only works if you can register more than 1 ssh keys on the services you want.

Comment by mschuster91 1 day ago

Which you can do pretty much anywhere already? I'm at least not aware of any major service not allowing you to register multiple SSH public keys.

With the obvious exception being, for whatever reason, AWS that only allows specifying ONE SINGLE KEYPAIR when creating new EC2 VMs. Whyyyyyyyyyyyyyy?!

Comment by maratc 1 day ago

When I was checking out their git hosting service (AWS CodeCommit), they only allowed for rsa keys (and not ed25519, for example.)

Comment by QGQBGdeZREunxLe 1 day ago

Sounds complicated. Just install https://secretive.dev/

Comment by Puts 1 day ago

It's literately TWO shell commands? One for generating the key in the secure enclave and one for adding it to ssh-agent?

Comment by ulimn 1 day ago

I've been using Secretive for years because I didn't bother looking it up how to do it without. I think this is worth doing without an additional third party, especially since it's only a few commands.

Comment by ggm 1 day ago

If you do this, have at least one backup key (if need be on paper) or a guaranteed alternate path into the hosts you depend on this key to access. Because if the secure enclave is as good as we're told, if you lose access to ->THIS<- secure enclave, its game over for the keys.

Secure enclave protecting Keychain, the keychain is backed up. Not the contents of the enclave.

Too many failed access attempts? poof the key is gone. Could be as low as 10.

(happy to be corrected. This is what I gather from a quick read-around. I was a bit surprised the site didn't seem to discuss this)

Comment by solatic 1 day ago

Your backup key should also be in a secure enclave, just in a different secure enclave. Both keys should be accepted by the system.

The truly paranoid can multiple types of secure enclaves - TouchID for primary, a YubiKey for backup.

> If need be on paper

Your security is only as strong as its weakest link. Paper has a way of getting photographed, and the privacy of your key depends on your OCR software, unless you really want to painstakingly copy it in by hand, and even then, it turns into a file-based key on the filesystem, with all its attendant risks.

Comment by littlecranky67 1 day ago

No, paper for cold storage has the advantage of requiring physical access. Not some virus or hacker breaking into your computer from hundreds of miles away. If you are living in the US, gun ownership provides additional security over this piece of paper at home.

Comment by solatic 1 day ago

> requiring physical access

This is the whole idea behind storing keys in the secure enclave. You can just as easily store the backup YubiKey in a safe as well.

Comment by gmac 1 day ago

Right, because shooting someone for the sake of a piece of paper is usually a proportionate response …

Comment by littlecranky67 23 hours ago

It is not the piece of paper but the property it represents. If it is a Wallet with just as much as 1 Bitcoin on it, I would should you if you were trying to take it from me illegaly - also considering the fact that you are probably in my house without my consent, which one might argue doesn't even require me to have that piece of paper in my house.

Comment by entrope 1 day ago

If someone is looking for that particular piece of paper, they probably want it for reasons that distinguish it from the average piece of paper. Also, most defensive gun uses end without shots being fired, so "usually" nobody even has a bullet fired at them.

Comment by gurjeet 1 day ago

Just in case it helps someone, a while ago I wrote a blog post with exact CLI invocations to set up a local-password-store protected by TouchID. If you wish, the encrypted password-store can be backed up and tracked with a Git.

> PasswordStore (`pass`) + GnuPG (`gpg`) + TouchID

> https://gurjeet.singh.im/blog/passwordstore+gnupg+touchid

Comment by apimade 1 day ago

Crazy that this particular feature we’ve all been waiting for hasn’t received first-party support by any DevEx company.

You know, the companies that say security is their number one priority, or companies that scream “developers, developers, developers”. How Google and Apple didn’t come up with something together eludes me, but then again, we have entire ecosystems and categories deployed in the areas they don’t service (auth, application control, etc).

Comment by elmcrest 1 day ago

happy 1Password user since years, provides this too and you'll have you ssh keys in the 1P keychain (yes, not open source, I know - only flaw imho)

Comment by lmz 1 day ago

That would make it extractable and syncable to other hosts. That's fine if that's what you want but it's an important distinction.

Comment by elmcrest 1 day ago

yes, that's exactly what I want :) (and the private key is only living inside 1Password and isn't extractable from there)

Comment by cromka 1 day ago

Typically you want to generate one key per host. That's why, by default, a new key bears a user@host identifier.

If it gets compromised, you need to revoke this one key only and still maintain access from, presumably, other systems of yours.

Comment by mercutio2 1 day ago

You’re mistaken. 1Password syncs keys. Therefore, they’re extractable.

Comment by lmz 1 day ago

https://www.1password.dev/ssh/manage-keys#export-an-ssh-key

Comment by LetMeLogin 1 day ago

I am doing the same, such a great underrated feature that many people do not know of.

Comment by vr46 1 day ago

As cool as this is, this does limit the functionality of your keys, because not everything can access the secure enclave in the way it wants to - and as others point out, this is a one-way street and locks your mac hardware into the flow.

I went with this system for some months but it ultimately broke my workflow. I switched to a system of my own devising, in which my local security key decrypts the SSH keys I require.

Comment by devjam 1 day ago

You can also use a password manager like 1Password [1] to store your private keys, and use a local socket for your SSH agent to automatically unlock using TouchID.

[1] https://1password.com/developers/ssh

Comment by citrin_ru 1 day ago

If I knew it's relatively easy I would have saved $$ on yubikey - for personal projects security requirements are not high but it's good to have something better than a file which could be stolen by malware. Kudos to author for the how-to.

Comment by XYen0n 1 day ago

The version of OpenSSH included with macOS does not support FIDO-related features and instead uses the relevant parameters to access the macOS Keychain, so I always have to install OpenSSH from nixpkgs myself.

Comment by nmattia 1 day ago

It’s a new feature! In Tahoe & Golden Gate at the very least FIDO is supported by the SSH agent

Comment by pentakkusu 1 day ago

No way, I just wondered if there is a way to do this myself... Having to type in my password was getting tedious for my lazy self.

Comment by michael-sumner 1 day ago

so the TouchID is a "Yubikey" but if you lose the Mac then you lose that hardware key?

Comment by 2III7 1 day ago

If you lose a Yubikey you also lose the... key.

Comment by throw0101a 1 day ago

Another article/discussion from ~year ago on doing the same thing, "Native Secure Enclave backed SSH keys on macOS":

* https://news.ycombinator.com/item?id=46025721

Comment by sgarland 20 hours ago

Thank you for raising this, as it predates TFA by a year, and also correctly cites their source.