Hardware Security Key on Schallbert's Blog

Use Password manager with hardware security keys

Schallbert — Sun, 18 Oct 2026

The Password Manager

The web is full of various password management solutions. This is understandable, given that we have an ever-increasing number of accounts, and no one wants to memorize passwords in the hundreds. So, let’s get straight to the point:

From the vast array of options, I evaluated three password managers based on my criteria (secure, user-friendly, open-source, self-managed) to make a final choice:

Firefox password manager (Online/Offline)
Vaultwarden (Online)
KeePassXC/KeePassDX (Offline)

Not the Firefox Password Manager

I ruled out Firefox because I want to use my hardware security key to unlock it rather than memorizing a long master password. On the plus side, however, it offers great ease of use, automatic form filling, and synchronization capabilities, albeit via third-party infrastructure.

Not Vaultwarden

I had been focusing on Vaultwarden for a long time. Running it on a local network requires meeting numerous prerequisites and setting up supporting software. Specifically things like HTTPS on the LAN and ACME challenges. Consequently, you need a dedicated small computer on your LAN, and ideally, a virtual private server to handle HTTPS traffic termination. Vaultwarden even supports incredibly convenient passkey-based login and can synchronize the password database across all devices on the network.

Ultimately, however, I avoided the complex setup, its additional dependencies, and software packages, all of which I would have had to maintain.

KeePassXC

I experimented with various versions of KeePass and eventually settled on KeePassXC. The overall package simply feels more polished and modern; I can use the software across different operating systems, and the extensions needed for hardware security keys (HSKs) are included right out of the box.

Setting up KeePassXC with an HSK

KeePass uses the keyed-hash message authentication code (HMAC) method to unlock the password database using hardware security keys. It relies on a shared secret key that must be present on both sides but is not exchanged between the parties.

Typically, you generate the secret key on the hardware security key and then copy it into the KeePassXC input field. But let’s take it step by step, as the process depends slightly on the specific HSK being used.

YubiKey

Yubico has prepared a guide specifically for use with KeePass. A YubiKey has two configurable slots that support various cryptographic functions. From the function selection, choose Challenge-response: program a challenge-response credential. The YubiKey then generates a 20-byte HEX code, which can subsequently be copied into KeePassXC.

It is important to note that the displayed code cannot be extracted later. Therefore, if the database is to have a secondary key (which is recommended), the code must be written down and then also stored in the secondary key.

For the YubiKey, I recommend leaving the requires touch option unchecked. Otherwise, you have to touch the YubiKey every time you use a password. Even more annoying is that touching the key also becomes necessary when adding or modifying a password entry.

Nitrokey

Nitrokey specifies that the secret be generated as a 20-byte base32 code. It can store exactly one HMAC secret. Nitrokey also provides an online guide for storing the HMAC secret for use with KeePassXC. As with the YubiKey, this guide relies on using the GUI app.

YubiKey - Nitrokey Compatibility

Ideally, I would store the key generated on the YubiKey onto the Nitrokey, or vice versa. That way, I would have a backup key and could access the KeePassXC database using either one.

But behold, the Nitrokey does not accept the YubiKey’s secret:

The same thing happens when I try to store a secret generated on the Nitrokey onto the YubiKey:

I needed a workaround for this. So, taking a pragmatic approach, I created a second password database. Both were intended to hold the same content but use different keys to unlock. I later learned that this wasn’t actually necessary. Nevertheless, here are the provisional solutions I came up with initially.

Dead End A: Cloning entries from the database

I populate the first database with passwords, sorting them into groups. Then, I clone a group, open the second database, and drag and drop the clone over.

Drawbacks: I have to repeat this process for every group, as drag-and-drop functionality isn’t supported for the root group. Whenever I make a change in Database_yubikey, I also have to update Database_nitrokey.

This becomes tedious, especially while the database is still under construction.

Dead End B: Copying the entire database and updating the HMAC

To do this, you store the HMAC secrets for both hardware security keys (HSKs) within the password manager. When the database changes, you create a copy of the database file, open it, and copy the secret belonging to the other HSK. Then, you navigate to Database > Database Security > Change Challenge-Response and enter that secret. The database now works with the other key.

Drawback: Requires manual updating of both databases. The challenge-response setup has to be reconfigured every time.

Solution: Converting the HMAC secret

I wondered if I could use the command line instead of the app to store the HMAC secret for my Nitrokey. Command-line tools like nitropy usually offer more options than their GUI counterparts. Perhaps this would allow me to solve the compatibility issue. Here is the link to the nitropy installation guide.

While looking for suitable documentation, I came across this interesting post about challenge-response. It made me realize something that tech-savvy people, or at least those who are used to cryptography, or work close to hardware, have known for a long time:

Data with a size of 20 bytes can be represented as 40 characters in hex AND as 32 characters in base32.

Consequently, an HMAC secret can be converted and stored on both the YubiKey and the Nitrokey. To do this, I use the small utility xxd to generate a base32 phrase for my Nitrokey from the YubiKey’s hex code.

# open a new terminal
# make sure the secrets are not saved to history (command for zsh)
history -p 
# c0ffee = secret hex key
# xxd convert input to binary (-r), output as plain hexdump (-p)
# interpret as base32 string
echo -n 'c0ffee' | xxd -r -p | base32
YD764===
# close terminal

Alternatively, it also works the other way round:

# open a new terminal
# make sure the secrets are not saved to history (command for zsh)
history -p 
# YD764=== = secret base32 key
echo -n 'YD764===' | base32 -d | xxd -p
c0ffee
# close terminal

KeePassXC: Keeping Passwords Neatly Organized

If you avoid using “Log in with Google” options for third-party services, you can end up accumulating a large number of passwords over time. To make finding and using these passwords easier on both mobile and desktop, it makes sense to organize them into logical groups.

Password Families

After some experimentation, the following naming scheme has proven effective for titles when I need to store multiple related passwords:

baseapp.attribute.specialization

For example, here is how the login details for my hardened Gitea setup would look:

gitea.login.schallbert
gitea.login.testuser
gitea.runner.registration
gitea.recoverykey

Password groups

I consider the following groups of passwords to be sensible:

Group	Description
Devices	Computer, phone, router, keys
Finance	Banks, credit cards, insurances, payment
Identity	Email, identity providers, single sign-in
Shopping	Online stores, streaming, subscriptions
Games	Platforms, launchers, servers
Social	Forums, Messengers, Social networks
Backup	Recovery keys, licenses, passphrases

In doing so, I make sure not to create too many subgroups. Otherwise, it is easy to get confused, especially in the mobile view.

Icons 🔑

KeePassXC offers the wonderful feature of downloading the target website’s favicon and using it as an icon. This makes navigating the password manager even easier.

However, the favicons are all bitmaps. If you prefer to use high-quality vector graphics, you can specify the path to an icon pack under “Choose Icon.” I downloaded the Aegis icons for this purpose and am very happy with them.

SSH connection errors

Schallbert — Fri, 12 Jun 2026

This short article deals with errors encountered when establishing an SSH connection. Whether connecting to other computers, servers, or services like version control systems, the error messages and their corresponding solutions are usually the same. However, it is only worth reading further if standard help pages - such as GitHub’s SSH troubleshooting guide - have not provided the desired solution.

Problem: “No Route To Host”

The console output shows (on a local network):

➜ blog git:(article) ✗ ssh 192.168.0.27
ssh: connect to host 192.168.0.27 port 22: No route to host

Or (on a remote network):

➜ blog git:(article) ✗ ssh 1.2.3.4
ssh: connect to host 1.2.3.4 port 22: Network is unreachable

The cause is very likely an incorrectly entered IP address or a failed DNS lookup. On a local network, a common reason is that the target device is powered off, preventing the router from reaching it. The issue can usually be resolved by correcting the destination address, powering on the target device, or updating the routing table.

Problem: Connection Refused

Terminal output:

➜ blog git:(article) ✗ git push gitea
ssh: connect to host git.schallbert.de port 22: Connection refused
fatal: Could not read from remote repository.

In this case, a connection to the destination cannot be established at all; the process fails before authentication even begins. In my experience, such errors arise for three reasons:

The host is not yet ready. For example, it might be booting up (the network card is active), but the SSH service has not started. The usual solution here is simply to wait.
A firewall, rate limiter, or services like fail2ban reject the connection (REJECT). This is often caused by too many failed login attempts or an overambitious bot detection mechanism. In rare cases, your IP address might also appear on a “deny-list” loaded by the target system. In this instance, too, the best course of action is to wait.
The service in question expects a port other than the standard SSH Port 22. Consequently, the user, target address, and port do not match.

The port issue is easily resolved.

Determine the Port on the host (Server Configuration / SSH). The image shows the settings for my Gitea instance. Alternatively, simply checking the service’s configuration file is usually sufficient.
Specify the correct port number in the SSH configuration file at ~/.ssh/config. Example:

# /.ssh/config
 Host gitserver
 Hostname git.schallbert.de
 Port 222
 [...]

Problem: Too Many Authentication Failures

Terminal output:

➜ blog git:(article) ✗ git pull
Received disconnect from <ipAddress> port <portId>: Too many authentication failures

So, we have a connection to the server 😁, but it won’t let us in 😨. At least it tells us why: it claims we’ve tried too many keys at its front door.

This error occurs when the server’s limit for login attempts is exceeded. For the sshd service, the default value is, for example, MaxAuthTries = 6. If you have saved many keys for multiple connections - or, like me, have recently started using Hardware Security Keys and set up backup keys (effectively doubling the key count) - this limit is quickly reached.

The tricky thing about this error is that it only appears with specific services “further down” in the agent’s keychain: after all, five keys are allowed to fail before the limit is hit. Furthermore, having the keys correctly configured in ~/.ssh/config doesn’t protect you; the agent always attempts to use all available keys unless explicitly told otherwise.

We can prevent this by using IdentitiesOnly yes. This explicitly instructs the agent to use only the identities (i.e., key files or username/password) specified for that particular host.

# /.ssh/config
Host gitserver
Hostname git.schallbert.de
Port 222
User <user>
PreferredAuthentications publickey
IdentityFile <path_to_private_key1>
Identityfile <path_to_private_key2>
IdentitiesOnly yes

Checking the Git config

You can also encounter this error if the repository’s Git configuration (located at <reponame>/.git/config) does not match the server and repository details defined in your SSH configuration (~/.ssh/config). If you change the SSH configuration, all repository configurations maintained locally must also be updated.

Example:

# <reponame>/.git/config
# [...]
[remote "origin"]
	url = ssh://git@git.schallbert.de:222/schallbert/<reponame>.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
	remote = origin
	merge = refs/heads/main
	vscode-merge-base = origin/main

In this case, the gitserver configuration is not used at all; instead, the connection is established directly. Consequently, the agent does not receive the IdentitiesOnly yes flag and cycles through keys until the server rejects the connection. Solution:

[remote "origin"]
url = git@gitserver:schallbert/<reponame>.git
fetch = +refs/heads/*:refs/remotes/origin/*

Problem: Permission Denied (publickey,password)

Console output:

➜ blog git:(article) ✗ ssh -T git@gitserver
git@git.schallbert.de: Permission denied (publickey,password).

Unfortunately, this problem can have many different causes. GitHub’s guide addresses a few of them, including:

Using sudo
Wrong server
Not using the git user
Using the wrong key (client)
Key not registered (server)

The output for an incorrect username looks like this:

➜ blog git:(article) ✗ ssh -T mit@gitserver
mit@git.schallbert.de: Permission denied (publickey).

Another cause can be a mismatch between the ~/.ssh/config configuration file and the remote address stored in the git client. If they do not match, any existing configuration will not be used at all.

You can verify this using git remote -v.

➜ blog git:(article) ✗ git remote -v
origin	ssh://git@git.schallbert.de:222/schallbert/blog.git (fetch)
origin	ssh://git@git.schallbert.de:222/schallbert/blog.git (push)

The correct approach, using the improved configuration file (with ports explicitly set and identity files defined and restricted to the specified ones), looks like this:

# Update link to server's git repository, use host alias from config file
➜ blog git:(article) ✗ git remote update origin git@gitserver:schallbert/blog.git
# Now check if the update was effective
➜ blog git:(article) ✗ git remote -v
origin	git@gitserver:schallbert/blog.git (fetch)
origin	git@gitserver:schallbert/blog.git (push)

Problem: Agent Refused Operation

Console output:

➜ blog git:(local-setup) ✗ git push --set-upstream origin local-setup
sign_and_send_pubkey: signing failed for ED25519-SK <path-to-private-key> from agent: agent refused operation

I have only encountered this error since I started using hardware security keys for SSH. As I see it, there are two possible causes. Fortunately, both are easy to fix:

The agent does not recognize the key. The ssh-add command resolves this. Verify using ssh-add -l | grep "<your-key's-comment>"
The requested key is missing. This can happen with HSKs and HSMs if they are not plugged in, not positioned correctly on the NFC reader, or if the HSM is unavailable on the network. It can also occur if the ~/.ssh/config file was edited manually and the key has since been renamed or deleted.

Hardware Security Key: add SSH

Schallbert — Sun, 03 May 2026

Motivation

In my post about hardware security keys, I wrote that I want to secure as many of my connections as possible without passwords provided by my new HSK. I use SSH connections for various services and purposes: I access my VPS, use services such as GitHub, Gitea and my own Gitea instance and run backups on the local network via scp, which uses the SSH protocol.

Setting up SSH access for hardware security keys

HSKs such as my Yubikey can store private keys for SecureShell access. This means you no longer need to store them locally on every device (although this remains configurable; see below). Furthermore, they are better protected against unauthorised access than if stored on a computer.

So I’m trying to switch my GitHub SSH access to HSK and am following Yubico’s guide to passwordless authentication for GitHub. The procedure for generating FIDO-compliant SSH keys is the same across different key manufacturers. I’m also linking to the Nitrokey guide for reference.

What doesn’t work

However, even with Yubico’s own recommendations, I am unable to achieve the desired result on my operating system and with the standard installation of openssh. The command assembled from the guide is:

schallbert@machine:~# ssh-keygen -t ed25519-sk -O resident -O verify-required -O application=ssh:github -O user=schallbert -C 'schallbert@github.com'

Once generated, we must store the public key (file extension .pub) in the web application of the respective service under the SSH Access menu item.

Meaning of the command and the most important options

This command¹ tells ssh-keygen to generate a key of type -t ed25519-sk for me. The suffix -sk indicates that the key should be stored on a hardware security key - in my case, the Yubikey.

To understand the -O resident flag, we need to know that the FIDO authenticator key, generated as with -sk, consists of two parts: a key handle part, which remains on the computer’s hard drive, and the private key itself, which exists only on the HSM. Only together can they correctly respond to authentication requests. The flag itself, however, instructs the program to write both parts of the key to the Yubikey. This makes it easier to use multiple devices with the same key: the key handle part can be read from the Yubikey and stored on other end devices. On the other hand, however, simply losing the Yubikey is now enough to grant potential attackers SSH access.

-f filename specifies the names for the key files. This is particularly useful when you need to manage multiple SSH connections or HSMs. I’ve created a naming convention to avoid confusion. It’s based on the syntax used to read keys from an HSM (ssh-keygen -K).

-f <keyType>_<protocol>:<service>_<user>_<device>

As a concrete example, my filename here would be as follows:

-f ed25519-sk_ssh:github_schallbert_yubikey-main

⚠️ Note when using Windows: The colon : is not allowed as a character in filenames. It is replaced by an underscore _, which must also be reflected in the config file (Ctrl+H -> replace : with _)

-C schallbert@github.com adds a comment to the key file itself, such as a contact address. This gives the key a label, which makes it easier to manage when dealing with multiple keys.

-O application=ssh:github is simply for neat listing in the Authenticator and ensures that I cannot confuse one key with another. Otherwise, it would simply say ssh:keygen and I would no longer be able to see which services I have stored keys for. Also helpful to discriminate keys when using the -resident option in congunction with key extraction ssh-keygen -K.

-O user=schallbert has no practical use for me, as SSH is not interested in this flag and, contrary to my expectations, the Yubikey Authenticator does not display the username.

-O no-touch-required prevents the hardware security key from having to be touched every time the key is used. Useful for very frequent use, though it compromises security due to the possibility of automation.

-O verify-required specifies that the HSM’s PIN must be entered before the key can be used. Although intended as an additional security measure, this causes problems for me in my shell. Specifically, the PIN is requested once, but the ssh-agent does not generate a prompt in my console every time. As soon as I try to connect via SSH in another session, I receive an error message: agent refused operation:

schallbert@machine:~# ssh -T git@github.com
sign_and_send_pubkey: signing failed for ED25519-SK "schallbert@github.com" from agent: agent refused operation
root@opnsense: Permission denied (publickey).

What was the problem?

After a long, frustrating troubleshooting session (What am I doing wrong? Does it work with the secondary key? Why does it work the first time but not afterwards? What if I regenerate the keys? What happens on other computers? What does ‘AI’ say about this? - The latter certainly took an hour and left me completely stuck), I try a different command. That works straight away.

What does work, however

schallbert@machine:~# ssh-keygen -t ed25519-sk -O application=ssh:github -C 'schallbert@github.com' -f ed25519-sk_ssh:github_schallbert_yubikey-main

If I omit verify-required, I can log in successfully and the SSH agent runs fine.

What `verify-required` requires

This post sheds some light on my issue. The terminal session I use to create the SSH key pair temporarily stores the PIN entry enforced by the verify-required flag. That is why the login works initially. If I log in later or in a different window, as I did above to check git pull in one of my repos, for example, the SSH agent does not ask for my PIN.

This is likely because the SSH agent itself cannot display prompts to the requesting programme. A submodule of OpenSSH provides a solution: openssh-askpass . This can be passed to the agent, which then transmits the PIN prompt to the user via askpass.

Installing ssh-askpass

My operating system did not have ssh-askpass installed by default, so I’ll install it here. It uses the package manager DNF (‘Dandified YUM’) instead of apt or other common managers. In my opinion, the naming convention isn’t 100% consistent: whilst I address the ssh programme in the terminal as ssh-agent, I have to type openssh-agent for the installation.

# verify-required needs openssh subpackage through Fedora's package manager
schallbert@machine:~# sudo dnf install openssh-askpass
Installing:
 openssh-askpass
[...]
Complete!

Now I want to tell the agent that it can use ssh-askpass to request the PIN. To do this, I need to know the path to the submodule.

schallbert@machine:~# which openssh-askpass
/usr/bin/which: no openssh-askpass [...]

Strange, I installed it above! Let’s have a look what the package manager has to say.

schallbert@machine:~# dnf repoquery --list openssh-askpass
[...]
/usr/libexec/openssh/ssh-askpass

Ah, openssh hides in libexec. Well, then I can link ssh-agent to ssh-askpass.

schallbert@machine:~# eval "$(ssh-agent -s; SSH_ASKPASS=/usr/libexec/openssh/ssh-askpass)"
Agent pid 16747

I check the connection to GitHub and, as expected, a dialogue box appears asking for my PIN. I then need to tap the HSK, after which I receive a success message. To ensure that this all works in a new terminal and after restarting the computer, I add a reference to the key in my configuration file.

# ~/.ssh/config
Host github
 User git
 Hostname github.com
 PreferredAuthentications publickey
 IdentityFile ~/.ssh/ed25519-sk_ssh:github_schallbert_yubikey-main

To be on the safe side, restart the agent and create new terminal sessions. If any login details were cached, this will reset them. When done, validate SSH connectivity.

 schallbert@machine:~# eval "$(ssh-agent -k)" && eval "$(ssh-agent -s)"

Annoying: Gnome pop-up ‘Allow inhibiting shortcuts’

The only downside is that I now get an extra pop-up when connecting via SSH. This is triggered by the gnome graphical user interface. Unfortunately, I can’t find an option to save the relevant setting permanently. As a result, it appears every time I connect with verify-required. With Gnome, the problem is already known to affect other applications, but apparently has not yet been resolved.

Transferring to Windows systems

I generated my keys using the -O resident option. It makes sense to test the extraction of the key-handle on a completely different system: Windows.

I open the command line and type

schallbert@windows-machine:~# ssh-keygen -K
Enter PIN for authenticator:
You may need to touch your authenticator to authorize key download.
Provider "internal" returned failure -1
Unable to load resident keys: invalid format

Invalid format? It’s often mentioned online that the keys sometimes need a line feed character at the end to be recognized correctly. However, I cannot modify them without downloading them from HSK. So I manually transfer the public key and key handle to the computer and try out the git pull command as a test. And look: it works!

So if you want to use the keys with different operating system families, the -resident option doesn’t seem to be of any use. The command ssh-keygen -K does not allow granularity: It will load all resident keys from the HSK at once.

VPS: Be careful when replacing keys

Another tip from personal experience: If you’ve already stored SSH keys with a service provider that hosts live-resources itself (in my case, a server as a VPS), new SSH keys are usually not passed on to that resource via the web frontend.

Consequently, the “old” keys are still needed, and the new ones aren’t used, even though they’re stored in the web app!

The new keys must be manually added to the destination.

I follow the instructions from my host Hetzner using the ssh-copy-id command.

Manually store new keys on the VPS

schallbert@machine:~# ssh-copy-id -i ./ed25519-sk_ssh:server_schallbert_yubikey-main.pub server

Here, server is the SSH alias for my VPS. The connection is established using the familiar “old” key, and the “new” one is saved. But something isn’t working as expected:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
		(if you think this is a mistake, you may want to use -f option)

Was the key transferred successfully?

So I log back into my server and check whether the new key actually appears in the ~/.ssh/authorized_keys file. It doesn’t. So I run the command above again, this time with the -f (Force) option enabled. And sure enough, the transfer works!

schallbert@machine:~# ssh-copy-id -f -i ./ed25519-sk_ssh:server_schallbert_yubikey-main.pub server 
Number of key(s) added: 1

Now try logging into the machine, with: “ssh -i <identityFile> 'server'”
and check to make sure that only the key(s) you wanted were added.

To test it as recommended, log in with the new key and… It works! Only now can the old keys be safely deleted.

How to avoid ssh-copy-id

If you want to transmit the public key without using additional tools, you can copy the contents of the public key file <key-filename>.pub directly into a new line of ~/.ssh/authorized_keys. You just need an open SSH connection to your target.

Thoughts on convenience and usability

When I look at my SSH connections, they broadly fall into two categories:

Admin access (VPS, NAS, Raspberry Pi) and signatures
Protocol access (Git etc.)

In my view, the former require a higher level of security. Furthermore, I don’t use them as frequently as version control systems. I therefore recommend verify-required for the first category and would omit this for the second. I would take the same approach with the no-touch-required option: if a commit is to be uploaded every few minutes, constantly having to touch the key is rather annoying.

All options are displayed when you open the manual using man ssh-keygen. ↩︎

Hardware Security Keys

Schallbert — Sat, 25 Apr 2026

Definitions: TPM and HSK

Acronym	Term	Brief description
TPM	Trusted Platform Module	Soldered securely. Protects a device
HSK	Hardware Security Key	Mobile. Protects accounts, certificates, private keys

The Trusted Platform Module is a security chip that securely stores cryptographic keys and provides functions such as Secure Boot, BitLocker encryption and device identity. It is permanently soldered onto the motherboard of a computer, smartphone, etc.

A Hardware Security Key HSK, on the other hand, is usually portable and can be connected to various devices. It can not only store keys, but often also perform cryptographic operations (key generation, signing, encryption). HSKs are designed to be highly secure and tamper-proof. They can be externally certified or audited, meaning that even highly sensitive processes such as payment transactions can be carried out.

What happened so far

I listened to a podcast from the Bundesamt für Sicherheit in der Informationstechnik (BSI) on the topic of ‘Passkeys instead of passwords’. Following the recommendations, I bought a Hardware Security Key (HSK) so that I can use passkeys for my services in future. For a long time now, I have been unhappy with my fragmented secret management system consisting of notes, browser plugins, offline password managers such as KeePass, SSH credentials stored on my hard drive, backup keys and emergency codes from various providers.

I’d finally like to bring some order to the situation without tying myself so tightly to a commercial provider that I become dependent on them.

Objectives

No longer having to remember passwords or login details
Setting up a system for managing passwords that is as simple as possible, yet secure
Bringing order to the jumble of accounts
Organising my digital legacy
Enabling others to do the same

Welche Erwartung ich jetzt schon einmal nehmen kann: Ganz ohne Passwörter oder Pins geht es auch mit dem HSK nicht. Ein Yubikey ist kein Passwortmanager. Er kann zwar Zertifikate, Passkeys und Secrets für OTPs halten, gibt diese Geheimnisse dann aber nicht mehr preis. Mit seiner Hilfe kann man signieren (Authentizität beweisen), Verschlüsseln und abgeleitete Schlüssel erstellen.

In fact, password management can be centralised and simplified using the Yubikey. Popular password managers support passkeys meaning a master password is no longer required.

Yubikey

As an HSK, I use two Yubikey key fobs. One to carry with me at all times and one as a spare, which is kept in a safe place. There are other providers of mobile Hardware Security Keys, such as Nitrokey. I wasn’t aware of them before writing this article. That’s a shame, as their product is open-source and therefore an ideal candidate for testing on my blog 😥.

Yubico Authenticator

The Yubikey Authenticator GUI programme is useful for setting up the device, assigning functions to the Slot key (e.g. confirmation or password entry via keyboard simulation) and if you use 2FA-Einmalkennwörter z.B. als TOTP. Furthermore, my Yubikey supports PKI, meaning that SSL certificates and private keys can be stored securely.

Concept of the HSK

Part of the concept is that private keys are either generated directly on the hardware key or - without being permanently stored locally - are created on an end device but stored on the Yubikey. These remain on the key and cannot be exported. It supports common asymmetric methods such as RSA and ECDH. For further details, see this BSI publication on cryptographic methods. Furthermore, the key will be kept offline most of the time, i.e. without a power supply. Thus it is virtually impossible to compromise. An additional PIN as a protective measure in the event of key loss is a further security factor.

Spare key

Nevertheless, you should make a note of which access points you protect using which method, so that the correct accounts can be locked in the event of loss. A ‘spare key’ should be available and set up, which is almost as time-consuming as configuring the main key.

NFC

I’d hoped that my key’s NFC support would make logging in even quicker and easier. However, two things bother me here: I simply cannot get my laptop to recognise the Yubikey via NFC. And on my mobile, NFC recognition works at best flakily. When I hold the key up to it, the app launches and asks me to enter the PIN. If I do so, I have to remove the key and hold it up to the sensor again (‘Do not move the key!’). This doesn’t work every time by a long shot and seems rather prone to glitches overall. A pity.

What I find myself missing when using the Yubikey

Overall, I do miss a few convenience features in my day-to-day use of the Yubikey. When I click on the desired keys or accounts, nothing happens. And it seems I can’t configure anything there either.

When using passkeys, I’d like to see a shortcut. Clicking on the relevant key in the authenticator should open the corresponding app or browser window with the target website. Since I’ve already unlocked the HSK with the PIN at this point, the login process can even take place fully automatically once the key is tapped.

I’d like to see something similar when managing accounts. Why is the module called ‘Accounts’ if I can’t access them directly? Here, too, I have to open the relevant web apps etc. myself, have the password manager ready, and then copy the 2FA codes from the authenticator. There must be an easier way.

Touch, password, PIN, PUK, management key, passphrase

Depending on the module, multi-factor authentication is usually required even when using the Yubikey. The simplest method is presence detection via a touch of the dongle. This ensures that a person is actively operating the HSK and cannot, for example, be logged in automatically. Touch can be used across modules; for detailed configuration, see my article on SSH.

The Accounts module can optionally be secured with a password, whilst the Passkeys module is secured via PIN. Some providers even require a PIN to be set up as a second factor.

The Certificates module must be protected against unauthorised access using PIN, PUK and management key. Private keys or certificates can optionally be protected with a passphrase, which locks the keys themselves (and, in my view, makes no sense for the Yubikey, as the private keys cannot be read anyway).

Feature set and cryptographic landscape

Since the HSK promises such a significant security boost, I naturally want to make use of as many of its capabilities as possible. I’ve been playing around with the various modules for a few weeks now and have found that you really need to get your head around them and learn a lot to be able to use them all effectively. At least, once you’ve done so, you’ll have a rough idea of what the modules do and gain a good overview of internet security, encryption methods and protocols.

“Accounts” and “Passkeys” are easy to set up for input forms (platforms, websites, shops) and apps (email clients, password managers, messengers): Highly recommended! - schallbert

Yubikey module	Description
Accounts	Management of accounts/logins, supports TOTP
Passkeys	Passwordless login procedure via FIDO/WebAuthn (public key credential)
Certificates	Storage and use of certificates; supports OpenPGP (PGP) and X.509 (PIV)
Slots	Two programmable slots for generating static passwords or one-time passwords

In my opinion, things get complicated and time-consuming with public/private keys and certificates. Generation and validation procedures depend on the operating system or the programmes available on it, and instructions are sometimes insufficient or contradictory: only for nerds or professionals. - schallbert

Let’s go through the modules.

Two-factor authentication: “Yubikey: Accounts”

The Yubikey can be used as a generator for time-based one-time passwords. To do this, as with any other authenticator app, you create an account for each service and transfer a security key (secret) to the Yubikey. Once the HSK is connected, one-time codes can now be generated based on this secret.

As there is no way to export these secrets from the Yubikey, the process must be repeated for secondary keys. However, not every provider supports the use of multiple authenticators. So it may be sensible to keep the secret in the clipboard¹ and reuse it when configuring the secondary key(s).

Passkeys ‘Yubikey: Passkeys’

The Passkey module on my Yubikey works quite well. Unfortunately, many services² do not yet support passwordless login or only accept Passkeys as a second factor. With other services³, I cannot disable the password, so I see little security benefit, or I am issued with backup codes that are intended to serve as a second factor in an emergency⁴. At least, I can now bypass the password-TOTP process for some services and log in more quickly.

‘The biggest advantages of the technology for users are, on the one hand, that in future they will no longer have to create and manage passwords. On the other hand, passkeys are immune to the vast majority of known phishing attacks.’ - BSI website, 2025 October

You do not need the Authenticator app to configure passkeys. This is done entirely within the browser or the command line. Both must support the handling of passkeys.

Keys & Certificates ‘Yubikey: Certificates’

To shed some light on this, we first need to understand the difference between a key pair and a certificate in the context of authentication. In both cases, the aim is to verify the client’s identity. This may be done with a server (e.g. via SSH), an institution (e.g. a Certificate Authority) or another client (e.g. via PGP). This allows the destination to confirm that the client attempting to connect is indeed authorised to do so.

Public/Private Key Pair

A key pair alone (i.e. without a certificate) is typically used when the communication destination is controlled by the same party as the client. In such cases, the client can place the public key on the host to establish the connection. This method is used, when setting up SSH connections and for certain APIs, such as Google Search Console.

The host can send a test message to the cient encrypted with the public key, which can only be converted back into plain text using the corresponding private key. If the client sends the correct plain text back to the host, this proves to the host that the connection partner is authentic.

Certificates / PIV

But what if the host is not under the client’s control? How can we then ensure that neither the client nor the server is impersonating someone else and has stored a forged public key? This is precisely where certificates are used.

Put simply, the certificate contains not only the public key but also additional information about the network participant and the desired connection. Now a trusted third party, uninvolved in the communication between client and server, comes into play. In the Private Key Infrastructure PKI, this is known as the Certificate Authority CA.

The network participant now sends the public key, together with metadata about themselves, to the CA and submits a so-called CSR, a Certificate Signing Request. The CA then verifies whether the participant’s channel actually belongs to them.

In the case of an email (keyword PGP/GPG), the CA can, for example, send an individual hash link - derived from the requestor’s public key - to the specified email address. If the link is clicked, this proves to the CA that the email address actually belongs to the client, and the CA can then issue the certificate, i.e. sign the CSR with its private key.

For domains (keyword SSL/TLS), the CA can check with the Domain Name Service provider whether the details match the server’s request.

Clients have the signatures of common Certificate Authorities stored (e.g. in the browser). If the certificate is tampered with on the return journey between server and client, its hash value changes and the client displays a certificate warning: ‘invalid certificate’. However, one must now trust the Certificate Authorities⁵ 🙃

The computer should be offline for this. If you want to be extra secure, carry out the pairing on a live operating system. This usually boots from a USB stick and forgets everything after shutdown. ↩︎
E.g. Not at all: Mailbox; 2FA: Discord and Kraken, as of 2026 April. But perhaps I haven’t found the right settings? ↩︎
E.g. Google, GitHub and Hetzner, as of 2026 April. ↩︎
These backup codes must also be stored securely. Ideally offline again, but definitely independently of the HSK. ↩︎
There are alternatives to institutions such as CAs; see Web of Trust. For example, identity verification can also take place peer-to-peer via uninvolved third parties. ↩︎