Pilot service for Yubikey two-factor authentication

November 10, 2015

A Yubikey Cosign authentication ‘factor’

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 3:34 pm
Tags: , , ,

Bearing the above specification in mind, we could now write a Cosign ‘factor’/authenticator which targets Yubikeys: we’d just need to feed it with the username, as well as the one-time-password produced by the Yubikey; have it perform the authentication – by slaving that off to a back-end authentication server; and then have it produce outputs as specified by the protocol.

However: we already have a Yubico PAM module which handles the details of the back-end authentication of the Yubikey one-time-password, and it turns out that a ‘universal Cosign PAM factor adaptor’ is available – see the relevant postings on the cosign-discuss mailing list. So we can use that instead.

The relevant C code file is now part of the Cosign download tarball, but it’s not autobuilt as part of the ./configure; make process. However:

  1. find it (as file pam_factor.c in the cgi/factors directory of the distribution);
  2. build it as follows:
    gcc -lpam -o pam_factor pam_factor.c
    
  3. copy the resulting binary factor to some suitable location, e.g., /usr/lib/cosign/factors; and
  4. edit /etc/cosign.conf to add the factor.

In the /etc/cosign.conf configuration file, all this finally takes the form:

factor /usr/lib/cosign/factors/otp login passcode

where otp is a symlink to the universal Cosign PAM factor adaptor pam_factor, and a new ‘otp‘ PAM service using the Yubico PAM module has also been declared.

Note: the name of the factor is significant, and is more than just, for example, self-documentation! Recall that the factor must, on successful authentication:

  • write the factor name to stdout; and
  • exit with 0.

The universal Cosign PAM ‘factor adaptor’ is coded to emit a factor name which corresponds to its basename – i.e. in our case, it will emit the factor name of ‘otp‘ on successful authentication. So the literal factor name ‘otp‘ is what the rest of the corresponding Cosign configuration client-side must be set up to expect.

In addition: the name of the corresponding local PAM service must match that of the factor: the factor is coded to call out to the local PAM service which corresponds to its basename.

Finally, however: why call this factor ‘otp‘ rather than, say, the more mnemonic name ‘yubikey‘? After all, both of the above-mentioned pieces of configuration could be fixed up accordingly. Well, as well as ‘leaking’ less internal configuration information, it turns out that the factor ‘otp‘ is already explicitly supported by the supporting HTML and Javascript distributed in the Cosign tarball. So ‘otp‘ is just better and easier all round.

December 12, 2014

Towards two-factor Yubikey authentication with OpenSSH

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 5:21 pm
Tags: , ,

Our overall strategy for a test OpenSSH service using two-factor authentication via Yubikey is now clear:

  1. Integrate Yubico’s PAM module into the PAM stack used for our ssh service.
  2. Configure that PAM module to authenticate against the Yubicloud service.
  3. Organize our configuration so that only those users who are registered (somehow …) for Yubikey use are required to submit a Yubikey OTP.

Since we definitely don’t want to mandate Yubikey use for every user, how can we arrange this final (very necessary) requirement? It turns out that the (previously unknown to me) pam_succeed_if module can help. That allows an ‘if test’ which tests for group and/or netgroup membership to be arranged in the PAM stack. So, what we need to do is to instantiate a suitable group (or netgroup) which contains the UUNs of all those users registered for Yubikey use.

To keep things as simple as possible for testing, we’ve chosen to set that up for now as a group, called yubikeyusers. (We’ll almost certainly use a netgroup in any final live implementation.) The relevant lines of the resulting PAM configuration are as follows:

 
auth	[success=ignore ignore=ignore default=1]	/lib64/security/pam_succeed_if.so	debug user ingroup yubikeyusers 
auth	required	/lib64/security/pam_yubico.so	id=<secret> key=<secret> authfile=/etc/yubikey_mappings debug 

Some notes about the parameters to the Yubico PAM module pam_yubico.so:

  1. We’ve got debugging turned on for this module so that we can get detailed output from the authentication process. For that to work as expected, it’s necessary to ‘touch’ the nominated log file in advance:
    touch /var/run/pam-debug.log
    chmod go+w /var/run/pam-debug.log
    
  2. The <secret> strings are our private keys for use with the Yubicloud service. Such keys are freely available from Yubico.
  3. The file /etc/yubikey_mappings contains the mappings of Yubikey public ids to local UUNs. That is: it formally associates actual Yubikeys with actual users. (An individual user can be associated with more than one Yubikey, by the way.) In a final live system, we’d expect to integrate that same information into our LDAP directory: Yubico’s PAM module can read from that.

Yubikey authentication

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 5:04 pm
Tags: ,

The Yubikey authentication standard is proprietary – but it is completely open. So it would be perfectly possible for anybody to implement their own authenticator from the ground up.

However: why bother? Yubico makes a lot of source code available at its github site including:

  1. Source code for an authentication server.
  2. Source code for a PAM module which interfaces with the authentication server.

In addition, Yubico provides a free ‘cloud-based’ authentication service, ‘Yubicloud’.

So in fact experimenting with Yubikey authentication is easy: for a start, anyway, we can just use the ‘Yubicloud’ service.

Theme: Rubric.