Hardware Security Key on Schallberts Blog

Passwortmanager mit Security Keys verwenden

Schallbert — Sun, 18 Oct 2026

Der Passwortmanager

Das Netz ist voll mit verschiedenen Lösungen zum Passwortmanagement. Das ist Nachvollziehbar, denn wir haben immer mehr Accounts und niemand merkt sich eine dreistellige Anzahl an Passwörtern freiwillig. Kommen wir also gleich zur Sache:

Ich habe mir aus dem ganzen Wust drei Passwortmanager nach meinen Kriterien (Sicher, komfortabel, quelloffen, selbstverwaltbar) angesehen und wollte hieraus eine Wahl treffen:

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

Kein Firefox Password manager

Firefox schied aus, da ich zum Entsperren meinen Hardware Security Key verwenden und mir kein langes Hauptpasswort merken möchte. Dafür sprachen hingegen die sehr einfache Verwendung, das automatische Ausfüllen von Passwortfeldern und die Möglichkeit der Synchronisation, wenn auch über eine fremde Infrastruktur.

Kein Vaultwarden

Vaultwarden hatte ich lange im Visier. Es benötigt für den Betrieb im lokalen Netzwerk viele Vorbedingungen und Software drum herum, Stichworte HTTPS im LAN, ACME-Challenge. Daher ist im LAN ein eigener kleiner Rechner vorzusehen und idealerweise verfügt man sogar über einen virtuellen pricaten Server, der den HTTPS-Verkehr terminieren kann.

Dafür unterstützt Vaultwarden dann sogar die super bequeme Anmeldung per Passkey und kann die Passwortdatenbank zwischen allen Geräten im Netzwerk synchronisieren.

Doch am Ende scheute ich die aufwendige Einrichtung und die neuen Abhängigkeiten und Softwarepakete, die ich alle hätte zusätzlich warten müssen.

KeePassXC

Ich habe mit verschiedenen Varianten von KeePass herumgespielt und mich am Ende für KeePassXC entschieden. Das Gesamtpaket fühlt sich einfach runder und moderner an, ich kann die Software betriebssystemunabhängig nutzen und die benötigten Erweiterungen zur Verwendung mit HSKs sind auch gleich dabei.

Einrichtung von KeePassXC mit einem HSK

KeePass verwendet das keyed-hash message authentication code oder HMAC-Verfahren zum Entsperren der Passwortdatenbank unter Verwendung von Hardware Security Keys. Es basiert auf einem gemeinsamen geheimen Schlüssel, der bei beiden Parteien vorliegen muss, aber nicht zwischen den Parteien ausgetauscht wird.

Üblicherweise erstellt man den geheimen Schlüssel auf dem Hardware Security Key und kopiert ihn dann in die Eingabemaske von KeePassXC - aber der Reihe nach, denn der Vorgang hängt ein wenig vom verwendeten HSK ab.

Yubikey

Yubico hat eine Anleitung eigens für die Verwendung mit KeePass vorbereitet. Ein Yubikey hat zwei variabel verwendbare Slots, welche verschiedene kryptografische Funktionen unterstützen. In der Funktionsauswahl ist Challenge-response: program a challenge-response credential anzuwählen. Anschließend erzeugt der Yubikey einen 20-byte HEX code, welcher anschließend nach KeePassXC kopiert werden kann.

Wichtig dabei ist, dass der angezeigte Code später nicht mehr extrahiert werden kann. Soll die Datenbank also einen Zweitschlüssel bekommen (was anzuraten ist), so muss der Code notiert und anschließend ebenfalls im Zweitschlüssel hinterlegt werden.

Ich empfehle beim Yubikey, das Häkchen bei requires touch wegzulassen. Ansonsten muss man bei jeder Verwendung eines Passwortes den Yubikey berühren. Viel nerviger noch ist, dass für das Hinzufügen oder Ändern eines Passworteintrages ebenfalls ein Berühren des Schlüssels notwendig wird.

Nitrokey

Nitrokey sieht die Erzeugung des Geheimnisses als 20-byte base32 code vor. Er kann genau ein HMAC-Geheimnis aufbewahren. Auch Nitrokey hat eine Anleitung zum Hinterlegen des HMAC-Secrets für die Verwendung mit KeePassXC online. Wie bei Yubikey auch basiert diese Anleitung auf der Verwendung der App.

Kompatibilität Yubikey - Nitrokey

Idealerweise würde ich nun den auf dem Yubikey erzeugten Schlüssel auf dem Nitrokey hinterlegen oder umgekehrt. So hätte ich einen Zweitschlüssel und könnte mit beiden auf die KeePassXC-Datenbank zugreifen.

Doch oh weh, der Nitrokey akzeptiert das Geheimnis des Yubikey nicht:

Genau so verhält es sich, wenn ich ein mit dem Nitrokey erzeugtes Geheimnis auf dem Yubikey hinterlegen will:

Hierfür benötige ich Abhilfe. Ich erstelle also ganz pragmatisch eine zweite Passwortdatenbank. Beide sollen denselben Inhalt haben, verwenden aber verschiedene Schlüssel zum Öffnen. Später lerne ich, dass das gar nicht nötig ist; dennoch hier erstmal meine provisorischen Lösungen.

Holzweg A: Einträge aus der Datenbank klonen

Ich befülle die erste Datenbank mit Passwörtern, welche ich in Gruppen sortiere. Anschließend klone ich die Gruppe, öffne die zweite Datenbank und ziehe den Klon per drag-and-drop herüber.

Nachteile: Ich muss den Vorgang für jede Gruppe wiederholen, denn drag-und-drop für die root-Gruppe ist nicht vorgesehen. Bei jeder Änderung in Datenbank_yubikey muss ich Datenbank_nitrokey ebenfalls anpassen.

Das ist sehr anstrengend, wenn die Datenbank sich noch im Aufbau befindet.

Holzweg B: Die ganze Datenbank kopieren und HMAC updaten

Hierfür speichert man die HMAC-Secrets der beiden Hardware Security Keys im Passwortmanager ab. Bei einer Änderung der Datenbank fertigt man eine Kopie der Datenbankdatei an, öffnet sie und kopiert sich das Secret des jeweils anderen HSK. Nun klickt man auf Database->Database Security->Change Challenge-Response und gibt das Secret dort ein. Schon funktioniert die Datenbank mit dem anderen Schlüssel.

Nachteil: Manuelle Aktualisierung beider Datenbanken erforderlich. Jedes mal ist challenge-response neu einzurichten.

Lösung: Konvertieren des HMAC-Secrets

Ich fragte mich, ob ich für den Nitrokey zur Speicherung des HMAC-Geheimnisses für meinen Nitrokey auch die Kommandozeile statt der App verwenden kann. Kommanodzeilenanwendungen wie nitropy verfügen meist über mehr Optionen als ihr GUI-App-Pendant. Vielleicht kann ich damit das Kompatibilitätsproblem lösen. Hier der Link zur Installation von nitropy.

Auf der Suche nach einer geeigneten Dokumentation stoße ich auf diesen interessanten Post zum Thema challenge-response. Dort wird mir klar, was softwareaffine Leute schon lange wissen. Zumindest, falls sie entweder mal das Thema Kryptografie gestreift haben oder nahe an der Hardware unterwegs sind:

Daten der Größe von 20 Byte lassen sich in hex mit 40 Zeichen UND in base32 mit 32 Zeichen darstellen.

Folglich lässt sich ein HMAC-Geheimnis konvertieren und damit sowohl auf dem Yubikey als auch auf dem Nitrokey ablegen. Dafür verwende ich das kleine Werkzeug xxd und lasse mir aus dem Hexcode des Yubikey eine base32-Phrase für meinen Nitrokey erzeugen.

# 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

Alternativ funktioniert auch der Rückweg:

# 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: Passwörter schön geordnet hinterlegen

Verzichtet man wie ich auf Dialoge wie “mit Google einloggen” bei Drittanbietern, so sammeln sich im Laufe des Lebens unter Umständen eine Menge Passwörter an. Zum vereinfachten Finden und verwenden der Passwörter sowohl mobil als auch auf dem Desktop bietet es sich an, sinnvolle Gruppen zu erstellen.

Passwortfamilien

Nach ein paar Experimenten hat sich folgendes Schema für Titel bewährt, wenn ich mehrere verwandte Passwörter speichern möchte:

baseapp.attribute.specialization

So würde aus den Zugängen für mein gehärtetes Gitea-setup:

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

Auf diese Weise bleiben verwandte Passwörter schön beisammen.

Gruppierung

Ich halte folgende Gruppen von Passwörtern für sinnvoll:

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

Dabei achte ich darauf, nicht zu viele Untergruppen zu erstellen. Gerade in der Mobilansicht ist man sonst schnell verwirrt.

Icons 🔑

KeePassXC bietet die wunderbare Möglichkeit, Favicons der Zielwebsite herunterzuladen und als Symbol zu verwenden. Damit gelingt die Navigation im Passwortmanager noch einfacher.

Die Favicons sind allerdings alles Bitmaps. Möchte man hochqualitative Vektorgrafiken verwenden bietet sich an, unter “Choose Icon” den Pfad eines Icon Packs anzugeben. Ich habe mir dafür die Aegis icons heruntergeladen und bin damit sehr zufrieden.

Scheitern von SSH-Verbindungen

Schallbert — Fri, 12 Jun 2026

In diesem kurzen Artikel geht es um Fehler beim Aufbau einer SSH-Verbindung. Egal ob andere Rechner, Server oder Dienste wie Versionsverwaltung - die Fehlermeldungen und zugehörige Lösungen sind meist gleich. Weiterlesen lohnt sich allerdings nur, wenn gängige Hilfeseiten wie Githubs troubleshooting-ssh nicht die erwünschte Lösung brachte.

Problem: “No Route To Host”

Die Konsolenausgabe zeigt (im lokalen Netz):

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

Oder (in einem entfernten Netz)

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

Ursache ist sehr wahrscheinlich eine falsch eingegebene IP oder eine fehlgeschlagene DNS-Namensauflösung. Im lokalen Netz ist ein realistischer Grund, dass der Teilnehmer abgeschaltet ist und der Router ihn daher nicht erreichen kann. Abhilfe schafft meist eine Korrektur der Zieladresse, Einschalten des Ziels oder Update der Routing-Tabelle.

Problem: Connection Refused

Konsolenausgabe:

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

Hier kann nicht mal eine Verbindung zum Ziel hergestellt werden. Man ist also “vor” der Authentisierung schon gescheitert. Meiner Erfahrung nach werden solche Fehler aus drei Gründen erzeugt:

Der Host ist noch nicht bereit. Er bootet beispielsweise gerade (Netzwerkkarte ist an) aber der SSH-Dienst ist noch nicht hochgefahren. Hier hilft meist: abwarten.
Eine Firewall, ein Rate Limiter, oder Dienste wie fail2ban weisen die Verbindung ab (REJECT). Die Gründe hierfür sind meist zu viele erfolglose Anmeldeversuche oder eine fehlgeleitete Bot-Erkennung. In seltenen Fällen kann es aber auch sein, dass die eigene IP-Adresse auf einer “deny-list” auftaucht, die von den Zielen eingelesen wurde. Auch hier empfiehlt sich: warten.
Der angesprochene Dienst erwartet einen anderen Port als den SSH-Standard Port 22. Somit stimmen User/Ziel-Adresse/Port nicht überein.

Das Port-Problem lässt sich leicht lösen.

Herausfinden des “Listen Port” auf dem Host (Server Configuration / SSH). Auf dem Bild ist dargestellt, wie die Einstellung auf meiner Gitea-Instanz aussieht. Alternativ genügt meist ein Blick in die Konfigurationsdatei des entsprechenden Services.
Die SSH-Konfiguration unter ~./ssh/config mit einer konkreten Port-Nummer versehen. Beispiel:

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

Problem: Too Many Authentication Failures

Konsolenausgabe:

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

Wir haben nun also eine Verbindung zum Server 😁, aber der mag uns nicht reinlassen 😨. Immerhin wird mitgeteilt, warum: Er meint, wir hätten zu viele Schlüssel an seiner Haustür ausprobiert.

Server-Anmeldelimit prüfen

Dieser Fehler tritt auf, wenn das Server-Limit der Anmeldeversuche gerissen wird. Der Wert beträgt beim Service sshd beispielsweise standardmäßig MaxAuthTries = 6. Hat man viele Schlüssel für mehrere Verbindungen abgespeichert oder verwendet wie ich neuerdings Hardware Security Keys und legt Zweitschlüssel an (also ssh-keys.count*2), wird dieser Wert schnell überschritten.

Fies bei diesem Fehler ist außerdem, dass er nur bei bestimmten Services “unten” in des Agents Schlüsselbund auftritt: unter den ersten sechs dürfen ja fünf Schlüssel falsch sein. Zudem schützt einen nicht, wenn man die Schlüssel in der ~./ssh/config korrekt hinterlegt hat. Der Agent nimmt stets alle Schlüssel zum Probieren mit, wenn man es ihm nicht explizit verbietet.

Das Verbot erteilen wir per IdentitiesOnly yes. Hiermit wird dem Agent klar gesagt, dass er nur die für diesen Host explizit angegebenen Identities (Also Schlüsseldateien oder Nutzername/Passwort) verwenden soll.

# /.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

Git-Config überprüfen

Diesen Fehler bekommt man auch, wenn die Git-Konfiguration des Repository unter <reponame>/.git/config nicht mit dem in der SSH-Konfiguration ~/.ssh/config hinterlegten Datensatz für Server und Repository übereinstimmt. Ändert man die SSH-Konfiguration, so sind alle auf diesem Server bereitgehaltenen Repo-Konfigurationen ebenfalls zu ändern.

Beispiel:

# <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 diesem Falle wird die gitserver-Konfiguration gar nicht verwendet, sondern sich direkt einwählt. Dies führt dazu, dass der Agent kein IdentitiesOnly yes Flag mitgeliefert bekommt und er Schlüssel durchprobiert, bis der Server abwinkt. Lösung:

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

Problem: Permission Denied (publickey,password)

Konsolenausgabe:

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

Dieses Problem kann leider viele verschiedene Ursachen haben. Ein paar räumt Githubs Anleitung bereits aus dem Weg, darunter:

sudo verwendet
Falscher Server
nicht den git-user verwendet
Falschen Schlüssel verwendet (client)
Schlüssel nicht hinterlegt (server)

Die Ausgabe bei falschem Username sieht so aus:

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

Eine weitere Ursache kann eine fehlende Abstimmung zwischen der Konfigurationsdatei ~./ssh/config und dem im git client hinterlegten Remote-Adresse liegen. Sind diese nicht deckungsgleich, wird eine eventuell bestehende Konfiguration gar nicht erst benutzt.

Eine Überprüfung kann man mit git remote -v durchführen.

➜ 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)

Korrekt wäre mit der verbesserten Konfigurationsdatei (Ports eindeutig gesetzt, Identity Files definiert und auf die Angegebenen beschränkt):

# 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

Konsolenausgabe:

➜ 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

Diesen Fehler sehe ich erst, seitdem ich Hardware Security Keys für ssh verwende. Aus meiner Sicht kann er zwei Ursachen haben. Beide sind zum Glück leicht zu beheben:

Der Agent kennt den Schlüssel nicht. Der Befehl ssh-add löst das Problem. Prüfung per ssh-add -l | grep “<your-key’s-comment>”
Der angeforderte Schlüssel ist nicht da. Kann bei HSK und HSM passieren, falls sie nicht eingesteckt sind, nicht richtig auf dem NFC-Lesegerät platziert sind oder das HSM im Netzwerk nicht verfügbar ist. Oder wenn manuell im Verzeichnis ~./ssh/config gearbeitet wurde und der Schlüssel nun umbenannt oder gelöscht ist.

Hardware Security Key: SSH einrichten

Schallbert — Sun, 03 May 2026

Motivation

In meinem Post über Hardware Security Keys schrieb ich, dass ich möglichst viele meiner Verbindungen passwortlos mit meinem neuen HSK absichern möchte. Ich verwende SSH-Verbindungen für verschiedene Dienste und Zwecke: Ich greife auf meinen VPS zu, benutze Dienste wie Github, Gitea sowie meine eigene Gitea-Instanz und lasse die Erzeugung von Backups im lokalen Netz über scp laufen, welches das SSH-Protokoll verwendet.

SSH-Zugriff für Hardware Security Keys einrichten

HSKs wie mein Yubikey können private Schlüssel für SecureShell-Zugriffe abspeichern. Somit muss man sie nicht mehr lokal auf jedem Endgerät ablegen (das bleibt aber konfigurierbar, siehe unten). Zudem sind sie gegenüber der Verwahrung auf einem Rechner besser gegen unbefugte Zugriffe geschützt.

Also probiere ich aus, meinen Github-SSH-Zugriff auf HSK umzustellen und folge Yubicos Anleitung für passwordlose Authentisierung für Github. Das Verfahren zur Erzeugung von SSH-Schlüsseln nach FIDO unterscheidet sich für verschiedene Schlüsselhersteller nicht. Ich verlinke ebenfalls die Nitrokey-Anleitung als Referenz.

Was so nicht funktioniert

Doch mit den Empfehlungen von Yubico selbst komme ich auf meinem Betriebssystem und der Standardinstallation von openssh nicht zum Ziel. Das aus der Anleitung zusammengebaute Kommando lautet:

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

Nach Erstellung muss man den öffentliche Schlüssel (Dateiendung .pub) in der Web-Anwendung des jeweiligen Dienstes im Menüpunkt SSH-Zugang hinterlegen.

Bedeutung des Kommandos und der wichtigsten Optionen

Dieser Befehl¹ sagt der Anwendung ssh-keygen, dass sie mir einen Schlüssel des Typs -t ed25519-sk erzeugen soll. Die Endung -sk sagt aus, dass der Schlüssel auf einem Security Key - in meinem Fall dem Yubikey - gespeichert werden soll.

Um das Flag -O resident zu verstehen muss man wissen, dass FIDO Authenticator-Schlüssel wie mit -sk erzeugt aus zwei Teilen bestehen: Ein key handle Teil, welcher auf der Festplatte des Rechners verbleibt und der private Schlüssel selbst, welcher nur auf dem HSK existiert. Nur zusammen können sie Authentisierungsanfragen korrekt beantworten. Das Flag selbst weist jedoch an, beide Schlüsselteile auf den Yubikey zu schreiben. Das erleichtert die Verwendung mehrerer Geräte mit demselben Schlüssel: Der key handle-Teil kann vom Yubikey ausgelesen und auf anderen Endgeräten abgelegt werden. Auf der anderen Seite jedoch genügt nun das Verlorengehen des Yubikey allein, um möglichen Angreifern SSH-Zugriff zu geben.

-f filename legt Namen für die Schlüsseldateien fest. Macht besonders dann Sinn, wenn man mehrere SSH-Verbindungen oder HSM verwalten muss. Ich habe mir eine Konvention erstellt, um nicht durcheinander zu kommen. Diese orientiert sich stark an der Schreibweise des Schlüssel-Auslesens von einem HSK (ssh-keygen -K).

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

Als konkretes Beispiel würde mein Dateiname hier wie folgt lauten:

-f ed25519-sk_ssh:github_schallbert_yubikey-main

-C schallbert@github.com fügt der Schlüsseldatei selbst einen Kommentar hinzu, zum Beispiel eine Kontaktadresse. Somit bekommt der Schlüssel ein Label, was die Handhabung unter mehreren vereinfacht.

-O application=ssh:github dient nur der sauberen Auflistung im Authenticator-Programm und sorgt dafür, dass ich Schlüssel nicht miteinander verwechseln kann. Ansonsten steht dort nämlich nur ssh:keygen und ich kann nicht sehen, für welche Services ich Schlüssel hinterlegt habe. Außerdem hilfreich bei der Verwendung von -resident, da bei der Extraktion der Schlüssel mit ssh-keygen -K Unterscheidbarkeit gegeben bleibt.

-O user=schallbert hat für mich keinen praktischen Nutzen, da SSH dieses Flag nicht interessiert und der Yubikey Authenticator meinen Nutzernamen anders als erwartet nicht anzeigt.

-O no-touch-required vermeidet, dass der Hardware Security Key bei jeder Verwendung des Schlüssels berührt werden muss. Nützlich bei sehr häufiger Verwendung, allerdings Sicherheitsverlust durch Automatisierbarkeit.

-O verify-required sagt aus, dass die PIN des HSM abzufragen ist, bevor der Schlüssel genutzt werden kann. Eigentlich als zusätzliche Sicherheit gedacht, bekomme ich damit in meiner Shell jedoch Probleme. Und zwar wird die PIN einmal abgefragt, erzeugt aber vom ssh-agent nicht jedes mal eine Abfrage in meiner Konsole. Sobald ich in einer anderen Session versuche mich per SSH zu verbinden, erhalte ich eine Fehlermeldung 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).

Woran hat es gelegen?

Nach langer, frustrierender Fehlersuche (Was mache ich falsch? Funktioniert es mit dem Zweitschlüssel? Warum geht es beim ersten mal, danach aber nicht mehr? Was ist, wenn ich die Schlüssel erneut erstelle? Was passiert an anderen Rechnern? Was meint “KI” dazu? - Letzteres kostete bestimmt eine Stunde und ließ mich komplett auf der Stelle treten) probiere ich es mit einem anderen Kommando. Das funktioniert auf Anhieb.

Was hingegen funktioniert

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

Lasse ich verify-required weg, kann ich mich erfolgreich anmelden und der SSH-agent läuft sauber durch.

Was `verify-required` benötigt

Dieser Post im Forum superuser bringt für mein Fehlerbild Licht ins Dunkel. Die Terminal-Session mit der ich das SSH-Schlüsselpaar erstelle speichert die per verify-required Flag erzwungene Pin-Eingabe zwischen. Daher funktioniert der Login erst einmal. Logge ich mich später oder in einem anderen Fenster ein, wie ich es oben getan habe um z.B. git pull in einem meiner Repos zu prüfen, fragt der SSH-Agent meine PIN nicht ab.

Das liegt wohl daran, dass der SSH-Agent selbst keine Prompts an das anfragende Programm ausgeben kann. Abhilfe schafft ein Untermodul von Openssh: openssh-askpass. Dieses kann man dem Agent übergeben, welcher dann die PIN-Abfrage über askpass an den User übermittelt.

Installation von ssh-askpass

Mein Betriebssystem hatte ssh-askpass nicht installiert, daher hole ich das hier nach. Es verwendet den Paketmanager DNF “Dandified YUM” statt apt oder anderer gängiger Manager. Dabei ist die Namensgebung meiner Meinung nach nicht 100% einheitlich, spreche ich den ssh-Programme doch im Terminal mit ssh-agent an, muss jedoch openssh-agent tippen für die Installation.

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

Nun will ich dem Agent mitteilen, dass er ssh-askpass zum Erfragen der PIN ansprechen kann. Dafür mus ich wissen, in welchem Pfad sich das Submodul befindet.

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

Komisch, aber ich hatte es doch installiert! Frage ich mal den Paketmanager:

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

Aha, openssh versteckt sich im Ordner libexec. Na dann kann ich das Modul jetzt dem Agent bekanntgeben.

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

Ich prüfe die Verbindung zu Github und bekomme wie gewünscht einen Dialog angezeigt, der meine PIN abfragt. Anschließend muss ich den HSK noch berühren und bekomme dann die Erfolgsmeldung. Damit das alles auch in einem neuen Terminal und nach Neustart des Rechners funktioniert, füge ich eine Referenz auf den Schlüssel in meine Konfigurationsdatei ein.

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

Um auf Nummer sicher zu gehen, den Agenten neustarten und neue Terminalsessions erstellen. Sollten Zugangsdaten im Cache gewesen sein, ist das hiermit zurückgesetzt. Anschließend erneut die SSH-Verbindung testen.

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

Einziger Wehrmutstropfen ist, dass ich jetzt beim Verbinden mit SSH ein zusätzliches Popup bekomme. Das wird durch die grafische Nutzeroberfläche gnome ausgelöst. Leider finde ich keine Option, die zugehörige Einstellung permanent speichern. Somit wird es bei jeder Verbindung mit verify-required angezeigt. Bei Gnome wird ist das Problem bereits für andere Anwendungen bekannt, anscheinend aber noch nicht abgestellt.

Übertragung auf Windows-Systeme

Ich habe meine Schlüssel ja mit der Option -O resident erzeugt. Da liegt es nahe, die Extraktion des key-handle mal auf einem komplett anderen System zu testen: Windows.

Ich öffne die Kommandozeile und tippe

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? Im Netz steht öfters geschrieben, dass die Schlüssel manchmal am Ende noch ein LineFeed-Zeichen benötigen um richtig erkannt zu werden. Ohne Download vom HSK kann ich sie aber nicht modifizieren. Also übertrage ich öffentlichen Schlüssel und key-handle manuell auf den Rechner und probiere testweise das git pull-Kommando aus. Und siehe da: Es klappt!

Möchte man also die Schlüssel mit verschiedenen Betriebssystemfamilien verwenden, nutzt die Option -resident anscheinend nichts. Der Befehl ssh-keygen -K ist nicht granular steuerbar: Er lädt alle auf dem HSK befindlichen resident keys herunter.

VPS: Vorsicht bei Schlüssel-Ersatz

Noch ein Hinweis aus eigener Erfahrung: Hat man bereits SSH-Schlüssel hinterlegt bei einem Dienstanbieter, der selber Ressourcen bereitstellt (In meinem Fall einen Server als VPS) so werden neue SSH-Schlüssel meist nicht über das Web-Frontend an diese Ressource weitergereicht.

Die “alten” Schlüssel werden folglich weiterhin benötigt und die Neuen nicht verwendet, obwohl sie in der Web-App abgelegt sind!

Die neuen Schlüssel müssen dem Ziel manuell bekanntgemacht werden.

Das führe ich der Anleitung von meinem Hoster Hetzner folgend mit dem Befehl ssh-copy-id aus.

Neue Schlüssel manuell auf VPS ablegen

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

Dabei ist server der SSH-Alias für meinen VPS. Ich verbinde mittels des bekannten, “alten” Schlüssels lasse den “Neuen” ablegen. Doch irgend etwas funktioniert nicht wie erwartet:

/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)

Schlüssel erfolgreich übertragen?

Ich logge mich also auf meinem Server ein und prüfe, ob der neue Schlüssel tatsächlich in der ~/.ssh/authorized_keys Datei auftaucht. Tut er nicht. Also führe ich das obige Kommando erneut aus, diesmal mit aktivierter -f (Force) Option. Und tatsächlich, die Übertragung klappt!

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.

Zum Testen wie empfohlen nun mit dem neuen Schlüssel einloggen und… Läuft! Erst jetzt können die alten Schlüssel sicher gelöscht werden: shred -u <path/to/private/key>

Auf direktem Wege ohne ssh-copy-id

Will man den neuen Schlüssel ohne zusätzliche Werkzeuge bekannt machen, so kann man den Inhalt der öffentlichen Schlüsseldatei <key-filename>.pub auch direkt selbst in eine neue Zeile von ~/.ssh/authorized_keys schreiben. Dafür benötigt man lediglich eine offene SSH-Verbindung zum Ziel.

Überlegungen zu Komfort und Bedienbarkeit

Wenn ich mir meine SSH-Verbindungen so ansehe, dann teilen sie sich grob in zwei Kategorien:

Admin-Zugänge (VPS, NAS, Raspberry Pi) und Signaturen
Protokoll-Zugänge (Git etc.)

Erstere erfordern aus meiner Sicht ein höheres Sicherheitsniveau. Zudem nutze ich sie nicht so häufig wie Versionsverwaltungen. Daher empfehle ich für die erste Kategorie verify-required und würde dies bei der Zweiten weglassen. Mit der Option no-touch-required würde ich ebenso verfahren: falls alle paar Minuten ein Commit hochgeladen werden soll, werden ständige Berührungen des Schlüssels schnell irritierend.

Alle Optionen bekommt man bei Aufruf des Handbuchs per man ssh-keygen angezeigt. ↩︎

Hardware Security Keys

Schallbert — Sat, 25 Apr 2026

Begriffsabgrenzung: TPM und HSK

Akronym	Bezeichnung	Kurzbeschreibung
TPM	Trusted Platform Module	Fest verbaut. Schützt das Gerät selbst
HSK	Hardware Security Key	Mobil. Schützt Konten, Zertifikate, private Schlüssel

Das Trusted Platform Module ist ein Sicherheitschip, der kryptografische Schlüssel sicher speichert und Funktionen wie Secure Boot, BitLocker-Verschlüsselung und Geräteidentität bereitstellt. Er ist fest auf der Hauptplatine eines Computers oder Smartphones verlötet.

Ein Hardware Security Key HSK, Hardware-Sicherheitsschlüssel hingegen ist meist mobil und kann mit verschiedenen Geräten verbunden werden. Es kann Schlüssel nicht nur speichern, sondern meist auch kryptografische Operationen (Schlüsselgenerierung, Signatur, Verschlüsselung) ausführen. HSKs sind hochsicher und manipulationsgeschützt konstruiert. Sie können extern zertifiziert bzw. auditiert sein, sodass auch hochsensible Vorgänge wie Zahlungstransaktionen ausgeführt werden können.

Was bisher geschah

Ich hörte einen Podcast vom Bundesamt für Sicherheit in der Informationstechnik (BSI) zum Thema “Passkey statt Passwort”. Den Empfehlungen folgend habe ich mir ein mobiles Hardware-Sicherheitsmodul (HSM) gekauft, um in Zukunft Passkeys für meine Dienste zu verwenden. Schon lange bin ich nicht mehr glücklich mit meiner fragmentierten Geheimnisverwaltung aus Zetteln, Browser-Plugins, offline-Passwortmanagern wie KeePass, auf Festplatte abgelegten SSH-Schlüsseln, Backup-Keys und Notfallcodes diverser Anbieter.

Ich möchte endlich mal Ordnung in die Landschaft bringen, ohne mich an einen kommerziellen Anbieter so fest zu binden, dass ich von ihm abhängig werde.

Zielvorstellung

Keine Passwörter oder Login-Daten mehr merken müssen
Möglichst einfache, dabei sichere Verwaltung von Passwörtern aufbauen
Ordnung in den Accountwust bringen
Digitalen Nachlass regeln
Anderen ermöglichen, es mir gleichzutun

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.

Vielmehr lässt sich die Passwortverwaltung mit Hilfe eines Hardware-Sicherheitsschlüssels aber zentralisieren und vereinfachen, da gängige Passwortmanager z.B. Passkeys unterstützen und so kein “Masterpasswort” mehr nötig ist.

Yubikey

Als HSK nutze ich zwei Yubikey Schlüsselanhänger. Einen zum immer dabeihaben und einen als Zweitschlüssel, welcher an einem sicheren Ort verwahrt wird. Es gibt noch andere Anbieter mobiler Hardware Security Keys wie Nitrokey. Die kannte ich vor Verfassen dieses Artikels noch nicht. Das ist bedauerlich, ist ihr Produkt doch quelloffen und damit idealer Testkandidat für mein Blog 😥.

Yubico Authenticator

Das GUI-Programm “Yubikey Authenticator” ist nützlich zum Einrichten, Belegen der Funktionstaste (z.B. Bestätigung oder Passwortausgabe als Tastatursimulation) und falls man 2FA-Einmalkennwörter z.B. als TOTP erzeugen will. Außerdem unterstützt mein Yubikey PKI, sodass man dort unter anderem auch SSL-Zertifikate und private Schlüssel geschützt ablegen kann.

Konzept des HSK

Dabei gehört es zum Konzept, dass private Schlüssel entweder direkt auf dem Hardware-Schlüssel erzeugt werden oder - ohne sie lokal dauerhaft zu speichern - zwar auf einem Endgerät erstellt, aber auf dem Yubikey abgelegt werden. Diese verbleiben auf dem Schlüssel und sind nicht exportierbar. Er unterstützt gängige asymmetrische Verfahren wie RSA und ECDH. Für Details siehe z.B. diese BSI-Publikation über kryptografische Verfahren. Außerdem wird der Schlüssel die meiste Zeit offline, also ohne Energieversorgung herumliegen und dadurch kaum angreifbar sein. Eine zusätzliche Pin als Schutzmaßnahme bei Verlust des Schlüssels ist ein weiterer Sicherheitsfaktor.

Zweitschlüssel

Dennoch sollte man sich notieren, welche Zugänge man mit welchem Verfahren schützt, damit die richtigen Accounts im Falle des Verlustes gesperrt werden können. Ein “Zweitschlüssel” sollte vorhanden und belegt sein, was fast genauso zeitaufwendig ist wie den Hauptschlüssel zu konfigurieren.

NFC

Von der NFC-Unterstützung meines Schlüssels hatte ich mir erhofft, Logins noch schneller und leichter hinter mich bringen zu können. Zwei Dinge hier stören mich jedoch: Meinen Laptop kriege ich partout nicht dazu, den Yubikey per NFC zu erkennen. Und auf dem Handy funktioniert die NFC-Erkennung höchstens mittelmäßig. Halte ich den Schlüssel dran, startet die App und bittet mich um Eingabe der Pin. Tue ich dies, muss ich den Schlüssel wieder entfernen und erneut an den Sensor halten “Schlüssel nicht bewegen!”. Das funktioniert längst nicht jedes mal und wirkt insgesamt ziemlich störanfällig. Schade.

Was mir beim Umgang mit Yubikey fehlt

Insgesamt vermisse ich ein paar Komfort-Funktionen beim alltäglichen Umgang mit dem Yubikey. Bei Klick auf die gewünschten Schlüssel oder Accounts passiert nämlich nichts. Und konfigurieren kann ich da anscheinend auch nichts.

Bei der Verwendung von Passkeys würde ich mir eine Verknüpfung wünschen. Ein Klick auf den entsprechenden Schlüssel im Authenticator sollte die entsprechende App bzw. das Browserfenster mit der Zielwebsite aufrufen. Da ich das HSK zu diesem Zeitpunkt bereits mit der PIN entsperrt habe, kann sogar der Anmeldevorgang nach Berührung des Schlüssels vollautomatisch stattfinden.

Ähnliches wünsche ich mir beim Umgang mit Accounts. Warum heißt das Modul “Accounts”, wenn ich meine Konten nicht direkt darüber aufrufen kann? Auch hier muss ich die entsprechenden WebApps etc. selbst öffnen, den Passwortmanager am Start haben und dann noch die 2FA-Codes vom Authenticator herauskopieren. Das geht bestimmt einfacher.

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

Je nach Modul gibt es auch bei der Verwendung des Yubikey zumeist eine Mehr-Faktor-Authentisierung. Das unkomplizierteste Verfahren ist eine Anwesenheitserkennung über eine Berührung des Sticks. Damit kann sichergestellt werden, dass eine Person das HSK aktiv bedient und nicht etwa automatisch eingeloggt werden kann. Touch kann modulübergreifend angewendet werden; zur Detailkonfiguration komme ich in meinem Artikel über SSH.

Das Accounts-Modul kann optional mittels Passwort, das Passkeys-Modul per PIN gesichert werden. Manche Anbieter verlangen die Einrichtung einer PIN als zweiten Faktor sogar.

Das Certificates-Modul muss mit PIN, und PUK und Management Key vor unbefugtem Zugriff gesperrt werden. Private Schlüssel oder Zertifikate können optional zusätzlich mit einer Passphrase ausgestattet werden, was die Schlüssel selbst schützt (und aus meiner Sicht für den Yubikey keinen Sinn macht, da die privaten Schlüssel ohnehin nicht auslesbar sind).

Funktionsumfang und kryptographische Landschaft

Da das HSK einen so großen Sicherheitsgewinn verspricht, möchte ich natürlich möglichst viele seiner Fähigkeiten nutzen. Ich habe jetzt ein paar Wochen mit den verschiedenen Modulen herumgespielt und muss feststellen, dass man sich ganz schön hineindenken und viel lernen muss, um alle gut nutzen zu können. Immerhin versteht man danach ungefähr was die Module tun und bekommt einen guten Überblick zu den Themen Internet-Sicherheit, Verschlüsselungsverfahren und -Protokolle.

“Accounts” und “Passkeys” sind für Eingabemasken (Plattformen, Webseiten, Shops) und Apps (Mailer, Passwortmanager, Messenger) einfach einzurichten: Absolut empfehlenswert! - schallbert

Yubikey-Modul	Beschreibung
Accounts	Verwaltung von Konten/Anmeldungen, unterstützt TOTP
Passkeys	Passwortloses Anmeldeverfahren durch FIDO/WebAuthn (Public-Key-Credential)
Certificates	Speicherung und Nutzung von Zertifikaten; unterstützt OpenPGP (PGP) und X.509 (PIV)
Slots	Zwei programmierbare Slots zur Ausgabe statischer Passworte oder Einmalkennwörter

Kompliziert und aufwendig wird es meiner Meinung nach mit Public/Private Keys und Zertifikaten. Erzeugungs- und Validierungsverfahren hängen vom Betriebssystem oder darauf verfügbaren Programmen ab und Anleitungen greifen teils zu kurz oder widersprechen sich: Nur für Nerds oder Profis. - schallbert

Gehen wir die Module mal durch.

2-Faktor-Authentisierung “Yubikey: Accounts”

Der Yubikey kann als Generator für zeitbasierte Einmalkennwörter dienen. Dafür legt man wie in jeder anderen Authenticator-App auch pro Dienst ein Konto an und übergibt einen Sicherheitsschlüssel (Geheimnis, Secret) an den Yubikey. Auf Basis dieses Geheimnisses können bei angestecktem HSK nun Einmalcodes erzeugt werden.

Da es keine Möglichkeit gibt, diese “Secrets” vom Yubikey zu exportieren, muss der Vorgang für Zweitschlüssel wiederholt werden. Doch nicht jeder Anbieter sieht die Nutzung mehrerer Authentikatoren vor. Also kann es sinnvoll sein, das Geheimnis in der Zwischenablage¹ zu halten und ihn bei der Konfiguration des/der Zweitschlüssel wiederzuverwenden.

Passkeys “Yubikey: Passkeys”

Das Passkey-Modul meines Yubikey funktioniert recht gut. Viele Services² unterstützen die passwortlose Anmeldung leider noch nicht oder akzeptieren Passkeys nur als zweiten Faktor. Bei anderen Services³ kann ich das Passwort nicht deaktivieren, sodass ich kaum einen Sicherheitsgewinn sehe oder mir werden Backup-Codes ausgegeben, die im Notfall als zweiter Faktor dienen sollen⁴. Immerhin, ich kann durch den Passkey jetzt bei einigen Diensten die Passwort-TOTP-Anmeldung umgehen und bin schneller eingeloggt.

“Die wohl größten Vorteile der Technologie für Nutzerinnen und Nutzer liegen darin, dass Sie in Zukunft zum einen keine Passwörter mehr erstellen und verwalten müssen. Zum anderen sind Passkeys immun gegen die breite Masse bekannter Phishing-Angriffe.” - BSI-Website, Oktober 2025

Die Authenticator-App braucht man nicht zur Konfiguration von Passkeys. Dies läuft komplett im Browser oder der Kommandokonsole ab. Beide müssen das Handling von Passkeys unterstützen.

Keys & Certificates “Yubikey: Certificates”

Um hier etwas Licht hineinzubringen, müssen wir uns erst einmal den Unterschied zwischen Schlüsselpaar und Zertifikat im Kontext der Authentisierung vor Augen führen. In beiden Fallen geht es darum, die Identität des Client zu verifizieren. Vor einem Server (z.B. per SSH), einer Institution (z.B. einer Certificate Authority) oder einem anderen Client (z.B. per PGP). Somit wird für das Ziel feststellbar, dass es sich tatsächlich um den zur Verbindung berechtigten Client handelt.

Public/Private Key Pair

Das reine Schlüsselpaar (also kein Zertifikat) wird üblicherweise dann verwendet, wenn das Ziel der Kommunikation im Besitz desjenigen ist, der auch über den Client verfügt. Dann nämlich kann der Client zum Aufsetzen der Verbindung den öffentlichen Schlüssel auf dem Host platzieren. Dieses Verfahren wird z.B. bei Einrichten von SSH-Verbindungen und für einige APIs wie bei der Search Console verschiedener Suchmaschinenanbieter angewendet.

Der Host kann dem Client mit dem öffentlichen Schlüssel verschlüsselte Testnachricht schicken, welche nur mit dem zugehörigen privaten Schlüssel wieder in Klartext umgewandelt werden kann. Schickt der Client den korrekten Klartext zum Host zurück, ist für den Host bewiesen, dass der Verbindungspartner authentisch ist.

Certificates / PIV

Doch was, wenn der Host nicht unter der Kontrolle des Clients steht? Wie soll dann sichergestellt werden, dass sich weder Client noch Server für jemand anders ausgibt und einen gefälschten öffentlichen Schlüssel hinterlegt? Genau da kommen Zertifikate zum Einsatz.

Vereinfacht gesagt enthält das Zertifikat nicht nur den öffentlichen Schlüsselteil, sondern zusätzliche Informationen über den Netzteilnehmer und die gewünschte Verbindung. Nun kommt eine vertrauenswürdige, an der Kommunikation zwischen Client und Server unbeteiligte dritte Partei ins Spiel. In der Private Key Infrastructure PKI nennt man sie Certificate Authority CA.

Der Netzteilnehmer sendet nun den öffentlichen Schlüssel samt Metadaten über sich selbst an die CA und stellt einen sogenannten CSR, einen Certificate Signing Request. Die CA prüft nun, ob der Kanal des Teilnehmers auch wirklich diesem gehört.

Bei einer E-Mail (Stichwort PGP/GPG) kann die CA beispielsweise einen aus dem Public Key errechneten Hash-Link an die angegebene Mailadresse versenden. Wird der Link geklickt, beweist dies der CA gegenüber, dass die Mailadresse tatsächlich dem Client gehört und sie kann das Zertifikat ausstellen, den CSR also mit ihrem privaten Schlüssel signieren.

Bei Domains (Stichwort SSL/TLS) kann die CA beim Domain Name Service DNS-Anbieter prüfen, ob die Angaben zur Anfrage des Servers passen.

Clients haben die Signaturen gängiger Certificate Authorities eingespeichert (z.B. im Browser). Wird das Zertifikat auf dem Rückweg zwischen Server und Client manipuliert, verändert sich der Hashwert und der Client spuckt eine Zertifikatswarnung aus: “invalid certificate”. Jetzt muss man jedoch den Certificate Authorities vertrauen⁵ 🙃

Der Rechner sollte dafür offline sein. Wenn man supersicher sein will, macht man das Anlernen auf einem Live-Betriebssystem. Das bootet üblicherweise von einem USB-Stick und hat nach dem Herunterfahren alles vergessen. ↩︎
Z.B. Gar nicht: Mailbox, 2FA: Discord und Kraken, zum Zeitpunkt Apr-26. Vielleicht habe ich aber auch nicht die richtigen Einstellungen gefunden? ↩︎
Z.B. Google, Github und Hetzner, zum Zeitpunkt Apr-26. ↩︎
Auch diese Backup-Codes müssen sicher abgelegt werden. Idealerweise wieder offline, unbedingt aber unabhängig vom HSK. ↩︎
Es gibt Alternativen zu Institutionen wie CAs, siehe Web of Trust. So kann die Verifikation der Identität beispielsweise auch peer-to-peer von unbeteiligten Dritten stattfinden. ↩︎

Hardware Security Key on Schallberts Blog

Passwortmanager mit Security Keys verwenden

Der Passwortmanager

Kein Firefox Password manager

Kein Vaultwarden

KeePassXC

Einrichtung von KeePassXC mit einem HSK

Yubikey

Nitrokey

Kompatibilität Yubikey - Nitrokey

Holzweg A: Einträge aus der Datenbank klonen

Holzweg B: Die ganze Datenbank kopieren und HMAC updaten

Lösung: Konvertieren des HMAC-Secrets

KeePassXC: Passwörter schön geordnet hinterlegen

Passwortfamilien

Gruppierung

Icons 🔑

Scheitern von SSH-Verbindungen

Problem: “No Route To Host”

Problem: Connection Refused

Problem: Too Many Authentication Failures

Server-Anmeldelimit prüfen

Git-Config überprüfen

Problem: Permission Denied (publickey,password)

Problem: Agent Refused Operation

Hardware Security Key: SSH einrichten

Motivation

SSH-Zugriff für Hardware Security Keys einrichten

Was so nicht funktioniert

Bedeutung des Kommandos und der wichtigsten Optionen

Woran hat es gelegen?

Was hingegen funktioniert

Was verify-required benötigt

Installation von ssh-askpass

Nervig: Gnome-Popup “Allow inhibiting shortcuts”

Übertragung auf Windows-Systeme

VPS: Vorsicht bei Schlüssel-Ersatz

Neue Schlüssel manuell auf VPS ablegen

Schlüssel erfolgreich übertragen?

Auf direktem Wege ohne ssh-copy-id

Überlegungen zu Komfort und Bedienbarkeit

Hardware Security Keys

Begriffsabgrenzung: TPM und HSK

Was bisher geschah

Zielvorstellung

Yubikey

Yubico Authenticator

Konzept des HSK

Zweitschlüssel

NFC

Was mir beim Umgang mit Yubikey fehlt

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

Funktionsumfang und kryptographische Landschaft

2-Faktor-Authentisierung “Yubikey: Accounts”

Passkeys “Yubikey: Passkeys”

Keys & Certificates “Yubikey: Certificates”

Public/Private Key Pair

Certificates / PIV

Was `verify-required` benötigt