I realized the Yubico Authenticator flatpak is not official. So, I’m looking into installing the official Authenticator from Yubico. Unfortunately, it’s a tar.gz file and I thought I’d try to verify what I’m doing before I blindly start entering commands.
The tar.gz file is downloadable from:
The official instructions for installing the thing are here:
In a nutshell, they amount to:
Have PCSD running: I ran systemctl is-enabled pcscd and it came back with “indirect.” So, I’m guessing that means it’s running in some “indirect” way, but it is running.
QR scanning requires either gnome-screenshot or Spectacle. I have Spectacle.
Run the app using ./authenticator from the directory where I’ve extracted the tar.gz.
To integrate with the desktop, run the desktop_integration.sh script.
Of course, the first thing I had to do was figure out how to extract the tarball. I did that by running tar -xvzf yubico-authenticator-7.3.0-linux.tar.gz where I downloaded the file (“7.3.0” is the latest version that downloaded).
Questions:
Is all the above legitimate in Bazzite (i.e., it won’t break either Bazzite or the app (“is it … ‘atomic’?”)?
Is this the “proper” way to install Yubico Authenticator on Bazzite?
Is there a preferred place to keep extracted tarballs on Bazzite?
Is there some kind of tool like Gear Lever (for appimages) that manages extracted tarballs.
I’d also like to know if the desktop integration script will work on Bazzite, but I don’t want to dump the whole script here. The crux of it seems to be:
EDIT: Well, after looking at the above for a while, everything seems self-contained and doesn’t look like it would do anything to system files. So, I just moved the extracted tarball to a folder called YubicoAuthenticator in my Home directory and followed the instructions. It seems to be working fine. I ran the desktop integration script and it added the application to Utilities in the Application Launcher. I added it to my Favorites and taskbar as normal.
Should be fine. The “atomic”-ness of Bazzite is in the OS, not the user-writable data, so applications aren’t “atomic” in the same way, unless they’re in the base image (e.g. Steam).
Flatpak is recommended first, before any other method, so in a sense, no, but since there are limitations in that version (e.g. screenshotting doesn’t work), it’s fine to install it using another method.
I’ll answer 3 and 4 together: if the application is a fully self-contained executable file, either AppImage or a golang binary, then it’s fine to just put it in a bin folder on $PATH, but for something distributed as many files (in a tarball or other archive format), it would be tidier to put it in a Distrobox and export it. The way you’ve got it working is fine, but updating and uninstalling are more straightforward with Distrobox: you just delete the container, and if updating, create a new one and install the new version in it.
One caveat: I use the Flatpak version myself and just work around the broken screenshotting, so I don’t know whether anything extra has to be done to make screenshotting work from within a Distrobox container.
Thanks for posting this guide. I’m currently also running the software directly instead of using flatpak, but I have used the flatpak version in the past, until it stopped working. I think it’s overkill to use a distrobox for this, because the installation is just one folder that you can delete if you no longer want to use the software.
Is there a preferred place to keep extracted tarballs on Bazzite?
Not as far as I know. Pick a directory in your home folder and extract the software there. I suggest ~/.opt (inspired by /opt).
I’d also like to know if the desktop integration script will work on Bazzite
It works like a charm on Bluefin. It only creates a single file in ~/.local/share/applications, which is the standard location for user-specific .desktop files. This is easy to clean up.
YubiKey Authenticator produces some additional files. For example, the file ~/.local/share/authenticator/shared_preferences.json contains information about the desired window size (and no, a distrobox would not have isolated that file). I had to delete this file recently, because for some unknown reason it contained an absurdly large window size and the authenticator crashed on startup.
Well you can’t access your saved OTP codes without the Yubikey authenticator app as far as I know. You can put OTP codes into keepass but they won’t be saved on your yubikey.
It also depends on the sites you visit and how many there are:
If a site uses only passwords, then a Yubikey won’t be of any use there. You’ll need a password manager of some kind.
If a site uses passkeys, it’s possible they won’t allow storing that passkey locally on your Yubikey. They might want to lock you into their ecosystem by forcing you to store the passkey on their system.
If a site does use passkeys and allows you to store them locally on your Yubikey, the passkey has a limited number of slots available for them. Mine is pretty old and stores only 25 passkeys (it also stores just 32 TOTP accounts). I believe the new versions of the Yubikeys will store 100 passkeys (I haven’t heard anything about an increease in TOTP slots).
A password manager can store a lot more passwords than a Yubikey (I’m not even sure if there’s a limit). Plus, many of them now handle TOTP and passkeys. Of course, if you put passwords, TOTP and passkeys all in the same password manager, if that gets hacked, it’s game over. All your eggs are in one basket.
My experience has been that almost no sites use hardware keys. The last time I checked Amazon, they use both passwords and passkeys. But, the passkeys had to be stored in the cloud on their system. Most of the banks I’ve accessed don’t use anything but passwords and SMS for 2FA (not even TOTP).
I’d also like to mention that with the new Bazzite F43.20260303, KeePassXC’s Autotype has stopped working properly. It’s never really worked fully on Wayland systems, but then again, AFAIK, no password managers work fully on Wayland. Wayland’s security model prevents security managers from seeing what site the browser’s on. Now, though, Autotype is randomly lower-casing symbols. So, half the time, logging in doesn’t work and I have to manually copy/paste the passwords. I’ve let them know about this, but they don’t care (I just confirmed something changed all the way up at the Fedora level, but they said:
“Why would we make a change to our implementation when it is only broken on one distro?”
That one distro being Fedora and, possibly, every distro based onit). So, now I’m looking for another password manager (and local, non-cloud-based password managers seem to be scarcer than hen’s teeth).
The YubiKey software is exclusively for working with the YubiKey. You can use it to manage TOTP codes and passkeys. It’s not a replacement for a password manager, because it does not support password management. YubiKeys also have only very limited storage.
I assume that you specifically mean TOTP. What you say is correct, however, whenever you set up 2-factor authentication with TOTP, you get shown a secret seed value. That seed value is usually shown as a QR code, but it can also be a base32 text (typically both are displayed). You can import this seed value both into your password manager and YubiKey. If you lose one, you still have access to the other. Be mindful that YubiKeys can only store a limited number of TOTP seeds (plus account metadata) due to limited storage and you want to use that limited space for accounts that are most important to you.
That is correct for resident keys. However, WebAuthn also supports non-resident keys which take up zero amount of storage on your hardware keys, because they get reconstructed automatically based on the domain and your userID/username. You can “store” an infinite number of non-resident keys on a hardware key. The industry has unfortunately decided that remembering usernames is too hard and that is why they have decided to push resident keys onto people. This is not a problem for people who store their passkeys on their computer, phone, or in the cloud, where there is plenty of storage available. But these storage places are still a lot less secure than a hardware token.
Non-resident keys are still an option. And some web sites support them. I also write this post to inform more people about non-resident keys, because they are cool and useful technology. And if passkeys become truly widespread, then our hardware keys will run out of space very quickly, if most websites require resident keys.
This forum, where we are posting right now, supports them. Unfortunately it only supports resident keys, which takes up one valuable slot on my hardware key.
I found a table on the Yubico site showing the capabilities of the various firmware versions of their Yubikey 5 line. It shows the increase in those resident keys @stego mentioned. With firmware 5.7.x, OATH Credential Storage went from 32 to 64 slots (I’ve currently got 31 of 32 filled) and FIDO2 Credential Storage went from 25 to 100 slots. Plus, there seems to be quite a few new capabilities.
When devices with firmware 5.7.4 (which is in the newest version still in the review stage) gets onto the devices they sell, I think I’ll be replacing my old keys (which are based on firmware 5.2.x). I’m sure that will be fun.
