Yubikey-SSH

From Wikitech
Jump to: navigation, search

Configuring the YubiKey NEO for SSH authentication in the prod cluster:

Installation

On Debian / Ubuntu:

apt-get install yubikey-personalization yubico-piv-tool opensc pcscd

The yubico-piv-tool package is in the universe repository in Ubuntu 15.10 and later. If you have an earlier version, you can get it from the PPA:

add-apt-repository ppa:yubico/stable
apt-get update

On MacOS:

brew install opensc ykpers yubico-piv-tool

If you're using "El Capitan", you might run into problems with the System Integrity Mode, see this posting in the Yubico forums for a fix

On OpenSuSE:

 zypper ar -r http://download.opensuse.org/repositories/security/openSUSE_Tumbleweed/ tumbleweed-security
 zypper in yubikey-piv-manager yubikey-neo-manager yubico-piv-tool libyubikey-tools libyubikey0 opensc

Same for 13.2 and tumbleweed, but remember to configure the correct repo for your release.

Enabling CCID smartcard mode

The smartcard/CCID feature on the YubiKey NEO is disabled by default. You can change that with the following command:

ykpersonalize -m82

A message will be printed to the console, confirming the action. This enables OTP (keyboard) and CCID. If you also want to enable U2F, you can use -m86, however this causes the device to not be recognised by libccid 1.4.18 or earlier (which includes Ubuntu 14.04 - but it is possible to install and use the libccid package from 16.04 here).

Note there's also a graphical tool yubikey-neo-manager that can be used to toggle on/off CCID, OTP, and UTF with friendly little checkboxes.

Remember to remove and re-insert your YubiKey before proceeding, otherwise you will get the error "failed to connect to reader".

Securing physical access to the YubiKey

When accessing the NEO you need to enter a PIN to prevent access for someone who e.g. stole your YubiKey. If that PIN is entered incorrectly thrice, the YubiKey needs to be unlocked with a PUK. If that PUK is also entered incorrectly three time your YubiKey needs to be reset (see later section), so make sure to store these in your password manager.

In addition the NEO uses a management key: It secures access when updating the feature applets running on the YubiKey and protects you from someone backdooring your NEO.

The YubiKey uses default values for PIN, PUK and management key, so we need to change all of them:

  • First the management key (24 chars hexadecimal):
key=`dd if=/dev/random bs=1 count=24 2>/dev/null | hexdump -v -e '/1 "%02X"'`
yubico-piv-tool -a set-mgm-key -n $key
  • Now the PIN (6 digits, 123456 is the shipped default PIN):
pin=`dd if=/dev/random bs=1 count=6 2>/dev/null | hexdump -v -e '/1 "%u"'| cut -c1-6`
yubico-piv-tool -a change-pin -P 123456 -N $pin
  • Finally the PUK (8 digits, with the default 12345678)
puk=`dd if=/dev/random bs=1 count=6 2>/dev/null | hexdump -v -e '/1 "%u"'|cut -c1-8`
yubico-piv-tool -a change-puk -P 12345678 -N $puk
  • Finally don't forget to keep the content of $key, $pin and $puk in your password manager.

Key/certificate creation

First of all generate a new private key: (9a is a slot number, for others see the introduction of https://www.yubico.com/wp-content/uploads/2015/04/Yubico-PIV-Management-Tools_v1.0.pdf )

 yubico-piv-tool -k $key -s 9a -a generate -o public.pem

Generate a self-signed certificate:

 yubico-piv-tool -a verify-pin -P $pin -a selfsign-certificate -s 9a -S "/CN=SSH key/" -i public.pem -o cert.pem

Import the certificate:

 yubico-piv-tool -k $key -a import-certificate -s 9a -i cert.pem

Note: with yubico-piv-tool v1.1.1 on OpenSuSE I had to add -k using yubico-piv-tool once the management key was changed, otherwise it would not prompt for the management key and simply fail on an authentication error.

Generate an SSH pubkey

On Debian/Ubuntu:

export OPENSC=$(dpkg -L opensc-pkcs11 | grep \/opensc-pkcs11.so\$ | head -n1 )
ssh-keygen -D $OPENSC -e
on an Ubuntu older than 15.10, where you had to use the PPA, opensc is a single package, you should use
export OPENSC=$(dpkg -L opensc | grep opensc-pkcs11.so\$)
ssh-keygen -D $OPENSC -e
On MacOS X / Brew:
export OPENSC="/usr/local/Cellar/opensc/0.15.0/lib/opensc-pkcs11.so"
ssh-keygen -D $OPENSC -e

On Fedora/OpenSuSE:

export OPENSC="/usr/lib64/opensc-pkcs11.so"
ssh-keygen -D $OPENSC -e

Adding your new SSH key

For the initial testing of the SSH key you can add it in parallel to your existing key, see e.g. commit 8ad4e24e6a91af737054a70beaaf84864c967199 in operations/puppet

Accessing the key

The key is accessed via the PKCS11 interface (which OpenSSH supports):

ssh -I $OPENSC $HOST
Enter PIN for 'PIV_II (PIV Card Holder pin)':

In some cases it might be like this:

Enter passphrase for PKCS#11:

You still need to enter PIN.

This can be configured so that you don't have to type -I every time:

echo "
Host *.wmnet *.wikimedia.org
PKCS11Provider $OPENSC" >> ~/.ssh/config

You also don't need to enter the PIN all the time, since ssh-agent supports PKCS11 as well. Run

ssh-add -s $OPENSC

to enter the key to the agent. But in that case don't add the PKCS11Provider entry to your ssh config.

Unfortunately, gnome-keyring, which is the default SSH_AUTH_SOCK implementation on many Linux desktops, does not support this.[1] Neither does gpg-agent.[2] You may see an error like:

SSH_AGENT_FAILURE
Could not add card: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

So on such systems, you either need to run a separate SSH agent:

eval `ssh-agent -s`
ssh-add -s $OPENSC

Or hack the session startup so that the real OpenSSH ssh-agent is used.

On MacOSX Yosemite, you may get the error message above along with "fork: Resource temporarily unavailable" for any commands after that. This will persist until you logout or reboot, and is caused by Apple's ssh-agent spawning runaway pkcs11 helper processes endlessly. It appears that upgrading to MacOSX El Capitan solves this issue.

Note that you can identify the current SSH agent with:

sudo fuser -v $SSH_AUTH_SOCK

If you remove the YubiKey from the USB port and then plug it back in, or if you press the button for OTP/U2F the card needs to be re-added to the agent:

ssh-add -e $OPENSC
ssh-add -s $OPENSC

Getting gnome-keyring out of the way so you can use ssh-agent

Disabling gnome-keyring altogether can cause Gnome to misbehave in ugly ways. But you can disable keyring components independently.

OpenSuSE 13.2

Here's what worked on OpenSuSE 13.2 & Tumbleweed. This will probably work in other freedesktop.org-compliant desktops.

cp /etc/xdg/autostart/gnome-keyring-gpg.desktop ~/.config/autostart/
cp /etc/xdg/autostart/gnome-keyring-pkcs11.desktop ~/.config/autostart/
cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
echo Hidden=true >> ~/.config/autostart/gnome-keyring-gpg.desktop
echo Hidden=true >> ~/.config/autostart/gnome-keyring-pkcs11.desktop
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

Log out and back in, and if you still see gnome-keyring-daemon running you should not see processes related to gpg, pkcs11, or ssh.

Xubuntu 14.04 (XFCE)

XFCE has its own very special way to start ssh-agent/gpg-agent. To configure it:

xfconf-query -c xfce4-session -p /compat/LaunchGNOME -t bool -s false
xfconf-query -c xfce4-session -p /startup/ssh-agent/type -n -t string -s ssh-agent

This makes xfce4-session start both ssh-agent and gpg-agent, but gpg-agent is started without SSH support. The first command disables GNOME services; xfce4-session will not start ssh-agent unless GNOME services are disabled. Disabling GNOME services also causes xfce4-session to not start gnome-keyring-daemon, but in my case that was not a problem, since lightdm was already starting it, via libpam-gnome-keyring. In fact, before I started work on this, I had two copies of gnome-keyring-daemon running.

Since lightdm starts gnome-keyring-daemon before xfce4-session starts ssh-agent, the latter overwrites the SSH_AUTH_SOCK environment variable, and so ssh-agent is used by the ssh client without even having to disable the SSH component in gnome-keyring.

Viewing an sftp URL in the file manager still worked, and apparently still used gnome-keyring.

Detecting key remove/insert on linux

Here's a udev hack to drop a file in /tmp that you can poll to see if the key has been reinserted.

# /etc/udev/rules.d/57-yubikey-neo-status.rules
# remember to run: udevadm control --reload-rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1050", ATTR{idProduct}=="0111|0116", RUN+="/usr/local/bin/yubi_tracker"
ACTION=="remove", SUBSYSTEM=="usb", RUN+="/usr/local/bin/yubi_tracker"

Here's the shell script that works with the udev hack:

#!/bin/bash

if /usr/bin/lsusb | /usr/bin/grep '1050:011[16]' > /dev/null; then
    /bin/date +%s > /tmp/yubi_inserted
else
    /usr/bin/rm /tmp/yubi_inserted
fi

Finally, here's the chunk of sample bash code to use with the above udev hack and ssh-agent:

# load identity from yubkey if yubikey is present but identity isn't loaded
if [ -f /tmp/yubi_inserted ]; then
    if ! /usr/bin/ssh-add -l | /usr/bin/grep opensc-pkcs11 > /dev/null; then
        if /usr/bin/ssh-add -c -s $opensc_lib; then
            # mark the time of last unlock
            /usr/bin/cp /tmp/yubi_inserted /tmp/yubi_unlocked
        fi
    fi
else
    # yubikey is not unlocked, so remove timestamp
    /usr/bin/rm -f /tmp/yubi_unlocked
fi

Suggested .bashrc

export OPENSC=$(dpkg -L opensc | grep opensc-pkcs11.so\$ )
function yubiadd() {
	ssh-add -s $OPENSC
}
function yubidel() {
	ssh-add -e $OPENSC
}	
function yubireset() {
	yubidel
	yubiadd
}

Resetting your Yubikey

In case you botch something, and you want to reset your Yubikey to factory settings, you'll need to lock yourself out, and then perform a reset:
yubico-piv-tool -a verify-pin -P 4711
yubico-piv-tool -a verify-pin -P 4711
yubico-piv-tool -a verify-pin -P 4711
yubico-piv-tool -a verify-pin -P 4711
yubico-piv-tool -a change-puk -P 4711 -N 675671
yubico-piv-tool -a change-puk -P 4711 -N 675671
yubico-piv-tool -a change-puk -P 4711 -N 675671
yubico-piv-tool -a change-puk -P 4711 -N 675671
yubico-piv-tool -a reset

Notes

  1. Bug 535373. There is some confusion on this bug report about what "PKCS#11 support" is. Gnome-keyring is a PKCS#11 provider, but not a PKCS#11 consumer. So it can pretend to be a smart card, but it can't read a smart card. You can see in the relevant source file that the ADD_SMARTCARD_KEY operation is unimplemented.
  2. Note the lack of ADD_SMARTCARD_KEY in the list of supported commands around line 261 of agent/command-ssh.c in the current git master (e9c16fee2576c772de9d4fb5d53fee28e4b84202).

See Also