booting system... standby
This is my simple blog. My intention is to ramble about things that amuse me. One day it might develop some structure, until then...
- 21 Apr 2014 » Two Factor (2FA) SSH Authentication Using YubiKey
- 31 Mar 2014 » Pragmatic Backups
- 20 Feb 2014 » SSH Reverse Tunnel on Linux with systemd
- 07 Jan 2014 » Opt-out of Junk Snail Mail
- 30 Dec 2013 » Time Warner Cable aka RoadRunner TLS and SSL Mail Fail
- 14 Dec 2013 » Long Range Zip Musings
- 29 Sep 2013 » Using Native IPv6 via Comcast in San Francisco
- 26 Aug 2013 » Where have I been?
- 14 Jul 2013 » FSSH part 2: Tmux and Vim
- 07 Jul 2013 » Dying Gigabyte Motherboard
- 30 Jun 2013 » SSD Caching Using dm-cache Tutorial
- 20 Jun 2013 » SSH Reverse Tunnel on Mac OS X
- 17 Jun 2013 » Ubuntu 13.04 Bandwidth Shaping and Traffic Control using HTB
- 16 Jun 2013 » Leveraging Upstart for User Jobs
- 15 Jun 2013 » Remote ssh copy paste buffers using fssh
- 09 Jun 2013 » Use imapfilter to filter SPAM - part 2
- 02 Jun 2013 » Android CA Certificates
- 01 Jun 2013 » Parse eMMC Extended CSD (ECSD) Registers with Python
- 30 May 2013 » Manage LXCs with Docker
- 28 May 2013 » Ting
- 27 May 2013 » SSD let me down again
- 27 May 2013 » BitTorrent Sync
- 26 May 2013 » Use imapfilter to filter SPAM - part 1
- 13 May 2013 » GNOME Keyring Access for Python
- 12 May 2013 » Lua popen3() Implementation
- 12 May 2013 » Btrfs filesystem trips up
- 09 May 2013 » Linux SSD caching part 2
- 08 May 2013 » Epson WorkForce WF-3520 + Ubuntu 13.04
- 06 May 2013 » GNOME Keyring Daemon Breaks My GPG Encrypted Backups
- 05 May 2013 » Issue with my SSD + btrfs + discard
- 26 Apr 2013 » Issues with Ubuntu's UFW on OpenVZ VPS
- 20 Apr 2013 » Linux SSD caching
- 10 Apr 2013 » My Wi-Fi access point revisited
- 01 Jan 2013 » New job, moving cross country
- 06 Sep 2012 » Ubuntu 12.04 LTS Minimal GUI
- 05 Sep 2012 » The smoking gun
- 29 Aug 2012 » A story about a car...
- 07 Aug 2012 » Managing /etc with etckeeper
- 06 Aug 2012 » Hello World
Two Factor (2FA) SSH Authentication Using YubiKey
April 21, 2014
The Yubikey works by taking an AES-128 encrypted message and sending it Yubico's authentication server. If the AES private key is stored on Yubico's server and the contents of the encrypted message are validated (counter, serial no, etc) then a verified result is returned, else fail.
The Linux PAM module will use the result to allow access to the machine in addition to a user's regular password.
A user would use the 2FA (two factor authentication) system by sshing in to a remote machine, typing their password followed immediately by the YubiKey's encrypted message (modhex encoded). If everything checks out the user is permitted access and the rest of the session continues as normal.
At the same time, if the user elects to use a ssh private key (think automation) the login process is unaffected by the YubiKey.
These are my brief notes on my YubiKey authentication setup on Arch Linux.
- A physical YubiKey, I have the YuibKey Standard. Thinking about a Neo.
- YubiKey is configured for Yubico OTP which is the default for slot 1 (aka short press).
- The Yubikey needs to have its Yubico OTP AES key uploaded to YubiCo's authentication server.
- Test all of this Yubico's Demo Site
- YubiKey public ID, available from the demo site or by reading the first 12 characters of short press (ie run
head -c 12in the console and then press the YubiKey).
Necessary libraries and dependencies installed, for Arch users it's as simple as:
These steps were run on an Arch Linux machine and are likely slightly different for every other distro.
/etc/pam.d/system-remote-loginto match the following, note the addition of the pam_yubico.so line:
#%PAM-1.0 auth required pam_yubico.so id=1 auth include system-login account include system-login password include system-login session include system-login
~/.yubico/authorized_yubikeysfile for each user with the following format:
<username>:<yubikey id from pre-reqs>
Attempt to ssh in to the local box
ssh user@localhostand type the user's password followed by a short YubiKey press. The system should login.
- Whenever configuring PAM, verify that security isn't broken. Try typing no password, wrong password, with/without YubiKey, with/without authorized_yubikeys file, with invalid entry in authorized_yubikeys file. Also be cautious of ssh multiplexing (connection sharing) as it may skip authentication and re-use / multiplex an existing connection. This could be misleading.
If the above steps don't work, turn on debugging:
debugoption to the end of the pam_yubico.so line in
Create the debug log file:
sudo touch /var/run/pam-debug.log sudo chmod go+w /var/run/pam-debug.log
Tail the logs looking for clues while debugging:
sudo journalctl -f -l tail -f /var/run/pam-debug.log
Disable debugging by removing the debug option and removing the log file.
- Man page:
- Documentation: yubico-pam wiki
Compromising the Added Security
The security is at least as strong as the original password, the second factor could be bypassed in the following cases:
- The AES private key of the Yubikey is compromised. Could be compromised by a very sophisticated via side-channel attack or if the key was regenerated or submitted to Yubico insecurely using YubiKey Personalization app.
- An adversary installs a trusted CA on the target machine and performs a man-in-the-middle attack when the pam_yubico modules contacts Yubico.
- An adversary could modify
- If the PAM files were incorrectly modified all security could be compromised (test!!!).
- Would be locked out of remote ssh access if Yubikey's authentication web service goes down. Moot point is would also be locked out if the remote machine's Internet connection went down, but that would cause many more problems like... no ssh access period.
- Bruteforce attack is significantly harder without forcing users to memorize something obnoxious.
- Can't be keylogged and replayed on a compromised machine due to the embedded counter.
- Doesn't require the user to expose a private ssh key (where both the key and passphrase could be stolen) when logging in from someone else's insecure machine.
- Impossible to login to users on the remote machine without configuring
~/.yubico/authorized_yubikeys. This prevents the accidental creation of ssh accounts when trying to create a simple user account.
- Now very difficult to login on a cell phone, but could be worked around with a dedicated ssh private key.
- The user can't lose the YubiKey and the (hopefully) installed ssh private keys at the same time or the user will be locked out.