Contributed by pitrh on from the ssh! key other keys dept.
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)
By bmercer (24.93.234.214) on
Comments
By Aaron Bieber (qbit) on http://qbit.io
Good find!
By sthen (2001:8b0:648e:cc05:10d8:3f51:9768:c081) 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).
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.
Comments
By Anonymous Coward (83.41.41.206) on
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.
Comments
By sobrado (83.41.41.206) on
By Chris (98.197.58.103) on
it seems that there is a 'yubiserve' which handles both yubi
and hotp stuffs:
http://openports.se/security/yubiserve
haven't tried myself yet..
By ALEX (115.70.177.211) on
Comments
By phessler (phessler) on why in god's name am I wearing pants?
we don't have PAM. so, yes?
By Didier (194.154.205.138) on
Thx a lot!
Comments
By sobrado (81.9.163.26) on