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.
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.
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'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.
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:
> Keep in mind that this file is somewhat protected by macOS so after each OS update you will need to add the line to the file. Other than that, it works perfectly!
TIL, I wondered why every time I did this it would reset after a while. Thanks!
if ! grep -q "pam_tid.so" /etc/pam.d/sudo ; then
echo "touch ID no longer enabled for sudo. Insert the following line as line 2 in /etc/pam.d/sudo:"
echo " auth sufficient pam_tid.so # enables touch id auth for sudo"
fi
I've been wanting to write a simple script or app that just runs on startup to check for and fix this, but I've been so lazy. It is just too easy to edit the file and move on...
In the same vein, I recently made a tool to use TouchID and the Secure Enclave to protect arbitrary data and env variables from the commandline: https://github.com/pathtofile/toucli
It is just an additional authentication mechanism to a list of various ones. If the client (COM port terminal, KVM terminal, SSH client, bare /dev/tty or any other client you can think of) does not support this mechanism, it will go for another one.
I like that you can do this and appreciate the knowledge, but it seems slower than just typing in your password, and kind of breaks my flow by removing my hand from the home row.
That depends on how long your password is I guess. I much prefer Touch ID personally it probably takes about the same time as typing my password but there’s no chance of a mistake or typo. It’s pretty seamless in my experience.
I set this up a few years ago and it's been very handy. I can also use my Apple Watch to authenticate certain things on my Mac, so I should try to set this up for sudo. Maybe my Yubikey as well.
I use external monitors now and leave my MacBook closed in a dock, so it would be nice if I could use an external fingerprint reader that I plug in via USB. I guess the Yubikey is sort of like this, but it's probably not as secure as using a fingerprint.
Except... is it just me, or is TouchID on MacOS unreliable for mostly everyone? It seems like I have a 25% success rate with TouchID. I have the same fingerprint mapped to three "fingers" and still it's awful.
I've noticed people saying this over on MacRumors, but my experience is exactly the opposite. I have a single finger set up as a single fingerprint, on a M1 Air, and it's been 100 % since I got the machine 20 months ago.
Like literally 100 %, I don't think I've ever had to touch the sensor twice or wait more than half a second.
PS: My hands don't sweat much and I keep the keyboard clean and without dust.
My wife does a lot of garden work. When she set up TouchID in the winter, it worked fine – until the gardening season started. Then it gradually became more unreliable, until it stopped working altogether. Then early last fall, when she went to the police station for a new ID card, their fingerprint reader was unable to read a fingerprint from any finger. She was told that this is not uncommon for people who do garden work, rock climbing, or some other kinds of manual labour. Their fingerprints just wear down enough for the reader not to be able to read them. – But not completely. Burglars beware. ;-)
Mine works nearly perfect. But an ex-colleague of mine couldn't use any interface with fingerprint recognition. Not the laptop, nor the phone, nor the (presumaby fancier) door access systems. There must be something odd about his prints, but it isn't visible to the naked eye.
Weird. For me, it has been working flawslessly since I got my iPhone 6s, and now two macbook pros down the line, I've had it fail maybe 5 times in total?
Note that the order of the lines in /etc/pam.d/sudo matters.
Add the "auth sufficient pam_tid.so" line below the pam_smartcard.so line as shown in the article for this to work correctly.
[+] [-] epistasis|3 years ago|reply
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.
[+] [-] buildbot|3 years ago|reply
[+] [-] vbezhenar|3 years ago|reply
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.
[+] [-] kitsunesoba|3 years ago|reply
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.
[+] [-] maxique|3 years ago|reply
[+] [-] Axsuul|3 years ago|reply
- You cannot import your existing SSH keys
- You cannot transfer SSH keys if you get a new machine
[+] [-] trhway6552|3 years ago|reply
[+] [-] kelnos|3 years ago|reply
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?
[+] [-] rendaw|3 years ago|reply
The code is fairly small so it can be an example for doing other PAM things too.
[+] [-] chatmasta|3 years ago|reply
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.
[+] [-] makeworld|3 years ago|reply
[+] [-] microtonal|3 years ago|reply
[+] [-] dna_polymerase|3 years ago|reply
[+] [-] kitsunesoba|3 years ago|reply
[+] [-] ConfuSomu|3 years ago|reply
[+] [-] ctur|3 years ago|reply
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.
[+] [-] jonhohle|3 years ago|reply
[+] [-] jph00|3 years ago|reply
[+] [-] ayewo|3 years ago|reply
Anyway, here's the version of your one-liner I used to preserve the spacing used in the rest of the file:
[+] [-] gnubison|3 years ago|reply
[+] [-] gumby|3 years ago|reply
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.
[+] [-] bobbylarrybobby|3 years ago|reply
[+] [-] inickt|3 years ago|reply
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.
[+] [-] jarym|3 years ago|reply
[+] [-] lelandfe|3 years ago|reply
[+] [-] maxique|3 years ago|reply
TIL, I wondered why every time I did this it would reset after a while. Thanks!
[+] [-] eevilspock|3 years ago|reply
[+] [-] latchkey|3 years ago|reply
[+] [-] shinzui|3 years ago|reply
[+] [-] computing|3 years ago|reply
[+] [-] loeg|3 years ago|reply
[+] [-] eevilspock|3 years ago|reply
2021.03.01: https://news.ycombinator.com/item?id=26302139
72 days ago: https://news.ycombinator.com/item?id=31750560
[+] [-] path_to_file|3 years ago|reply
[+] [-] dixie_land|3 years ago|reply
[+] [-] impoppy|3 years ago|reply
UPD: https://en.m.wikipedia.org/wiki/Linux_PAM
[+] [-] JLCarveth|3 years ago|reply
[+] [-] rez9x|3 years ago|reply
[+] [-] vonseel|3 years ago|reply
[+] [-] nathan_f77|3 years ago|reply
I use external monitors now and leave my MacBook closed in a dock, so it would be nice if I could use an external fingerprint reader that I plug in via USB. I guess the Yubikey is sort of like this, but it's probably not as secure as using a fingerprint.
[+] [-] ghoward|3 years ago|reply
Is it possible for a process to authenticate a user without root privileges, including setuid/setgid?
[+] [-] GekkePrutser|3 years ago|reply
And like others said, it doesn't persist anymore. I also edited the sshd_config to enforce public key Auth but this was getting annoying.
I use FreeBSD now which lets me use my computer the way I want to.
[+] [-] stblack|3 years ago|reply
[+] [-] Toutouxc|3 years ago|reply
Like literally 100 %, I don't think I've ever had to touch the sensor twice or wait more than half a second.
PS: My hands don't sweat much and I keep the keyboard clean and without dust.
[+] [-] duxup|3 years ago|reply
My work profile is one finger, personal profile a different, both work great.
[+] [-] hanche|3 years ago|reply
[+] [-] tgv|3 years ago|reply
[+] [-] camhart|3 years ago|reply
I have noticed if I remove my fingerprint then add it back, it's more accurate for a short time. Then over time it goes back to not working as well.
[+] [-] jeffhuys|3 years ago|reply
[+] [-] thefabsta|3 years ago|reply
[+] [-] bouncing|3 years ago|reply