Documentation is unclear on applicability

[candlerb]

The documentation is very unclear as to what use cases this module supports.

I am guessing the pam U2F module only works for token authentication on the local host - that is, it talks directly to the U2F token using the local USB controller. Is that true?

But could you use this to authenticate an SSH session to a remote host? If so, how does it work?

Presumably at the server side the PAM module could send challenge/response messages to the client, but how would the ssh client talk to the U2F device at the client side? Is the user required to paste challenge/response messages into some companion tool?

The page at https://www.yubico.com/applications/computer-login/linux/ makes this even less clear. There it talks about using one time passwords (that's fine - I am happy with how the original Yubikey OTP works), and yet this page has a link to the PAM U2F module!

[a-dma]

I am guessing the pam U2F module only works for token authentication on the local host - that is, it talks directly to the U2F token using the local USB controller. Is that true?

That would be correct.

But could you use this to authenticate an SSH session to a remote host? If so, how does it work?

Presumably at the server side the PAM module could send challenge/response messages to the client, but how would the ssh client talk to the U2F device at the client side? Is the user required to paste challenge/response messages into some companion tool?

To have native support would require modifying both the ssh client and server. There are a few patches around and some people have had some success with it. Have a look at #12.

The page at https://www.yubico.com/applications/computer-login/linux/ makes this even less clear. There it talks about using one time passwords (that's fine - I am happy with how the original Yubikey OTP works), and yet this page has a link to the PAM U2F module!

I agree that this page is not very clear. I'll see if I can get it to improve. Thanks for the pointer.

[candlerb]

That's great, thanks. I hadn't seen the "manual mode" pam option, I might have a play with it.

In such a deployment, there is also a question around good enrolment practice: whether you should enrol separately for each host, or whether it would be reasonable to set a fixed origin of (say) "pam://mycompany.com" or even just "pam://ssh" and copy the same keyhandle/userkey onto each host.

Then it becomes more like regular ssh pubkey authentication, and you can just copy one keyhandle/userkey around all machines sharing the same origin. This is clearly beneficial if you are doing bulk administration with something like ansible or puppet - but are there any significant weaknesses in this approach?

[a-dma]

The main difference would be that with regular pubkey ssh doesn't care where credentials are stored, so the user could have the same private key imported onto several YubiKeys (e.g., one at the office and one at home) and it would still work. Keyhandles however are device specific and unique, so you would have to enroll multiple devices.

[candlerb]

Sorry, maybe I wasn't clear. I am talking about holding a single U2F device but using it to log into multiple hosts over ssh.

The way U2F is designed, you are supposed to have a different origin for each server you are talking to, which means having to enrol the same device separately into each server. This was part of Google's design for privacy reasons, so that two colluding servers couldn't determine that the same user was connecting to them.

But this is not helpful for ssh. Standard ssh procedure is to create a single public/private key pair, not a separate key pair for each host you connect to.

Using U2F in the same way means you would configure all hosts in the same administrative group with the same origin; then you could upload the same keyhandle/userkey to all the hosts. In the limit, every host in the world could be configured with the same origin e.g. pam://ssh

Would that be a bad thing? If so, why?

[a-dma]

Ah sorry, I got you now.

The main advantage, that I can think of, with having different origins for each server would be protection in case you copied the "credential" file to the wrong machine thus granting access to someone who shouldn't. Even if the KeyHandle is valid the origin won't match.

However, as you say the disadvantage would be having much more friction having to have multiple enrollment procedures.

The two solutions are just flip sides of the same coin, but I don't think there is anything inherently wrong with either one.

[candlerb]

FYI, I got this to work. Here are the details:

• Client side (OSX): brew install pam-u2f
• Tested the client side by registering and authenticating to demo.yubico.com. This all works fine.
• Client side: pamu2fcfg -opam://ssh -ipam://ssh -ubrian and note the output.
• Server side (Ubuntu 14.04): install libu2f-server 1.0.1, libu2f-host 1.1.0, pam-u2f 1.0.4 from source
• Server side:

/etc/pam.d/sshd

...
# Standard Un*x authentication.
auth sufficient pam_u2f.so debug manual origin=pam://ssh
@include common-auth
...

/etc/ssh/sshd_config

ChallengeResponseAuthentication yes
UsePAM yes

~/.config/Yubico/u2f_keys: paste in the key line from pamu2fcfg

Then when you connect, you get a challenge from the server:

$ ssh <hostname>
Now please copy-paste the below challenge(s) to 'u2f-host -aauthenticate -o pam://ssh'
{ "keyHandle": "8ERjAazI1ItnebpJ2M-7POwq3P6tQMY_KoEo42GcWzi3oiI8hj12HDl99hihgRZs3wb6K5qv7YcfUyLJeKzPvQ", "version": "U2F_V2", "challenge": "FCBgRNVrZldM--cDSO5B6MPGdcg3HqmnncoAbcGRLcM", "appId": "pam:\/\/ssh" }
Now, please enter the response(s) below, one per line.
[0]:

Do what it says:

$ u2f-host -aauthenticate -o pam://ssh
<paste in JSON challenge>
^D

Press the presence button, paste the response back into the ssh window, and hey presto!

NOTE: u2f-host was initially giving

error (-6): authenticator error

without even waiting for presence. It turns out that you must give pamu2fcfg both the origin and appid; if you give it just the origin then the appid is not what you expect. (#34)

[candlerb]

Actually, that PAM configuration isn't right. We should require the user to enter their Unix password first, then only if it's correct do the U2F challenge (as a second-factor authentication).

Something like this (NOTE: I am not a PAM expert but this seems to work)

# Standard Un*x authentication.
@include common-auth
auth    required    pam_u2f.so debug manual origin=pam://ssh

The way I had it before, you got the U2F challenge straight away. This had lots of weaknesses, e.g. simply by connecting to the ssh port you could probe for valid account names and learn authorized key handles.