Updated Two-factor authentication with SSH
I've updated the section to match how yubico-pam's configuration currently works. The instructions are mostly taken from https://developers.yubico.com/yubico-pam/ and https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html , this is how I set up my machine.
The default Yubico server is contacted over https. Still, the documentation suggests using the API ID instead of id=1, but no API key, which to me seems like a semi-HMAC way of doing things. Should I change the section for general PAM setup accordingly? Would mean that users will generally have to generate the key pair.
- I've left it at id=APIID for now, just in case id=1 is insecure. It makes the two sections kind of identical, but I don't know enough about HMAC/https to decide if id=1 is OK. Please advise. Lcts (talk) 18:25, 14 April 2017 (UTC)
- For completeness sake, I added the
id=1way of connecting back in - it might be of interest for people planning to set up their own servers - but added a warning. If someone knows that the warning is unwarrented, they should feel free to remove it.
- For completeness sake, I added the
Incorrect information regarding required YubiKey version for PIV
The article mentions in two places that a YubiKey 4 or later is required for PIV support. "Starting from the fourth generation devices, the Yubikeys contain a PIV (Personal Identity Verification) application on the chip." and "A YubiKey with the PIV (Personal Identification Verification) application is required; this means you need a YubiKey 4 or later."
This is incorrect, however, as the older YubiKey NEO and NEO-n also include a PIV applet. This can be confirmed here https://www.yubico.com/products/yubikey-hardware/compare-yubikey-4-neo/, https://support.yubico.com/support/solutions/articles/15000006494-yubikey-neo and https://support.yubico.com/support/solutions/articles/15000006495-yubikey-neo-n. I've also had it confirmed by their tech support. In addition, other sites such as the Debian wiki also mention that both NEO models can be used https://wiki.debian.org/DebianSingleSignOn#Use_with_a_Yubikey_in_PIV_mode
The only limitation on the NEO keys is that they are limited to RSA only, whereas the 4 series also support ECC.
Incorrect information regarding required full disk encryption
The article says: As of December 2019 `sd-encrypt` enabled boot is not supported by yubikey-full-disk-encryption.
Improve udev example rule
The example udev rule only covered YubiKey 4 and one model ID. I've expanded that rule to include all model IDs taken from this link.
Move content to U2F article
There now is also a page Universal 2nd Factor. Content that doesn't depend on the type of key but works for all U2F keys should be moved there to avoid duplication and chaos and also help people with other kinds of U2F devices. That seems to be the case for section 4 and 6.3 and maybe also 5.3 and 6.1? The general article should therefore be linked in a "related box". Do you agree? -- Nudin (talk) 12:06, 17 June 2020 (UTC)
Apologies for not bringing this up before making changes, as I should have. I didn't familiarize myself with the contributing guidelines and just started chopping. I'm doing this because I recently got a new yubikey, and there were several things about this article which tripped me up trying to understand it. I'm hoping to make it easier for the next person.
What's been done
I've largely rewritten the introduction and section on One-time-passwords with the following goals:
- Start with a high-level overview of the topic, and then go into progressively greater detail. (Start with an overview of the yubikey's capabilities, then cover its inputs and outputs, then go into detail on each specific mode.)
- Consolidate related information into relevant sections. It was scattered, which made it difficult to understand which features and limitations were related to which modes. (For example, the "two slots" section was in the introduction, when the two slots are exclusively for the OTP mode. They have nothing to do with U2F or RSA keys.)
- Reduce wordiness - There were several opportunities to improve succinctness.
- Reduce repetition - There were a few sentences repeated nearly word-for-word in different places.
- Improve Language and style.
- Add OTP instructions for static passwords
- Add OTP instructions for OATH
- Improve challenge-response instructions. Update the examples to use ykman instead of ykpersonalize, as that's what the other examples use and its syntax is much more readable.
- Expand the U2F section
- Expand the OpenPGP section (Just a few sentences, no need to rewrite the GPG smartcard article here.)
- Move SSH instructions to the 'Tips and tricks' section with the other examples.
- Extract "How to use a yubikey with X" to its own section
- Improve the "Yubikey and" section
- When explaining how to use a yubikey with some software or service, start with which modes & features can be used to accomplish it.
- In general, provide links to instructions rather than the instructions themselves.
- The 'Two-factor authentication with SSH' section is really 'Yubikey and PAM'. It's not specific to SSH, the same instructions can be used for anything which uses PAM for authentication. There's also the possibility to use challenge-response instead of Yubico OTP, removing the requirement for an external server, which should be documented.
What's left to do
- Add some sources to the PIV section.
- Improve some of the more hacky troubleshooting and maintenance instructions
- Regarding the "Yubikey and" section, I think it is not maintainable to repeat step-by-step instructions for every possible use of a yubikey here. Instead, we should offer an overview of the possibilities (along with their advantages and disadvantages), along with links to instructions where they exist elsewhere. Only provide step-by-step instructions when they don't exist anywhere else, and even then we should consider whether some other page is the right place (in other words, is it specific to the Yubikey?)
Removal of accuracy flag
The page is currently flagged for accuracy for the following reason:
The article lacks sources, is interspersed with TODOs and probably out of date.
This was added in October of 2018, nearly 2 years ago. Since then most of the article has been rewritten and updated, and there are no longer any TODOs left. There is always room for improvement, and some of the troubleshooting and maintenance instructions need work, but overall I don't believe the entire article needs an accuracy flag anymore.
I'm going to leave this discussion up on the talk page for a week or two, and then if there are no objections I'll remove the flag.