Note the similar previously started article for Fedora Linux 34 that is in the stalled category, Card #17.

That article had issues with the use of Yubico images which were not resolved so the article was not published.

Hey there! I'm open to write this article. I've already started work on this for my own blog (almost done writing the article there) and I'm implementing it in my company. I've already setup and played around using YubiKeys for PAM (Login/Sudo), 2FA, FIDO2 and PIV (SSH). I'm experienced in using modern yubico manager interfaces in CLI and GUI (via fedora packages).

I have no experience in decrypting LUKS partitions with it yet. But then again I see that particular topic as an optional one as IMO LUKS unlocking should be done by binding to an onboard TPM2. I don't know about external drives though

I only have experience with Yubikey 5(C) NFC and it's features. I don't use other smart cards.

The topic on website authentication via OTP or FIDO2 is a rather broad one and I fear derailing of the core of this article. Bitwarden in particular only supports FIDO with the Premium Licence (to be fair: it only is 10$ a year).

With the already present article I don't think it will take much time. Do you think if screenshots include the the Yubico logo it is sufficient to pixel it out? I can't access the preview of the article on wordpress to see the current state of it (at least without logging in)

@w4tsn: I'll try adding you as a secondary author on that article that is stalled.

Note: in this effort an update to the rather outdated / incomplete fedora docs are in order: https://fedoraproject.org/wiki/Using_Yubikeys_with_Fedora

Do you think if screenshots include the the Yubico logo it is sufficient to pixel it out?

The problem with the previous article was that the inline image was lifted wholesale from a website that explicitly stated that their images were under copyright and could not be duplicated for use on other sites.

I think a background photo of their logo would be fine under the "fair use clause".

The preamble to Section 107 lists six illustrative[6] types of uses that may be analyzed under the doctrine: criticism, comment, news reporting, teaching, scholarship, and research. These uses are not, however, presumptively fair.[7] Instead, the courts are directed to examine the use according to four statutory factors: “(1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes; (2) the nature of the copyrighted work; (3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and (4) the effect of the use upon the potential market for or value of the copyrighted work.”

I started work on the article based on what is already there and decided to re-write most of it. Mainly because since Fedora 34 the pam_yubikey module has evolved and many thing in PAM configuration are A LOT easier today (especially regarding SELinux etc.).

I'm not yet sure about the scope of the article. I think that A) YubiKey configuration, B) PAM usage (for login, gdm, sudo) and C) SSH makes sense. Other usages include but are not limited to PGP signing, WebAuthn, Substitute to Google Authenticator and OpenSSL PKI stuff and I guess we could split that up into follow up articles? Maybe WebAuthn is actually an interesting use-case, as you can register the key at many web sites today and use the press of a button instead of OTP.

I decided to replace the OTP explain image with a hand drawn version with slight modifications to the original. WDYT? Not sure if the OTP explain section is really necessary though and I'm tending to remove it.

@w4tsn: All your ideas sound excellent to me. I'm really looking forward to seeing what you come up with! 🙂

My only recommendation is to state up-front in such articles that these security measures should not be considered 100% (and if you can provide examples of when and how they might be ineffective, all the better). I really like the way you explained that encryption of at-rest data does not prevent hacking of the user's PC at runtime in your last article.

I think the article is ready for review :)

WDYT?

Is it correct that this article should be dual-credited to both Peter Veres and yourself? (I don't know how much of the original article is still existent.)

Yes, I think that is totally fair

@drmckay: Are you OK with your name being accredited to this revised form of your original article?

@drmckay: Are you OK with your name being accredited to this revised form of your original article?

Hi, yes, it's totally fine 👍

Excellent. Thanks Peter!

There are a few articles ahead of this one so it will probably be a few weeks before it goes out. In the meanwhile, you (all) are still free to make revisions.

@rlengland I think this post has an image now so I guess the tag can be removed?

Also: I marked two paragraphs with [Editorial note:...] where I think some custom styling would be appropriate. I don't know how to set a "warning-style" block

To make a warning-style block, I sometimes set the background to red for the paragraph. There should be an option to do that in the right-hand sidebar when editing the paragraph.

See https://fedoramagazine.org/hibernation-in-fedora-36-workstation/ for and example of how I've styled a warning before.

@w4tsn Can you add a line or two about how you enter the PIV, FIDO2, etc modes in the GUI YubiKey Manager? I am guessing that it is by selecting "Applications" or "Interfaces" but I think it would be helpful to make that clear.

Also, there are several acronyms like PIV and OTOP etc. I've added some explanation for a couple of them but it might be useful for the novice if you could work in a few more.

Thanks for all your work on this article.

@w4tsn Can you add a line or two about how you enter the PIV, FIDO2, etc modes in the GUI YubiKey Manager? I am guessing that it is by selecting "Applications" or "Interfaces" but I think it would be helpful to make that clear.

Done

Also, there are several acronyms like PIV and OTOP etc. I've added some explanation for a couple of them but it might be useful for the novice if you could work in a few more.

I worked in more and think I got all of them. I could even add some more explanation of the single standards, etc. but that would get out of hand pretty quickly I think because of how much is going on there already :D (I did add some more hyperlinks to explanations however)

Thanks for all your work on this article.

My pleasure!

Your changes look good! The article is scheduled for 3 March (this Friday).

Thanks again.

A comment on the article noted the important fact that caution is advised when handling the OTP Slot 1. We should put a warning under the "Configure YubiKey -> OTP" section with the following content:

Slot 1 is special as it contains a factory credential already uploaded to YubiCloud. Deleting and recreating a Yubico OTP secret and uploading it to YubiCloud yourself will put a special mark on it which has consequences: service providers might not trust such a key and Yubico might delete those secrets at anytime for practically any reason.

No problem. Done.

As I updated the YubiKey Quick-Docs and revisited the OpenSSH section I noticed an error on my side which also made it into the article: the OpenSSL certificate generation is only necessary for YubiKeys that do not support FIDO2, so in the article this step is either unnecessary or does not work on older keys as the ssh-keygen command has to look a bit different for older keys.

So you would like me to delete the paragraph that starts "Create a self-signed certificate for that key. ..." and the following command-line example?

I would move everything from "Your YubiKey can store OpenSSH private keys in the PIV module..." to right before "...Use OpenSSH ssh-keygen to generate..." into a sub section "YubiKeys without FIDO2 support", since FIDO2 should be the standard as it's much easier to use. The section then also needs a bit more content, as handling is a bit different:

Generate a public key from the X.509 certificate stored on the YubiKey.

[…]$ ssh-keygen -D /usr/lib/libykcs11.so -e

Login to systems with this public key:

[…]$ ssh -I /usr/lib/libykcs11.so user@remote.example.org

Then add the following as new introduction of the section:

"Some newer YubiKeys support FIDO2. If you have one of those and are running a recent version of Fedora Linux with at least OpenSSH 8.2+ it's very simple to maintain your SSH keys with the YubiKey."

I'd also rename the heading "OpenSSH with PIV and FIDO2" to "OpenSSH with FIDO2 or PKCS#11".

Please also change "If the key is generated with a touch requirement, only omit the verify-required option." from the last paragraph to "If you did not set a FIDO2 pin on the key omit the verify-required flag."

I've attempted the changes you've requested. Please review them and let me know if I missed anything. I also added a tag at the bottom of the article noting that it has been revised.

LGTM! Thank you

Argh. I missed a pre-requisit step for this last change request:

Instead of "The OpenSSH agent and client support YubiKey without further changes." it has to be:

The OpenSSH agent and client support YubiKey FIDO2 without further changes. For older keys without FIDO2 you need the PKCS#11 extension which is shipped in the official repositories:

sudo dnf install -y yubico-piv-tool-devel

No problem. Updated.