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
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!
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!
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.)
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:
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?
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. :-)
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.
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!
msangi | 9 hours ago
To make it a bit less tedious adding back the key after a reboot I export
SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylibso that I only need to typessh-add -K[OP] nmattia | 9 hours ago
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!
eta | 10 hours ago
Cool! I personally use Secretive for this but I had no idea you could do it all with OS-provided tooling.
[OP] nmattia | 10 hours ago
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!
bityard | 5 hours ago
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.)
nikaro | 3 hours ago
Then you could use
-t none(instead of-t bio), this would do the sme as your current setup.[OP] nmattia | 11 hours ago
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!
atmosx | 9 hours ago
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.
[OP] nmattia | 9 hours ago
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?
atmosx | 8 hours ago
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:
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.
See: https://www.1password.dev/ssh
[OP] nmattia | 8 hours ago
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?JustinAzoff | 7 hours ago
Not exactly true, you can set IdentityAgent per host or hosts by using match blocks in your ssh configuration file.
atmosx | 7 hours ago
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
IdentityAgentsections in your config and thus, you can direct the client to which socket to connect for keys.bityard | 5 hours ago
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.
atmosx | 4 hours ago
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.
For my setup that would really be an overkill. It's a SOHO after all. These are pets not cattle. :-)
bramh | 39 minutes ago
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.
iv | 11 hours ago
Nice!
Do you know if it’s possible to do GPG commit signing in Git with this? (I.e. private key in the enclave.)
adamcstephens | 9 hours ago
Git can use an SSH key for its signing, so yes it can as long as you’re not tied to explicitly GPG keys.
[OP] nmattia | 10 hours ago
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!