When I had to decide whether I should buy a tablet, a laptop, or try to invest in a Steam Deck, I chose the Steam Deck, and I don’t regret it. Earlier, I also invested in a YubiKey hardware token to make many of my accounts more secure with it. But earlier this year, I raised the question: Can I use my YubiKey hardware token to unlock my Steam Deck, at least in Desktop Mode?
What is my motive? In part, the reason I bought a Steam Deck, is because it is a hand-held PC, and allows me to do some fundamental office work and some development too. It can do much more than a tablet could. For this reason, I would prefer to have my hand-held PC be more resilient from a security standpoint. So, let’s say someone gets a hold of it and decides they want to prank me. Any sensitive data will remain locked, and remain locked, until I present my YubiKey to the system.
Now Yubico, the company behind the hardware token, has a guide on setting up their YubiKey under Ubuntu, but there are three catches with this:
- SteamOS since 3.0 deviated from Debian, and is now based on Arch, and still not on Ubuntu.
While this does not seem so much of an issue, what you need to realize is that both Debian and Ubuntu usesaptpackage manager, but Arch usespacman, and the two repository sources use different philosophy to pack packages to these systems, and thus one must match the correct packages needed for the system. - SteamOS is an immutable system, and the system partition is not preserved between updates.
The problem with this is that we want to lock out everyone else from the system with a system module that isn’t installed by default. If an update is applied, (and it is typically applied in Game Mode), then the hardware token-based login breaks, and either you also get locked out, or no one is locked out of the Steam Deck. If you can’t check the hardware key, it doesn’t matter if you have it or not. But the configuration files are also reverted after an update, so you don’t just have to reinstall the module; but you must also do the entire reconfiguration process. - There are two system partition sets.
I have not even considered it yet, (and I’m not discussing this in this article), but SteamOS does the system update by maintaining two system partition sets: It applies the update to the inactive one then switches over, and if the updated system fails to boot, then reverts to the previous partition set. This is only relevant when considering the necessary modules.
⚠️ Important: Before you read further, I must bring your attention, that this blog post describes partial instructions on altering your system configuration. Altering system configurations can lead to a broken system or you being locked out. Also, this is not a complete instruction, so if you have a brand new Steam Deck, chances are, you cannot even invoke sudo yet just by following this set of instructions, and if you have not used a terminal, you may also not know how to invoke it in the first place. Since this is more of a technical article, I am focusing more on how the configuration on SteamOS differs over Ubuntu and to report my findings on adapting this security feature. When I have found out a safe and reproducible way to set up your Steam Deck with a YubiKey, I make a user-friendly guide under Steam Community Guides.
Finding the packages
As any package repositories, they can be searched online. But I have to look for packages for Arch, and the guide is for Ubuntu, and it instructs the reader to install libpam-u2f. I couldn’t find any rhyme or reason how package names from Ubuntu map to Arch, so I just tell you that the package is called pam-u2f in Arch. And I have found it in the Arch repository search online as well, thanks to finding libfido2 first in there, which listed this package as a dependent package. Great! All we need is to install this package.
But before we do that, we have to realize, that SteamOS maintains its own package repositories, which means we can’t just willy-nilly grab a package from the main Arch repository and install that. There was even a report on the Steam Community forums that this broke the system. But even if it doesn’t, I prefer to install with the least hassle. After initializing and populating the repository key, it is time to run the command that installs the package we are looking for:
sudo pacman -S pam-u2f
But this didn’t work for me: pacman reported, that it can’t find the pam-u2f package. I said no worries, I will compile it from source, but then I noticed that libfido2 is also missing. Out of desperation, I have decided to just open the repository directory in a browser. We can read these URLs from the /etc/pacman.d/mirrorlist file, gather the extra-3.6 value for the $dist key from the /etc/pacman.conf file, and realize that $arch cannot be anything else than x86_64. I have found the missing package with the name of pam-u2f online in the SteamOS repository and ended up constructing the following (existing) URL: https://steamdeck-packages.steamos.cloud/archlinux-mirror/extra-3.6/os/x86_64/pam-u2f-1.3.0-1-x86_64.pkg.tar.zst. After that, I executed a slightly altered version of the previous command, and it worked this time:
sudo pacman -U https://steamdeck-packages.steamos.cloud/archlinux-mirror/extra-3.6/os/x86_64/pam-u2f-1.3.0-1-x86_64.pkg.tar.zst
However, after any subsequent attempt, running the prior command succeeded. I do not know what went wrong; have I actually tried pam-u2f, or misspelled the name of the package as pam_u2f, or just never tried the correct name after finding it in the repository and just proceeded to download the file through the URL? Or the package is now cached—that is also a possibility. Either way, I have the package installed, and I can call the pam-u2f.so module, and invoke the pamu2fcfg command.
Configuring your Steam Deck with YubiKey
This one is fairly straight forward here on. However, I want to take care of two things:
- Non-destructive way of locking my Deck with the YubiKey
- Preserving the configuration
Since I’ve started thinking about how this configuration can be made, Valve introduced a method of preserving configuration files, by listing these files in a text file, and placing that text file under the /etc/atomic-update.conf.d/ folder. Since I’ve chosen to place the u2f_keys file created while following the guide under the /etc/Yubico/ folder for added security, I’m also utilizing this feature of SteamOS by listing the /etc/Yubico/u2f_keys file there. For increased security, I also changed the permissions from 644 to 600, so only the root user can read it. With this, 2nd is covered… sort of.
If you read the original guide, you also notice, that it also modifies the /etc/pam.d/sudo file, and later others too. We also need to change sudo, su, su-l and system-auth instead, and preserve the configurations too, but there’s a catch: these files come from packages. This means that if the package updates these files while also preserving any of the configuration files with the help of the /etc/atomic-update.conf.d/ configurations, we may skip out on any update introduced in those configuration files. Should this be a security issue? No? Not really? Here comes where I’m a bit confused. Obviously, it would be a security issue if an update could remove an entry from here. However, my concern actually comes from what the /etc/atomic-update.conf.d/example-additional-keep-list.conf example file said:
## Please be careful with what you whitelist here -- `pacman -Syu` may touch ## these files and thus prevent atomic updates from adjusting them in the future.
I have to research what this means regarding PAM, but my speculation is that it means nothing. However, I cannot list libraries and executable files here, as that would prevent the system from updating it in the future. But in the future, the preserve file list should be something like this:
# Preserve the key registrations from pamu2fcfg. /etc/Yubico/u2f_keys # Preserve `sudo` and `su` authenticating with the keys /etc/pam.d/sudo #/etc/pam.d/sudo-i # Does not exist in SteamOS /etc/pam.d/su /etc/pam.d/su-l # Preserve system-wide authentication with the keys /etc/pam.d/system-auth
For the 1st, I read through the manual page for pam.conf, in hopes I can find another control, more suitable than require for the case when the module cannot be found. To test this, I’ve just uninstalled the pam-u2f module and run some tests. I saw that the PAM module returns ‘unknown module’, or something to that effect, when I try to authenticate, when the module is missing. But what I noticed is that you can specifically control how the authentication process should work for each and every return value, including when PAM fails before invoking the module. The manual page also lists what each predefined control value maps to, so constructing a control set that works like require but permits access when the module is missing is the following:
auth [success=ok new_authtok_reqd=ok ignore=ignore module_unknown=ignore default=bad] pam_u2f.so authfile=/etc/Yubico/u2f_keys
While it is not ideal to permit the user to authenticate while the token cannot be read, it is also an important factor, that I do not wish to lock myself out under these circumstances.
Conclusion
☝️ I have achieved some things, 👉 but I still need to work on others, ‼️ while there are things that bother me:
- ☝️ The security configuration is definitely incomplete. While it works, and should work when the original guide is altered with what I did, and it also makes sure that it will not lock you out when an update arrives, but then the key usage will no longer be enforced. This is good for testing purposes, and see how this setup behaves when a new update is released.
- 👉 We must find a way to reinstall the
pam-u2fmodule after an update, or find an already available solution for using the YubiKey for authentication. If thepam-u2fmodule is being removed after every update, while you might not brick your Steam Deck, you definitely cause some unwanted headache, and there is no reason to preserve the PAM authentication configuration files under these circumstances. - 👉 Clearly, a configuration file, that is related to security, cannot be subject to change when a system update arrives, since that would mean, you cannot securely configure your system. So either there should be a ‘user’ configuration file, that an administrator can modify to control the authentication method without worrying about the packages overriding your configurations, or there must be some exemption from updating these configuration files that I’m not aware of yet. We could just ignore this and include these files in the atomic-update configuration files anyway, but that is not how I roll: I like to know how the system and the tools included in it work and then utilize it correctly. I strive for perfection and approach it as close as possible, while perfectly aware that perfection itself is unachievable.
- ‼️ Desktop Mode doesn’t actually require you to log in! This one bothers me, because putting your PC into sleep mode seems quite intuitive nowadays, but doing so on the Steam Deck will mean that your PC will resume to Desktop Mode without any authentication! This is actually a completely different matter from what the article is about, while both topics are about security, but it relates to this, and I want to return to this topic later.
I have originally asked this on the Steam Community in hopes that someone has some information on it, (and since I don’t know where I can find a more technical forum for such questions), that you can find in the following link. The link leads you directly to the related post that describes the steps you need to do to enable YubiKey support in Steam Deck, with a heavy warning:
