pam-u2f: randomly stopped working on OSX

I got PAM working on my Mac a few days ago, but today at work I notice it’s randomly stopped working. Debug output below:

sh-3.2# su smiller
debug: pam-u2f.c:64 (parse_cfg): called.
debug: pam-u2f.c:65 (parse_cfg): flags 0 argc 1
debug: pam-u2f.c:67 (parse_cfg): argv[0]=debug
debug: pam-u2f.c:68 (parse_cfg): max_devices=0
debug: pam-u2f.c:69 (parse_cfg): debug=1
debug: pam-u2f.c:70 (parse_cfg): interactive=0
debug: pam-u2f.c:71 (parse_cfg): cue=0
debug: pam-u2f.c:72 (parse_cfg): manual=0
debug: pam-u2f.c:73 (parse_cfg): nouserok=0
debug: pam-u2f.c:74 (parse_cfg): alwaysok=0
debug: pam-u2f.c:75 (parse_cfg): authfile=(null)
debug: pam-u2f.c:76 (parse_cfg): origin=(null)
debug: pam-u2f.c:77 (parse_cfg): appid=(null)
debug: pam-u2f.c:119 (pam_sm_authenticate): Origin not specified, using "pam://Scotts-MBP-2"
debug: pam-u2f.c:130 (pam_sm_authenticate): Appid not specified, using the same value of origin (pam://Scotts-MBP-2)
debug: pam-u2f.c:140 (pam_sm_authenticate): Maximum devices number not set. Using default (24)
debug: pam-u2f.c:158 (pam_sm_authenticate): Requesting authentication for user smiller
debug: pam-u2f.c:169 (pam_sm_authenticate): Found user smiller
debug: pam-u2f.c:170 (pam_sm_authenticate): Home directory for smiller is /Users/smiller
debug: pam-u2f.c:177 (pam_sm_authenticate): Variable XDG_CONFIG_HOME is not set. Using default value ($HOME/.config/)
debug: pam-u2f.c:209 (pam_sm_authenticate): Using default authentication file /Users/smiller/.config/Yubico/u2f_keys
debug: util.c:107 (get_devices_from_authfile): Authorization line: smiller:AKyp1zw9XB7pCU03aKbSyNekjzX0Eeh1C7KY3v9eEXtR4poT7mHoioq8hp21ckzqxi4zF1Di7vXGSFw9zDlKVA,046f2691aaabc25e65e35130dbcaa42d532fa2ae1f9b6310a259143680d1376686dfb91506da83802325f82c15ec5f5799641c94f3cb63b621bcd68a33063eecb1
debug: util.c:112 (get_devices_from_authfile): Matched user: smiller
debug: util.c:130 (get_devices_from_authfile): KeyHandle for device number 1: AKyp1zw9XB7pCU03aKbSyNekjzX0Eeh1C7KY3v9eEXtR4poT7mHoioq8hp21ckzqxi4zF1Di7vXGSFw9zDlKVA
debug: util.c:157 (get_devices_from_authfile): publicKey for device number 1: 046f2691aaabc25e65e35130dbcaa42d532fa2ae1f9b6310a259143680d1376686dfb91506da83802325f82c15ec5f5799641c94f3cb63b621bcd68a33063eecb1
debug: util.c:172 (get_devices_from_authfile): Length of key number 1 is 65
debug: util.c:200 (get_devices_from_authfile): Found 1 device(s) for user smiller
debug: util.c:262 (do_authentication): Device max index is 0
debug: util.c:288 (do_authentication): Attempting authentication with device number 1
debug: util.c:310 (do_authentication): Challenge: { "keyHandle": "AKyp1zw9XB7pCU03aKbSyNekjzX0Eeh1C7KY3v9eEXtR4poT7mHoioq8hp21ckzqxi4zF1Di7vXGSFw9zDlKVA", "version": "U2F_V2", "challenge": "IEMNMAlXKY3DTyk_iru5InxI2s4Pi77rDGZg8SKVro0", "appId": "pam:\/\/Scotts-MBP-2" }
debug: util.c:328 (do_authentication): Unable to communicate to the device, authenticator error
debug: pam-u2f.c:256 (pam_sm_authenticate): do_authentication returned -2
debug: pam-u2f.c:275 (pam_sm_authenticate): done. [authentication error]

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 2
  • Comments: 22 (6 by maintainers)

Commits related to this issue

Most upvoted comments

Yep, that’s the issue. From @smiller171 's log:

debug: pam-u2f.c:76 (parse_cfg): origin=(null) debug: pam-u2f.c:77 (parse_cfg): appid=(null) debug: pam-u2f.c:119 (pam_sm_authenticate): Origin not specified, using “pam://Scotts-MBP-2” debug: pam-u2f.c:130 (pam_sm_authenticate): Appid not specified, using the same value of origin (pam://Scotts-MBP-2)

The hostname has a -2 suffix indicating the MBP probably renamed itself due to a ‘false’ .local name collision (it happens sometimes). This means it will probably fail again, next time it happens. IMO, the documentation should reflect the fact that origin and appid have to be set. Otherwise, if the hostname changes, authentication fails.

For those encountering this problem, @c00kiemon5ter 's solution worked reliably for me also. But note that it’s --set and --get with double dashes.

Hello, I’m also using mac os x, and had the same problem. It is now that I solved it that I could search the right keywords and see others having the same problem. For the sake of explanation and to make up for the searching I did, here is a description and the solution (tldr; @g5pw is right):

By default mac os x changes the hostname by doing a reverse dns lookup on the (dhcp) locally assigned ip. In order to reproduce the problem all that is needed is to setup your ~/.config/Yubicon/u2f_keys when connected to some network, test that the key works and then disconnect (or connect to another network) - now the key should not work.

The solution is to set a hostname, so that the OS does not change it when connecting or disconnecting between networks. The programmable way to do that, is by using scutil (system configuration utility) to query and set the hostname.

$ sudo scutil --set HostName my-static-hostname-or-fqdn-that-will-not-change
$ scutil --get HostName
my-static-hostname-or-fqdn-that-will-not-change

Cheers 🍺 🏖

PS: one can always reset the default behaviour by specifying an empty hostname