drduh/YubiKey-Guide: GnuPG- und SSH-Schlüssel auf Hardware auslagern
drduh/YubiKey-Guide bietet eine praxistaugliche Open-Source-Implementierung mit stabiler Einsatzbarkeit für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Wie der Community-Leitfaden von drduh die Einrichtung eines YubiKey für GnuPG und SSH Schritt für Schritt abdeckt, von Debian Live bis zum Touch-Modus.
- Für wen ist es gedacht?
- Der Leitfaden eignet sich für Nutzer, die GnuPG- und SSH-Private Keys physisch sichern wollen und bereit sind, dafür eine isolierte Umgebung mit Debian Live aufzubauen. Wer nur eine schnelle Zwei-Faktor-Lösung ohne OpenPGP sucht, wird mit Security-Key-Modellen nicht bedient.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 7 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich HTML, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
YubiKey-Guide: Hardware-Krypto für GnuPG und SSH verstehen
drduh/YubiKey-Guide ist ein Community-Leitfaden, der zeigt, wie Zugangsdaten auf einem YubiKey gespeichert werden. Das Kernversprechen: Die privaten Schlüssel lassen sich nicht mehr vom Gerät herauskopieren. Ergänzend bleibt ein separater offline aufbewahrter Certify-Schlüssel bestehen, der nur zum Ersetzen oder Erneuern der Schlüssel verwendet wird.
Das Repository ist in HTML geschrieben, steht unter der MIT-Lizenz und liegt laut Metadaten bei über 12450 Sternen und 1249 Forks mit nur 10 offenen Issues. Eine gerenderte Fassung gibt es unter drduh.github.io/YubiKey-Guide. Wichtig für die Hardware-Auswahl: Nur Modelle mit OpenPGP-Anwendung funktionieren mit dieser Anleitung. YubiKey Security Key und YubiKey Bio enthalten diese Anwendung nicht und sind laut README ungeeignet.
Der Leitfaden wendet sich an Leser mit Bereitschaft zu handwerklicher Sorgfalt: Signaturprüfungen, temporäre GnuPG-Home-Verzeichnisse und getrennte Backup-Medien gehören zum vorgesehenen Ablauf. Bequemlichkeit steht nicht im Zentrum, sondern Kontrolle über die eigenen Schlüssel.
Sichere Umgebung: Debian Live, Signaturprüfung und die dd-Warnung
Ein ganzer Abschnitt widmet sich der Wahl der Umgebung für die Schlüsselerzeugung. Die README ordnet Optionen vom fremden Computer über virtualisierte Systeme bis zum luftabgeschirmten Gerät ohne Netzwerk. Für die meisten Leute gilt Debian Live von USB gebootet als praktische Basis, während Coreboot-Firmware oder ein ARM-basiertes Raspberry-Pi-Setup die harten Enden der Skala markieren.
Der Weg dorthin ist vollständig bebildert: Mit curl werden SHA512SUMS, deren Signatur und das 64-Bit-XFCE-Live-ISO geladen, anschließend der Debian-Signaturschlüssel über hkps://keyring.debian.org empfangen oder aus dem Verzeichnis pubkeys importiert, und mit gpg --verify SHA512SUMS.sign SHA512SUMS geprüft. Der Hash-Vergleich läuft über grep $(sha512sum debian-live-*-amd64-xfce.iso) SHA512SUMS.
Zum Schreiben des Images nutzt der Leitfaden sudo dd if=debian-live-*-amd64-xfce.iso of=/dev/sdc bs=4M status=progress ; sync, mit einer ausdrücklichen Warnung: Der dd-Befehl überschreibt das gewählte Gerät vollständig, der Gerätepfad ist vorher zu kontrollieren. Für OpenBSD gibt es eine Variante mit doas und of=/dev/rsd2c. Zusätzlich empfiehlt die README, mindestens zwei USB-Laufwerke für verschlüsselte Offline-Backups an unterschiedlichen Orten bereitzuhalten und den YubiKey vorab unter yubico.com/genuine auf Echtheit zu prüfen.
Certify-Schlüssel, Subkeys und verschlüsselte Offline-Backups
Die Schlüsselerstellung startet in einem temporären GnuPG-Home-Verzeichnis mit einer empfohlenen gpg.conf, die AES256 und SHA512 wählt, Kommentar- und Versionsheader abschaltet und no-symkey-cache setzt. Zuerst entsteht der Certify-Schlüssel ohne Ablaufdatum, danach drei Subkeys für Signieren, Verschlüsseln und Authentifizierung mit selbst gewählter Laufzeit. Nach jeder Erzeugung erfolgt eine Verifikation der Schlüssel, bevor etwas auf die Hardware übertragen wird.
Für die Passphrase empfiehlt der Leitfaden ein Muster aus Großbuchstaben und Ziffern, weil es sich leicht von Hand notieren lässt, und liefert eine druckbare Vorlage dafür. Das Backup folgt demselben Ansinnen: Die geheimen Schlüssel werden auf verschlüsselte Datenträger exportiert, unter Linux mit LUKS, unter OpenBSD mit bioctl. Die README nennt mindestens zwei Backups auf getrennten tragbaren Geräten und erwähnt Paperkey für eine physische Papierkopie.
Erst wenn diese Grundlage steht, rückt der YubiKey selbst in den Mittelpunkt. Diese Reihenfolge ist kein Selbstzweck: Wer die Schlüsselerzeugung auf dem Alltagsrechner durchführt, kann die spätere Hardware-Sicherung teilweise konterkarieren.
PIN-Änderung, Kartenattribute und Transfer der Subkeys
Beim Konfigurieren des YubiKey erklärt der Leitfaden zuerst die Standard-PINs der OpenPGP-Anwendung: 123456 für den Benutzer und 12345678 für den Admin-Bereich. Beide sind sofort zu ändern. Die Warnung dazu ist deutlich: Drei falsche Benutzer-PIN-Versuche sperren die PIN, drei falsche Versuche bei der Admin-PIN oder beim Reset-Code zerstören die Kartendaten.
Als nächstes setzt die Anleitung ein zufälliges, nicht identifizierbares Login-Attribut, denn die Kartenmetadaten sind ohne Authentifizierung lesbar. Der Transfer jedes Subkeys erfolgt über gpg --edit-key, gefolgt von einer Kontrolle mit gpg -K: Die Ausgabe zeigt ssb>, um anzuzeigen, dass der private Schlüssel nun auf der Karte liegt und das System keine nutzbare Kopie mehr besitzt.
Damit ist die Grundkonfiguration abgeschlossen, und der YubiKey übernimmt die Rolle, die vorher die Festplatte hatte: Träger der geheimen Schlüssel, aber ohne Möglichkeit, diese auszulesen. Wer mehrere YubiKeys betreibt, findet dafür einen eigenen Abschnitt mit Hinweisen zur parallelen Nutzung.
Alltag mit dem YubiKey: Signieren, Verschlüsseln, SSH und Touch-Modus
Für den täglichen Gebrauch behandelt die README das Importieren des öffentlichen Schlüssels, das Setzen von ultimativer Trust sowie Befehle zum Verschlüsseln, Entschlüsseln und Signieren. Für SSH konfiguriert der Leitfaden gpg-agent als SSH-Agent, exportiert den öffentlichen SSH-Schlüssel und zeigt mit IdentitiesOnly und IdentityFile, wie eingeschränkt wird, welcher Schlüssel einem Server angeboten wird. Plattformspezifische Abschnitte decken macOS, Windows und WSL ab, inklusive launchd-PLIST-Dateien und PuTTY-Unterstützung.
Ein eigener Abschnitt gilt dem Touch-Modus: Mit ykman openpgp keys set-touch wird verlangt, dass Signatur-, Verschlüsselungs- oder Authentifizierungsoperationen eine physische Berührung erfordern. Der YubiKey blinkt laut README, während er auf die Berührung wartet. Diese Kombination aus physischer Präsenz und Hardware-Schlüssel schließt die Lücke, die ein rein softwarebasiertes Setup offen lässt.
Auch die Agent-Weiterleitung wird ausführlich behandelt, sowohl über ssh-agent als auch über S.gpg-agent.ssh, mit Varianten für verkettete Weiterleitung und ältere Distributionen. Für E-Mail gibt es Abschnitte zu Thunderbird, Mailvelope und Mutt, dazu Hinweise zu Keyservern.
Fazit: Wartung, Reset und die Grenzen des Leitfadens
Der Schluss des Leitfadens behandelt das Langzeitthema: Subkeys lassen sich erneuern oder rotieren, der YubiKey selbst lässt sich zurücksetzen, und optionale Härtungsschritte wie verbesserte Entropie, die Aktivierung von KDF und Netzwerküberlegungen runden das Bild ab. Troubleshooting-Hinweise und alternative Lösungen zeigen, dass der Autor auch die Fälle bedenkt, in denen etwas schiefgeht.
Die MIT-Lizenz erlaubt breite Nutzung, bietet aber keine Gewährleistung. Der Leitfaden ersetzt keine Sicherheitsberatung für konkrete Organisationen und trifft keine Aussagen über die Sicherheit einzelner YubiKey-Modelle; er dokumentiert einen bewährten Ablauf mit überprüfbaren Befehlen.
Geeignet ist das Projekt für alle, die SSH- und GnuPG-Schlüssel ernsthaft schützen wollen und die Zeit investieren, Debian Live zu booten und die Signaturprüfung mit gpg --verify tatsächlich durchzuführen. Ungeeignet ist es, wenn ein Security-Key-Modell ohne OpenPGP vorliegt oder wenn eine Anleitung mit grafischem Installer erwartet wird. Wer den Ablauf einmal durchlaufen hat, besitzt ein Setup, bei dem der Verlust eines Rechners die Schlüssel nicht mehr gefährdet.
Redaktionelles Fazit
Der Leitfaden eignet sich für Nutzer, die GnuPG- und SSH-Private Keys physisch sichern wollen und bereit sind, dafür eine isolierte Umgebung mit Debian Live aufzubauen. Wer nur eine schnelle Zwei-Faktor-Lösung ohne OpenPGP sucht, wird mit Security-Key-Modellen nicht bedient. Prüfe zuerst, ob dein YubiKey-Modell die OpenPGP-Anwendung enthält, und arbeite dann die README-Abschnitte in der vorgesehenen Reihenfolge durch.
Community-Notizen