Setting up SSH keys on macOS with Touch ID
51 points by nmattia
51 points by nmattia
To make it a bit less tedious adding back the key after a reboot I export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib so that I only need to type ssh-add -K
Yep, that's a good idea! You can also set it in the ~/.ssh/config: https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb4acf#using-the-securitykeyprovider-by-default
I added it explicitly in the post because I'm a big fan of less hardcoded configuration, and so that it can be enabled/disabled explicitly (you may not always want to use ssh-keychain when adding keys). Maybe should I have mentioned it though!
Cool! I personally use Secretive for this but I had no idea you could do it all with OS-provided tooling.
It's recent that macOS ships with all the tools to do this natively. I prefer to avoid relying on 3rd party tools but I read some good things about Secretive while researching this!
Post author here. This was the result of a lot of experimentation; if there are experts that want to chime in, I'd love to hear your thoughts!
Thanks for writing this, I will have to try it out. I only skimmed the article because I'm not familiar with a lot of the secure enclave/Apple-specific stuff, but I have a question: Does this setup require biometric authentication every time the key is used, or does the system "remember" your authorization for some length of time?
When I use regular SSH keys on my desktop machines, I typically set the SSH key passphrase to be the same as the login passphrase and then configure the OS/desktop to unlock the SSH key automatically on login. This is reasonably secure and very convenient, especially since I often connect to various hosts through automation. (SSHFS, Ansible, etc.)
Cool stuff.
Key management depends on how you use your setup I suppose. I share SSH keys between machines, so in my case 1Password handles it nicely, but there are drawbacks as well (e.g. some systems are not well supported).
I can see plenty of reasons to go one key per laptop though, but since I use roughly 3 different Apple laptops and ~5 systems (in total) that I want to be able to SSH from, and the targets number is 10+ (RPis, Linux boxes, routers, etc.), key distribution becomes a real pain for me.
Agreed, there's different ways to go about this. For what it's worth I also have a couple of MacBooks and some linux systems, but they each get their own SSH key. That way I have more fine-grained (per-machine) access control.
Sorry if this is a dumb question: do you simply save the private key to 1Password and copy it to new machines, or does 1pass act as a security key provider for SSH?
1P can be used to generate or save existing ssh keys. The app knows that the type of secret is an ssh key. There's a background agent that needs to be enabled. At that point you just configure the IdentityAgent socket:
IdentityAgent "~/Library/Group Containers/ABC.com.1password/t/agent.sock"
Then the SSH agent will trigger a touchID authentication during session init and wait for your fingerprint. The data is synced via cloud, so when I setup a new machine, all I have to do is setup 1P via mobile QR code and I have access to all my private keys.
I see, thanks! I guess this means you can only use 1Password keys, since you're bypassing the default agent? Or does 1Pass also go look for keys in ~/.ssh?
Not exactly true, you can set IdentityAgent per host or hosts by using match blocks in your ssh configuration file.
I guess this means you can only use 1Password keys, since you're bypassing the default agent?
That's correct. In order to use the default ssh agent, when I connect to the M4 or M1 via SSH, I have to comment the 1P integration (the line I shared earlier). In that can I use ssh forwarding, which works pretty well (I still get the touchID auth).
ps. @JustinAzoff is correct, you can have multiple IdentityAgent sections in your config and thus, you can direct the client to which socket to connect for keys.
Copying private keys away from the machine they were generated on is generally to be avoided. You could accidentally leave them somewhere you don't mean to (temp directory, thumb drive), or someone could steal/pwn one of your machines.
SSH certificates are the solution you're looking for. You can set up a CA and then sign both host and user public keys with it. This avoids having to share/distribute user keys, and also solves the weakness of trust-on-first-use when connecting to a host for the first time. (Literally nobody verifies key fingerprints.) Setting up the CA and then using it to sign keys is of course a little work the first time but it can be automated.
Copying private keys away from the machine they were generated on is generally to be avoided.
I agree. In my setup the private key lives in the 1P vault and it's accessible during the ssh session via touchID auth. The vault is then synced from one laptop to the next via cloud. Same with passkeys and all other secrets.
You can set up a CA and then sign both host and user public keys with it.
For my setup that would really be an overkill. It's a SOHO after all. These are pets not cattle. :-)
"set up a CA" is really simple.
ssh-keygen -t ed25519 -f certificate_authority -C "User Certificate Authority"
copy to server and add this to your sshd_config:
TrustedUserCAKeys /etc/ssh/certificate_authority.pub
Then you sign your ssh public key:
ssh-keygen -s certificate_authority -I $(uuidgen) -z '0001' -n username id_ed25519.pub
ssh config:
Host server01
User username
IdentitiesOnly yes
IdentityFile ~/.ssh/id_ed25519
CertificateFile ~/.ssh/id_ed25519-cert.pub
The private material cannot be extracted, is never shown, cannot be stolen
Does this also mean you cannot back up your private key? I guess it's less important for SSH compared to something like GPG, but I still have physical prints of the keys I deem important in case of hardware failure.
I ran into a similar question a while ago when trying to do something similar using a Yubikey as an SSH key. The procedure used in the blog post here generates the key in-enclave, which is the most secure from a privacy perspective (if it has never left the secure enclave it can't be intercepted) but not the most secure from an availability perspective (you don't have a way to back it up).
On the Yubikey side, my strategy was to generate the key off-Yubikey, back it up (I put it on a USB drive with a passphrase and then put it in my safe), and then load it onto the Yubikey. Slight tradeoff here in that the key does exist in memory in plaintext at one point, so technically open to interception by malware or whatever, but I do get a backup of it.
I haven't tried it, but based on what was in the blog post I looked at the man page for sc_util and it does have import-ctk-identities and import-ctk-certificate sub-commands as well. The import-ctk-identities sub-command explicitly has a flag to specify how the private key is protected inside the PKCS#12 archive, so that at least suggests to me that you could do a similar flow where you generate a private key, import it into the enclave, and then delete the key material from your machine (or remove the media the key is stored on).
Nice!
Do you know if it’s possible to do GPG commit signing in Git with this? (I.e. private key in the enclave.)
Git can use an SSH key for its signing, so yes it can as long as you’re not tied to explicitly GPG keys.
Oh, that's a great question. I would need to research this a bit but my guess would be yes theoretically, though in practice it might require some finicking!
And of course, thanks to Anthropic, we can now trust NIST P-256 ;)
(Secure Enclave only supports P-256 keys)