OpenBSD Journal

Using Yubikey For SSH Multi-Factor Authentication

Contributed by pitrh on from the ssh! key other keys dept.

Brandon Mercer (bmercer@) writes in to shed some light recently added alternative authentication methods in SSH:

For a long while now I've been complaining that usernames and passwords aren't enough. With ssh(1) you've also got keys and other variants, however the recent addition of AuthenticationMethods in sshd(8) really is a thing of beauty! What AuthenticationMethods allows you to do is specify a list, or multiple lists of chained authentication methods that must all be successful in order to authenticate the user.

So for instance "publickey,password" would require a successful public key authentication, followed by a successful password authentication. That in itself is very useful and makes ssh authentications much stronger, but when you combine that with something like a yubikey, the strength goes way up! I've had several yubikeys for a long while and you've been able to log into your OpenBSD box with them for a while, so I set out to see how it would look to use it to authenticate ssh in the same fashion.

The setup for the yubikey is fairly straightforward. OpenBSD has the yubikey personalization tools in ports and it should also be noted that you no longer need to reboot your machine between programming your yubikey and using it :).

For this test I used the yubikey-personalization-gui tool and programmed my yubikey. By choosing Yubico OTP, and selecting the Advanced programming option you're prompted to select which slot to put your new profile in. Since I still want to use this yubikey with my other accounts that are tied to the yubikey authentication service I programmed the second slot. The folks at yubikey provide a couple buttons to generate valid modhex Public Identities, Private Identities, and Secret Keys. You can copy the private identity and secret key into /var/db/yubikey/$user.uid and /var/db/yubikey/$user.key respectively, and then write the configuration to your yubikey. Once this is done you can tell your login.conf that you'd like to allow yubikey as a valid authentication method. If you're feeling brave like I was you can put yubikey as the default and leave passwd in as a fallback. Note that yubikey being set as the default authentication method is what allows sshd to be used with your yubikey. You can test your yubikey configuration from the command line using login. You'll need to long press your yubikey for 4 seconds in order to activate the OTP in the second slot. If you've been brave and made yubikey your default auth method and you haven't configured yubikey for root you'll want to take note of the -a flag for su. If you don't have your yubikey present and want to sudo something, the -a flag works there as well.

I won't bore you to death with the setup details of creating SSH keys since it's covered well in the docs. The short summary is to ssh-keygen your key; I like to password protect mine. Copy the PUBLIC key to .ssh/authorized_keys and test that it works.

Now to put it all together. In your sshd_config add a new line with AuthenticationMethods publickey,password. You can also create other auth schemes for users without yubikeys. Now to test! ssh localhost should now display "Authentication with partial success." and be prompting you for a password. A long press on your yubikey will generate a OTP and send it, and voila!

You should be warned that if you use xlock there doesn't appear to be an easy way to fall back to passwd authentication. If you can't find your yubikey you'll need to login with username:passwd in another console and kill xlock. Have fun, and be safe out there! :)

(Comments are closed)


  1. By bmercer (24.93.234.214) on

    Just a note that I figured out how to make xlock take another form of authentication. In the password field you just type passwd:yourpassword or yubikey:<keypress> where passwd and yubikey are valid authentication methods in your login.conf.

    1. By Aaron Bieber (qbit) on http://qbit.io

      > Just a note that I figured out how to make xlock take another form of authentication. In the password field you just type passwd:yourpassword or yubikey:<keypress> where passwd and yubikey are valid authentication methods in your login.conf.

      Good find!

  2. By sthen (2001:8b0:648e:cc05:10d8:3f51:9768:c081) on

    This works nicely on a single machine, but if you're looking into using this method on a network, there's something to be aware of.

    The authentication token produced by the Yubikey is based on a sequential counter. To avoid somebody replaying an old value, you need to keep track of this counter. This is fine where you have a single machine handling authentication, but login_yubikey currently has no means of syncing the database, so there's a problem if you want to use the same Yubikey to access multiple machines on a network. (The standard method used by Yubikey's own programs is to have authentication done on a single machine, and client programs access this by using an HTTP-based protocol which avoids the need to sync).

    If you need something other than this right now, you can use a TOTP token instead (e.g. feitian c200) with login_totp (this is in the login_oath package), there is still a small window where replays can work, but it's time-limited. There is also login_totp-and-pwd which requires entering your usual password *in addition* to the one-time password. A downside to this method in some situations is that clocks must be in sync.

    1. By Anonymous Coward (83.41.41.206) on

      > The authentication token produced by the Yubikey is based on a sequential counter. To avoid somebody replaying an old value, you need to keep track of this counter. This is fine where you have a single machine handling authentication, but login_yubikey currently has no means of syncing the database, so there's a problem if you want to use the same Yubikey to access multiple machines on a network. (The standard method used by Yubikey's own programs is to have authentication done on a single machine, and client programs access this by using an HTTP-based protocol which avoids the need to sync).

      Don't understand why so many people has modded down sthen's comment. He is obviously right. Let us suppose you have a YubiKey used to access two computers. When you log into one computer both YubiKey and computer counters are increased making current OTP useless to gain access to this computer again. Second one, however, will be unaware this OTP has been used and will gladly accept it. Remember, a YubiKey is some sort of keyboard, there is no magic on how it works. Of course, once YubiKey is used to log into the second computer it will synchronise its counter with YubiKey's internal one. Until it happens any OTP used to access other systems will remain valid.

      1. By sobrado (83.41.41.206) on

        A workaround is using one YubiKey per computer. However, it will move the "key management" problem to a new level if you have too many computers. ;)

    2. By Chris (98.197.58.103) on

      in case anyone runs into this later.. like I did -
      it seems that there is a 'yubiserve' which handles both yubi
      and hotp stuffs:

      http://openports.se/security/yubiserve

      haven't tried myself yet..

  3. By ALEX (115.70.177.211) on

    Hi, are the PAM modifications for SSH still necessary with this configuration ?

    1. By phessler (phessler) on why in god's name am I wearing pants?

      > Hi, are the PAM modifications for SSH still necessary with this configuration ?

      we don't have PAM. so, yes?

  4. By Didier (194.154.205.138) on

    Would you mind posting the changes you did to your login.conf ?
    Thx a lot!

    1. By sobrado (81.9.163.26) on

      see login.conf(5)

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]