Not exactly connected but the same crowd interested in this topic may also be interested in this tool to store SSH private keys in the Secure Enclave, kind of like what can be done with a YubiKey:
I've been looking for something like this for 3-4 years but only found it six months ago (in an HN thread). I use separate keys for every use case, and now know every time a key is used for any purpose, whether it's connecting to source control or my text editor is connecting to a remote VM.
Only thing I haven't figured out is how to do git signatures with these sorts of keys, but I haven't debugged it at all.
I actually tried this and was glad I left myself an out - I had a kernel panic, after which the contents of the secure enclave where wiped with the rest of the system state (to restart from known good settings???). Bye-bye SSH private key. I would recommend caution if you use it.
The same could happen with a hardware token like Yubikey, if it were to suffer from an irrecoverable software or hardware error. It's still useful, because spoofed authentication prompts will no longer get a chance at plaintext access to your password.
Why those things are not built-in to macOS. I don't understand. It should not be hard to implement for Apple engineers and it could be a good example for corresponding API.
I don't use sudo often enough to warrant system changes, so I don't use those programs, but if they would be enabled by default, I would gladly use them.
Secretive is great. I use it on my T2 and M-series Macs and feel much better with keys sitting in those machines' secure enclaves than I did back when it was just sitting in ~/.ssh/ for anything to grab.
I just wish there were something as clean as Secretive for using generic PC TPMs or YubiKeys in place of a Secure Enclave under Windows and Linux. Currently have a Linux laptop halfway through setting that up and it's messy in comparison.
For Windows, it seems it's possible[0, see footnote], however there are problems like general incompatibilities [1], and official support status is " We have this in our backlog. At this point it's not prioritized.".
0.footnote: "Windows Hello also supports other types of authenticators like internal TPM device(if they support generating ECDSA or Ed25519 keys, they can be used instead of FIDO/U2F security keys)."
But it’s not really the same. Having private key material in the secure enclave means that it’s not extractable (except perhaps by state-level attackers with hardware access). With an SSH private key in 1Password there are still many possible software-level attack vectors (vulnerabilities in 1Password, a compromised 1Password update, etc.).
Exactly, these are precisely the features I'm looking for. They are not caveats, they are the way I want my keys to behave.
If there is some sort of use case where I want to be able to backup a key, or share it with someone else I can always fall back to SSH keys on a hard disk. But those are usually anti-patterns.
I know PAM gets criticized here and there, sometimes heavily, but it's actually a super flexible system. The thing that really stands out is that no application actually needs to know about all the various authentication methods possible. That file in /etc/pam.d/ just corresponds to the app's "service name", and you (as the machine administrator) can put in it whatever you want. The app just needs to go "Hey PAM, I want to start authentication using service 'sudo'", and then PAM will send instructions to the app, like "Display the text 'Place your finger on the fingerprint scanner'", or "Display the text 'Password:' and then prompt for masked input".
It's really quite flexible, and despite its age, still works pretty well with current programming paradigms, whether your UI is text or graphical or whatever. The one oddity is that when it asks you to prompt for some kind of user input, it will actually expect you to return the resulting input from the same callback function. So if you're using a modern-ish GUI toolkit, you'll need to run the PAM stuff off on a different thread that's allowed to block while your UI thread is free to do what it needs to do. But overall that's just... fine?
Self plug, but here's a PAM module I made for using gpg for login: https://gitlab.com/rendaw/pamgpgr . I've been using it for a couple years for sudo I think (yubikey).
The code is fairly small so it can be an example for doing other PAM things too.
The API for “Pluggable Authentication Modules” (PAM) seems to be earning its name. It’s an ideal adapter layer for adding interoperable authentication to any program. And since so many programs already consume it, it’s a natural target for new authentication providers to implement. If a backend can serialize its authentication model to users and groups, then it can give those lists to a program that consumes them through PAM to authenticate users and authorize actions.
Thanks to open standards (really POSIX in this case), even a small program can immediately benefit from PAM authentication because it will work in any organizational environment, regardless of whatever over-engineered backend system (like LDAP or Kerberos) or SaaS (like Okta or O365) is providing the list of users and groups.
I was really hoping the article would have explained a bit about PAM. Any high school English teacher can Google instructions for enabling sudo with Touch ID, but I’ve come to expect HN posts to have a higher pedigree.
I've also done this on my Framework laptop running Linux, it's really convenient. Have it set up for sudo, user login, etc. Just added this to various files in /etc/pam.d
I tried this just over a year ago, but it is quite flakey. IIRC because of how PAM works, you have to wait until this PAM module times out before you can switch to another form of authentication. (E.g. because fingerprint authentication fails.)
On my ThinkPad X1 Nano, GNOME under Fedora 35 and 36 offer the ability to use the fingerprint sensor for login and sudo in the Settings app. Pretty nice.
This nicely did the trick! Adding the line at the top of /etc/pam.d/system-auth makes sudo authenticate use the fingerprint, which is nicer than always typing my password and gives a streamlined experience between SDDM and sudo.
Every MacOS update, I do run a sudo command and get the password prompt. I cancel, and instead do...
sudo cp ~/Dropbox/etc-pam.d-sudo /etc/pam.d/sudo
Type the password once and you're done. I've been carrying this around for quite a while. No need to edit the file every MacOS, just copy it.
But once it did utterly go south when Dropbox's "load files on demand" functionality replaced the file with a bunch of zero bytes. That wasn't fun to fix. So maybe Dropbox isn't the best storage place.
Consider storing a diff instead of replacing the file completely. If the patch fails (either because the diff is all zeros or the file has changed in some material way), you can proceed with the appropriate fix.
Thanks for sharing. While tweaking the formatting, I accidentally introduced a typo which led to me spending a few minutes hunting for a fix for "sudo: unable to initialize PAM: No such process" without having to reboot :(
Anyway, here's the version of your one-liner I used to preserve the spacing used in the rest of the file:
I did this when the touch ID macs were first released and very quickly disabled it.
Why? Because asking for a password for su / sudo broke the flow -- not only did I have to move my right hand from the home row (or both, for my watch), but it popped up a modal-like window away from where my eyes were. Basically it impinged on my focus.
Also, with sudo, I think a lot of the value is the inconvenience of typing out a password. Having to stop and think and type is a nice guardrail that I think fingerprint-based auth would remove.
The sudoers file on my Mac is configured to always show the disclaimer (and I deleted the Apple written one so it shows the original disclaimer too). It’s definitely made me stop and think once or twice before brew did something I didn’t want it to (or if I forgot which terminal I was in).
Does watch unlock now work natively with pam_tid? I know as of at least a few months ago it would only work if you could use touch ID, i.e. when the laptop was open. If it was docked, it would fall back to password auth.
I wrote a patcher that changed this behavior, it patched pam_tid directly on your system and just updates the API Apple calls to allow unlocking with watch-only when touch ID is unavailable:
This needs to be applied after every system update. Apart of that, it works really well (I have very dry skin so touch ID works for me 50% on a good day)
Guilherme’s stuff is great. pam-watchid is a reimplementation of Apple’s pam_touchid, but uses the other authentication flag which I patch in to the original binary.
I see this post pop up often so I think there's demand. But Apple only cares about solutions that make money, and this one doesn't. With Apple, I'd expect them more to block free solutions, and require an iCloud subscription to enable it.
macOS already does fallback for this just fine: if an application requests authentication with the Secure Enclave, I'm prompted to touch the touch ID sensor if my laptop is open, but if it's closed and I'm using a docking station, it just asks for my password instead. No reason why remote ssh can't work the same way.
Readit News
https://github.com/maxgoedjen/secretive
I've been looking for something like this for 3-4 years but only found it six months ago (in an HN thread). I use separate keys for every use case, and now know every time a key is used for any purpose, whether it's connecting to source control or my text editor is connecting to a remote VM.
Only thing I haven't figured out is how to do git signatures with these sorts of keys, but I haven't debugged it at all.
I don't use sudo often enough to warrant system changes, so I don't use those programs, but if they would be enabled by default, I would gladly use them.
I just wish there were something as clean as Secretive for using generic PC TPMs or YubiKeys in place of a Secure Enclave under Windows and Linux. Currently have a Linux laptop halfway through setting that up and it's messy in comparison.
`ssh-keygen -t ed25516-sk` or `ecdsa-sk` and then you touch your yubikey when unlocking the key, the same time as you would type a password.
Question for anyone else reading: Does it make sense to use a password with -sk keys? I don't think it would make a difference either way.
0: https://github.com/tavrez/openssh-sk-winhello
0.footnote: "Windows Hello also supports other types of authenticators like internal TPM device(if they support generating ECDSA or Ed25519 keys, they can be used instead of FIDO/U2F security keys)."
1: https://github.com/tavrez/openssh-sk-winhello/issues
2: https://github.com/PowerShell/Win32-OpenSSH/issues/1804#issu...
https://blog.1password.com/1password-ssh-agent/
- You cannot import your existing SSH keys
- You cannot transfer SSH keys if you get a new machine
BTW, if you have a key that you copy around to multiple machines, you’re doing it wrong!
If there is some sort of use case where I want to be able to backup a key, or share it with someone else I can always fall back to SSH keys on a hard disk. But those are usually anti-patterns.
It's really quite flexible, and despite its age, still works pretty well with current programming paradigms, whether your UI is text or graphical or whatever. The one oddity is that when it asks you to prompt for some kind of user input, it will actually expect you to return the resulting input from the same callback function. So if you're using a modern-ish GUI toolkit, you'll need to run the PAM stuff off on a different thread that's allowed to block while your UI thread is free to do what it needs to do. But overall that's just... fine?
The code is fairly small so it can be an example for doing other PAM things too.
Thanks to open standards (really POSIX in this case), even a small program can immediately benefit from PAM authentication because it will work in any organizational environment, regardless of whatever over-engineered backend system (like LDAP or Kerberos) or SaaS (like Okta or O365) is providing the list of users and groups.
But once it did utterly go south when Dropbox's "load files on demand" functionality replaced the file with a bunch of zero bytes. That wasn't fun to fix. So maybe Dropbox isn't the best storage place.
Anyway, here's the version of your one-liner I used to preserve the spacing used in the rest of the file:
Why? Because asking for a password for su / sudo broke the flow -- not only did I have to move my right hand from the home row (or both, for my watch), but it popped up a modal-like window away from where my eyes were. Basically it impinged on my focus.
Nice idea, not so nice in practice.
I wrote a patcher that changed this behavior, it patched pam_tid directly on your system and just updates the API Apple calls to allow unlocking with watch-only when touch ID is unavailable:
https://github.com/inickt/pam_wtid
Was a fun reverse engineering experience and wrote up some more info in the README.
https://github.com/insidegui/pam-watchid
... and my /etc/pam.d/sudo needs to be changed like this:
This needs to be applied after every system update. Apart of that, it works really well (I have very dry skin so touch ID works for me 50% on a good day)Deleted Comment