Millstream Computing

Subscribe to the RSS feed by copy/paste the link below

Yubikey

Posted by Admin on 26. August, 2019

Today I got my Yubikey and this is how I set up my Fedora boxen to use it with sudo and disable password access for sudo.

Note that this is for Fedora 27 and Fedora 29. YMMV.

First verfy your key is genuine by going to https://www.yubico.com/genuine/ and follow the instructions.

My Yubikey only supports two modes, because I am a cheapskate:

$ ykman info Device type: Security Key NFC Serial number: Not set or unreadable Firmware version: 5.1.2 Form factor: Keychain (USB-A) Enabled USB interfaces: FIDO NFC interface is enabled.

Applications USB NFC OTP Not available Not available FIDO U2F Enabled Enabled OpenPGP Not available Not available PIV Not available Not available OATH Not available Not available FIDO2 Enabled Enabled

So u2f is what I'll use here. First open a terminal and become root. Yea I know the dangers about this but during this process you may lose sudo access and then you'll be stuck and unlikely to become root. depending on how your system is configured. You mostly wont need to use it, it's just a backup. Use another terminal as a regular user with sudo access for most of the commands here.

sudo install *yubi*

sudo dnf install pamu2fcfg

pamu2fcfg -u mikee > yubikeys

sudo mv yubikeys /etc/secure/

Note: It seems that you can't copy keys from one machine to another. I tried.

Get https://github.com/Yubico/libu2f-host/blob/master/70-u2f.rules

and install it into /etc/udev/rules.d

I had to edit theYubikey lines so they look like:

# Yubico YubiKey #KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0113|0114|0115|0116|0120|0200|0402|0403|0406|0407|0410", TAG+="uaccess" #, GROUP="plugdev", MODE="0660"

Note that there are no line breaks in the ATTRS{... line. I seems that in later Fedora distro's, GROUP and MODE are not needed as this is taken care of with the TAG and ACL. See http://www.example.comhttps://bugzilla.redhat.com/show_bug.cgi?id=1270102 for some info on this. Documantation is sparce apparently.

Then reload the udev rules,as root, with:

udevadm control --reload

sudo vi /etc/pam.d/sudo

and edit it to look like;

#%PAM-1.0 auth required pam_u2f.so cue authfile=/etc/security/yubikeys #auth include system-auth account include system-auth password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so session include system-auth

This disables passwords for sudo and you can ONLY sudo with the Yubikey. So make sure you can su with a root password before you do this because if you make a mistake you will be locked out and unable to make any more changes to the file. You will then have reboot into single user mode to get root access and fix your mistake.

To limit the time, in minutes, that sudo lasts do : visudo and add:

Defaults timestamp_timeout=1

in the the block of defaults, although I don't think it really matters where it is in the file. Use timestamp_timeout=0 if you are really paranoid.

For requiring the key for su, my /etc/pam.d/su file looks like:

#%PAM-1.0 auth sufficient pam_rootok.so # Uncomment the following line to implicitly trust users in the "wheel" group. #auth sufficient pam_wheel.so trust use_uid # Uncomment the following line to require a user to be in the "wheel" group. #auth required pam_wheel.so use_uid # The following line requires a U2F key to be used. auth required pam_u2f.so cue authfile=/etc/security/yubikeys # Comment the following line to disable password login #auth substack system-auth auth include postlogin account sufficient pam_succeed_if.so uid = 0 use_uid quiet account include system-auth password include system-auth session include system-auth session include postlogin session optional pam_xauth.so

Of course this means you will not be able to do any system admin tasks if you ssh in. Arguably using sudo is regarded as marginally safer than su'ing to root user so apply whichever suits your workflow.

You will also need to add a line to /etc/security/yubikeys for the root user for this to work. Including your backup key too.

Also learn to use vi so you don't have to use that nano (spit) shit. Linux and unix system ALWAYS have vi installed. Learn it.

Create the plugdev group and add users to it using the tool of your choice. Now exit out of root on that backup terminal just in case you type somehing stupid in there and trash your system. I have a different coloured (red) prompt for the root user to remind me to be careful.

Now I need to get the KDE and tty logins to work the same. Yay, a secure(ish) computer. Now mod the pam rules for other services you want to restrict.

Also get two, or more, keys.

Using your Yubikey for SSH

Since version OpenSSH 8.2 you can use your Yubikey for authorise ssh sessions. You need to generate a ecdsa-sk keys and add them to .ssh/authorized_keys file on the remote.

ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk

If you have multiple keys (and you should) generate a PK for each and name the file approriately.

Edit your .ssh/config to use these keys when ssh'ing into the remote. Remove the public keys you were previously using from the remote's .ssh/authorized_keys.

To further lockdown the remote add:

PubkeyAcceptedKeyTypes sk-ecdsa-sha2-nistp256[at]openssh[dot]com,sk-ssh-ed25519[at]openssh[dot]com

to /etc/sshd/config

Don't forget to firt login to the remote using your old method and stay logged in there until you have confirmed that the new method works from another terminal session. If you do not confirm this and you log out you may lose access to the remote for ever.

Refs:

https://cryptsus.com/blog/how-to-configure-openssh-with-yubikey-security-keys-u2f-otp-authentication-ed25519-sk-ecdsa-sk-on-ubuntu-18.04.html

Yubikey

Using your Yubikey for SSH

Comments