New to Yubikey. I have been using KeepassXC for ages and am now trying to incorporate a Yubikey for challenge response. The Yubikey shows up in sys-usb after following this method: https://doc.qubes-os.org/en/latest/user/security-in-qubes/ctap-proxy.html
This led me to believe, that the vms I had set to use ctap would recognize the Yubikey. But in my dedicated KeepassXC vm, when I follow the procedure to make a new datafile and successfully reach the Challenge-Response box, I get a ‘No hardware keys detected’ message. Clicking on the ‘Refresh hardware keys’ box does nothing. Was I wrong to use the ctap process link above? There are three vms, which I would like to have the Yubikey available to. Would I need to for instance use the Yubikey Manager cli program to configure a USB port on the computer as well? If so do I do this in dom0, sys-usb or each of my working vms?
KeePassXC uses the YubiKey’s OTP/Challenge-Response interface.
The Qubes CTAP Proxy (and standard U2F proxies) are designed to proxy FIDO2/U2F requests to web browsers. They do not forward the low-level USB transactions required to unlock a KeePassXC database via Challenge-Respons
This means you have to pass the whole device to the VM where your KeepassXC is actually running.
Thanks Zrubi. Appreciated. So the documentation procedure I referred to above is completely separate from the one I should be using (which I assume then should be Multi-factor Login — Qubes OS Documentation )? If the Yubikey must then be attached to the Keepass vm, does this mean, that I need to remove it and attach it to another vm for use there (such as a banking vm)? If so, it sounds like qubes would require two, three or more hardware keys for any kind of convenience amongst vm’s.
The doc you have referred and followed are for using your Yubikey as a FIDO2 device for authenticating on websites with passkeys.
And there is no password manager involved in this method, so this has nothing to do with your KeePassXC - or any other password manager at all.
KeePassXC is a password manager that can use Yubikey to encrypt (~kind of MFA) your password database. However this method is not compatible with the CTAP proxy.
And this is not really needed, neither it is adding to much to your security - if you follow the Qubes standard/recommendation to use a non-networked VM for holding your KeePassXC database.
(So if you still want to use that, you need to pass your entire Yubikey device to the VM (qube) your KeePassXC is actually running)
So those are 2 completely independent - but currently not compatible - use case of your Yubikey.
And - not trying to confuse you - but there are many more use case like:
- encrypting/decrypting your LUKS device
- locking your screen
- using it as an MFA method to your login
- using it to hold/generate your SSH/GPG/x509 keys
Thank you Zrubi for the information. Yes, I have been using a non-networked vm for my KeepassXC and using ctl-c ctl-v to access it from other vm’s. I guess I was trying to do too much with my new Yubikey. I mainly wanted it for increasing useage with browser site accesses from two or three vm’s and I had originally wanted it as well for my Qubes logins, although my Qubes installation runs entirely on a desktop box with firewall access denied from any other devices on the router. So realistically the Yubikey login would probably just be a ‘nice to have’ feature, more than an actual need I guess. Thanks.
You should go for it for sure!
Just don’t mix it up with your passwords and with your KeePassXC, as it is completely independent of those.
FIDO2 is a passwordless auth method, what you can try/learn here:
It can be confusing because most of the password managers out there are trying to comply with these and simulating similar ‘services’…
BUT if you do have a real Yubikey you don’t need anything else, but the key (sitting in your sys-usb) and your CTAP Proxy configured correctly.
Using you Yubikey for dom0 (or GUI domain) Logins is much more trickie, as it is depends on a lot of things in case of Qubes. And if any of those are broken/not working and/or just having some issues, you can easily lock yourself out from your device.
So in practice, you should only (try) set it up as an ‘quick login’ alongside with normal password as a fallback method…
(pam_u2f is the keyword - if you wanna try such)
Thanks. I think I will decide against the Yubikey for Qubes login.
Small practical point if you keep the KeePassXC database in an offline qube: before experimenting with Challenge-Response, make sure you also have a normal database backup and a second initialized YubiKey stored separately. With CR, losing or resetting the only key can make the database effectively unrecoverable.
For the browser/FIDO2 side, I would keep that as a separate setup: CTAP proxy in sys-usb, then only allow the browser qubes that need it. That avoids attaching the whole USB device to a networked qube just because one site wants a security key.
One extra habit that helps here: keep the FIDO2/passkey use and the KeePassXC challenge-response use documented as two separate setups, including which qubes are allowed to request each one. It avoids the common mistake of attaching the whole YubiKey to a networked browser qube just because a site wants WebAuthn. For KeePassXC CR specifically, I would test opening a copied database with the spare key before depending on it.