Integrating FoxT BoKS ServerControl with Yubikey (MFA) authentication

2015-11-17 10:03:00

As promised, I’ve put some time into integrating the Yubikey Neo that I was gifted with Fox Technologies BoKS.  For those who are not familiar with BoKS, here’s a summary I once wrote. I’ve always enjoyed working with BoKS and I do feel that it’s a good solution to the RBAC-problems we may have with Linux and Windows servers. So when I was gifted a Yubikey last week, I couldn’t resist trying to get it to work with BoKS.

My first order of business was to set up a local, private Yubikey validation infrastructure. This was quickly followed by using an LDAP server to host both user account data and Yubikey bindings (like so). And now follows the integration with BoKS!


Yubikey and BoKS: it takes a little work

The way I see it, there’s at least three possible integration solutions that us “mere mortals” may achieve. There are definitely other ways, but they require access to the BoKS sources which we won’t get (like building a custom authenticator method that uses YKCLIENT).

  1. Adjust your software to use both Yubikey and then PAM to use BoKS.
  2. Adjust your software to use PGP/SSH keys stored on Yubikey.
  3. Adjust your software to authenticate against Kerberos, which in turn uses Yubikey OTP. BoKS allows Kerberos authentication by default.

Putting this into a perspective most of us feel comfortable with, SSH, this would lead to:

  1. Run a second SSH daemon next to the BoKS-provided SSH. This second daemon will only allow Yubikey+password MFA logins and is only accessible to a select group of people. This requires the definition of a custom access method and some PAM customizations.
  2. A solution like this, with PGP/SSH keys.
  3. Using BoKS-sshd, together with the Kerberos authentication method defined by BoKS

In my testing environment I’ve gotten solution #1 to work reliably. The next few paragraphs will describe my methods.



The following assumes that you already have:

All the changes described will need to be made on all your BoKS systems. The clients running the special SSH daemon with Yubikey support will need the PAM files as well as all the updates to the BoKS configuration files. The master and replicas will technically not need the changes you make to the SSH daemon and the PAM files, unless they will also be running the daemon. Of course, once you've gotten it all to run correctly, you'd be best off to simply incorporate all these changes into your custom BoKS installation package!


Let’s build a second daemon

BoKS provides it’s own fork of the OpenSSH daemon and for good reason! They expanded upon its functionality greatly, by allowing much greater control over access and fine-grained logging. With BoKS you can easily allow someone SCP access, without allowing shell access for example. One thing FoxT did do though, is hard-disable PAM for this custom daemon. And that makes it hard to use the pam_yubico module. So what we’ll do instead, is fire up another vanilla OpenSSH daemon with custom settings.

Downside to this approach is that you lose all fine-grained control that BoKS usually provides over SSH. Upside is that you’re getting a cheap MFA solution :) Use-cases would include your high-privileged system administrators using this daemon for access (as they usually get full SSH* rights through BoKS anyway), or employees who use SSH to specifically access a command-line based application which requires MFA.

The following commands will set up the required configuration files. This list assumes that BoKS is enabled (“sysreplace replace”), because otherwise the placement of the PAM files would be slightly different.

I’ve edited /etc/ssh/yubikey-sshd_config, to simply adjust the port number from “22” to “2222”. Pick a port that’s good for you. At this point, if you start “/usr/sbin/yubikey-sshd -f /etc/ssh/yubikey-sshd_config” you should have a perfectly normal SSH with Yubikey authentication running on port 2222.

You can ensure that only Yubikey users can use this SSH access by adding “AllowGroups yubikey” to the configuration file (and then adding said Posix group to the relevant users). This ensures that access doesn’t get blown open if BoKS is temporarily disabled.

Finally, we need to adjust the PAM configuration so yubikey-sshd starts using BoKS. I’ve changed the /etc/opt/boksm/pam.d/yubikey-sshd file to read as follows:

auth      required
auth      required mode=client ldap_uri=ldap:/// ldapdn= user_attr=uid yubi_attr=yubiKeyId id= key= url=http:///wsapi/2.0/verify?id=%d&otp=%s
auth      required
account   required
account   required
password  required
# close should be the first session rule
session   required close
session   required
session   required
# open should only be followed by sessions to be executed in the user context
session   required open env_params
session   optional force revoke


Caveat: public key authentication

Unless you are running OpenSSH 6.x as a daemon (which is NOT included with RHEL6 / CentOS 6), then you must disable public key authentication in /etc/ssh/yubikey-sshd_config. Otherwise, the pubkey authentication will take precedent and the Yubikey will be completely bypassed.

So, edit yubikey-sshd_config to include:


Reconfiguring BoKS

The file /etc/opt/boksm/sysreplace.conf determines which configuration files get affected in which ways when BoKS security is either activated or deactivated. Change the “pamdir” line by appending “yubikey-sshd”:

file pamdir relinkdir,copyfiles,softlinkfiles /etc/pam.d $BOKS_etc/pam.d vsftpd remote login passwd rexec rlogin rsh su gdm kde kdm xdm swrole gdm-password yubikey-sshd

The file /etc/opt/boksm/bokspam.conf ties PAM identifiers into BoKS access methods. Whenever PAM sends something to, this file will help in figuring out what BoKS action the user is trying to perform. At the bottom of this file I have added the following line:

yubikey-sshd   YUBIKEY-SSHD:${RUSER}@${RHOST}->${HOST}, login, login_info, log_logout, timeout

The file /etc/opt/boksm/method.conf defines many important aspects of BoKS, including authentication and access “methods”. The elements defined in this file will later appear in “access routes” (BoKS-lingo for rules). At the bottom of this file I have added, which is a modification of the existing SSH_SH method:

METHOD YUBIKEY-SSHD:  user@host->host,    -prompt, timeout, login, noroute, @-noroute, usrqual, uexist, add_fromuser

By now it’s a good idea to restart your adjusted SSH daemon and BoKS. Check the various log files (/var/log/messages, /var/opt/boksm/boks_errlog) for obvious problems.


Assigning access

My user account BoKS.MGR:thomas has userclass (BoKS-speak for “role”) “BoksAdmin”. I’ve made two changes to my account (which assumes that group “yubikey” already exists):

This leaves me as follows:

[root@master ~]# lsbks -aTl *:thomas
Username:                     BOKS.MGR:thomas
User ID:                      501
User Classes:                 BoksAdmin
Group ID:                     501
Secondary group ID's:         505 (ALL:yubikey)
Assigned authenticator(s):    ssh_pk
Assigned Access Routes via User Classes
BoksAdmin                     login:*->BOKS.MGR 00:00-00:00, 1234567
                              su:*->root@BOKS.MGR 00:00-00:00, 1234567
                              yubikey-sshd:ANY/PRIVATENET->BOKS.MGR 00:00-00:00, 1234567
                              ssh*:ANY/PRIVATENET->BOKS.MGR 00:00-00:00, 1234567


Proof: Pam_yubico works with pam_BoKS

The screenshot below shows two failed login attempts by user Sarah, who does have a Yubikey but who lacks the Posix group “yubikey”. Below is a successful login by user Thomas who has both a Yubikey and the required group.

yubikey BoKS ssh login failure

The screenshot below shows a successful login by myself, with the resulting BoKS audit log entry.

yubikey ssh BoKS login success tags: , , ,

View or add comments (curr. 0)