SSH-Zugänge gehören zu den sensibelsten Anmeldewegen in einer IT-Infrastruktur. Administratoren, Entwickler und DevOps-Teams verwenden Secure Shell täglich für den Zugriff auf Linux-Server, Cloud-Systeme, Netzwerkgeräte, Git-Repositories und andere kritische Systeme. Entsprechend wichtig ist der Schutz der verwendeten SSH-Schlüssel.
Ein YubiKey kann dabei einen entscheidenden Unterschied machen: Statt einen besonders sensiblen privaten SSH-Schlüssel ausschließlich als Datei auf einem Notebook zu speichern, kann die Authentifizierung an einen physischen Hardware-Sicherheitsschlüssel gebunden werden.
Für Unternehmen entsteht damit eine interessante Möglichkeit, privilegierte SSH-Zugänge stärker gegen den Diebstahl von Zugangsdaten und privaten Schlüsseln abzusichern.
Allerdings gibt es nicht nur einen Weg, einen YubiKey mit SSH zu verwenden. Je nach Umgebung kommen FIDO2/OpenSSH, PIV oder OpenPGP infrage. Dieser Ratgeber erklärt die Unterschiede und zeigt, welche Variante für welchen Anwendungsfall sinnvoll ist.
Kann man einen YubiKey für SSH verwenden?
Ja. Ein YubiKey kann für die Authentifizierung über Secure Shell (SSH) verwendet werden. Moderne OpenSSH-Versionen unterstützen FIDO-Sicherheitsschlüssel direkt. Mit der YubiKey 5 Series stehen darüber hinaus weitere Möglichkeiten über PIV beziehungsweise OpenPGP zur Verfügung.
Damit gibt es grundsätzlich drei interessante Ansätze:
- SSH mit FIDO2 beziehungsweise FIDO-Security-Key-Unterstützung von OpenSSH
- SSH über PIV/Smartcard
- SSH über OpenPGP
Welche Variante sinnvoll ist, hängt von der bestehenden Infrastruktur, dem eingesetzten YubiKey-Modell und den Anforderungen an Schlüsselverwaltung und Kompatibilität ab.
Warum normale SSH-Schlüssel ein Sicherheitsrisiko sein können
SSH Public-Key-Authentifizierung ist grundsätzlich ein bewährtes Verfahren. Ein typisches Schlüsselpaar besteht aus einem öffentlichen und einem privaten Schlüssel.
Der öffentliche Schlüssel wird auf dem Zielsystem hinterlegt. Der private Schlüssel verbleibt beim Benutzer und beweist bei der Anmeldung, dass dieser zum hinterlegten öffentlichen Schlüssel gehört.
Genau dieser private Schlüssel ist besonders schützenswert.
Liegt er als Datei auf einem Notebook, muss dessen Schutz vollständig durch das Betriebssystem, Dateiberechtigungen, Verschlüsselung und gegebenenfalls eine Passphrase gewährleistet werden.
Wird der private Schlüssel kopiert oder anderweitig kompromittiert, kann daraus ein erhebliches Sicherheitsrisiko entstehen.
Was verändert ein Hardware Security Key?
Bei hardwaregestützter SSH-Authentifizierung wird ein physischer Authenticator in den Anmeldeprozess eingebunden.
Der entscheidende Vorteil besteht darin, dass die kryptografische Operation an die Hardware gebunden werden kann. Der Benutzer benötigt damit nicht nur die entsprechende Konfiguration, sondern auch den physischen Sicherheitsschlüssel.
Je nach gewähltem Verfahren und Konfiguration kann zusätzlich eine PIN oder eine bewusste Benutzerinteraktion am YubiKey verlangt werden.
Das erhöht insbesondere bei privilegierten Konten die Hürde für einen Angreifer erheblich.
Drei Möglichkeiten, einen YubiKey für SSH zu verwenden
| Methode | Geeignet für | YubiKey-Serie | Besonderheit |
|---|---|---|---|
| OpenSSH + FIDO | Moderne SSH-Umgebungen | Security Key Series und YubiKey 5 Series | Direkte FIDO-Unterstützung in OpenSSH |
| PIV / Smartcard | Enterprise- und PKI-Umgebungen | YubiKey 5 Series | Integration über Smartcard-/PKI-Funktionen |
| OpenPGP | Bestehende GPG-/OpenPGP-Workflows | YubiKey 5 Series | Interessant für Teams mit bestehender OpenPGP-Infrastruktur |
Variante 1: SSH direkt mit FIDO2 und OpenSSH
Für viele moderne Umgebungen ist die direkte FIDO-Unterstützung von OpenSSH der interessanteste Ansatz.
OpenSSH unterstützt seit Version 8.2 Sicherheitsschlüssel über spezielle Schlüsseltypen. Dabei wird der Hardware-Authenticator direkt in den SSH-Authentifizierungsprozess eingebunden.
Ein typisches Beispiel ist ein ECDSA-Security-Key-Schlüssel:
ssh-keygen -t ecdsa-skDas -sk steht dabei für einen Security-Key-basierten Schlüsseltyp.
Je nach unterstützter Hardware und Software kann alternativ auch ein Ed25519-basierter Security-Key-Typ eingesetzt werden:
ssh-keygen -t ed25519-skVor einem produktiven Rollout sollte immer geprüft werden, welche Algorithmen und Optionen von den eingesetzten Clients, Servern und Security Keys tatsächlich unterstützt werden.
Was wird bei FIDO-SSH auf dem Computer gespeichert?
Hier besteht ein wichtiger Unterschied zu einem klassischen SSH Private Key.
Bei der FIDO-basierten Variante enthält die auf dem Rechner gespeicherte SSH-Datei nicht einfach den exportierbaren privaten kryptografischen Schlüssel. Stattdessen enthält sie Informationen, mit denen OpenSSH den zugehörigen Hardware-Authenticator verwenden kann.
Für die eigentliche kryptografische Authentifizierung wird weiterhin der passende Security Key benötigt.
Dadurch reicht es einem Angreifer nicht ohne Weiteres, lediglich die entsprechende SSH-Datei vom Notebook zu kopieren.
Was sind Resident Keys bei SSH?
OpenSSH verwendet für eine bestimmte FIDO2-Funktion weiterhin den Begriff „resident key“. In den aktuellen FIDO- und WebAuthn-Standards wird dafür üblicherweise von einem discoverable credential gesprochen.
Ein solcher Schlüssel kann mit einer entsprechenden Option erzeugt werden:
ssh-keygen -t ed25519-sk -O residentDer Vorteil liegt insbesondere in der Portabilität. Die benötigten Credential-Informationen können stärker an den Authenticator gebunden werden, sodass ein Benutzer seinen Sicherheitsschlüssel leichter auf einem anderen Arbeitsplatz einsetzen kann.
Das kann beispielsweise für Administratoren interessant sein, die von mehreren definierten Management-Workstations auf Server zugreifen müssen.
PIN und Benutzerverifikation für SSH
Eine weitere wichtige Möglichkeit ist die Benutzerverifikation.
OpenSSH kann bei unterstützten FIDO2-Sicherheitsschlüsseln so konfiguriert werden, dass für die Nutzung des SSH-Schlüssels eine Benutzerverifikation verlangt wird.
Beispielsweise:
ssh-keygen -t ed25519-sk -O verify-requiredDamit kann die Authentifizierung neben dem Besitz des Hardware-Schlüssels zusätzlich von der vorgesehenen Benutzerverifikation abhängen.
Für privilegierte Konten ist das besonders interessant, weil ein gestohlener YubiKey dadurch nicht automatisch ausreicht, um den entsprechenden SSH-Zugang zu verwenden.
Variante 2: YubiKey PIV für SSH
Die YubiKey 5 Series unterstützt zusätzlich Personal Identity Verification (PIV) beziehungsweise Smartcard-Funktionen.
Damit können kryptografische Schlüssel innerhalb der PIV-Anwendung des YubiKeys verwendet werden.
OpenSSH kann über eine PKCS#11-Schnittstelle auf entsprechende Schlüssel zugreifen.
Dieser Ansatz ist insbesondere für Unternehmen interessant, die bereits:
- eine Public Key Infrastructure (PKI) betreiben,
- Smartcards einsetzen,
- Zertifikate zentral verwalten,
- bestehende PIV-Prozesse besitzen oder
- mehrere Unternehmensanwendungen mit derselben Smartcard-Infrastruktur absichern.
Für einen reinen neuen SSH-Rollout ist PIV nicht automatisch besser als die direkte FIDO-Unterstützung. Die Entscheidung hängt von der bestehenden Infrastruktur ab.
Variante 3: OpenPGP für SSH
Eine weitere Möglichkeit der YubiKey 5 Series ist OpenPGP.
OpenPGP wird häufig mit E-Mail-Verschlüsselung und digitalen Signaturen verbunden, kann aber auch in SSH-Workflows integriert werden.
Dieser Ansatz ist insbesondere dann interessant, wenn ein Unternehmen oder Entwicklerteam bereits eine etablierte OpenPGP-Infrastruktur besitzt.
Für einen neuen, ausschließlich auf SSH ausgerichteten Rollout sollte dagegen geprüft werden, ob die direkte FIDO-Unterstützung von OpenSSH einfacher zu betreiben ist.
FIDO2, PIV oder OpenPGP: Welche Methode sollte man wählen?
| Anforderung | Empfohlener Ausgangspunkt |
|---|---|
| Neuer moderner SSH-Rollout | OpenSSH + FIDO prüfen |
| Vorhandene PKI-/Smartcard-Infrastruktur | PIV prüfen |
| Bestehende OpenPGP-Infrastruktur | OpenPGP prüfen |
| Möglichst einfache FIDO-Hardware | Security Key Series prüfen |
| SSH plus PIV, OpenPGP, OATH oder OTP | YubiKey 5 Series |
Security Key oder YubiKey 5 für SSH?
Das ist eine der wichtigsten Kaufentscheidungen.
Wenn ausschließlich die direkte FIDO-Unterstützung von OpenSSH benötigt wird, kann die Security Key Series bereits die passende Wahl sein.
Die Security Key Series konzentriert sich auf FIDO-basierte Authentifizierung.
Wer dagegen zusätzlich PIV, OpenPGP, OATH oder OTP einsetzen möchte, benötigt die umfangreichere YubiKey 5 Series.
| Funktion | Security Key Series | YubiKey 5 Series |
|---|---|---|
| FIDO2 | Ja | Ja |
| FIDO-basierte OpenSSH-Nutzung | Ja, bei kompatibler Umgebung | Ja, bei kompatibler Umgebung |
| PIV | Nein | Ja |
| OpenPGP | Nein | Ja |
| OATH | Nein | Ja |
| OTP | Nein | Ja |
| Typischer Einsatz | FIDO-fokussierte Authentifizierung | Multi-Protokoll-Umgebungen |
Eine ausführlichere Gegenüberstellung finden Sie in unserem Beitrag YubiKey 5 vs. Security Key – alle Unterschiede einfach erklärt.
Welcher YubiKey eignet sich für SSH?
Die Modellwahl hängt vor allem von zwei Fragen ab:
- Welche Protokolle werden benötigt?
- Welchen USB-Anschluss besitzen die verwendeten Arbeitsplätze?
Security Key C NFC
Für einen modernen FIDO-fokussierten SSH-Rollout an USB-C-Geräten kann der Security Key C NFC eine interessante Option sein.
Er bietet USB-C und NFC und konzentriert sich auf FIDO-basierte Authentifizierung.
Security Key NFC
Für Arbeitsplätze mit USB-A bietet sich entsprechend der Security Key NFC an.
Auch hier liegt der Schwerpunkt auf FIDO.
YubiKey 5C NFC
Wenn neben FIDO-basiertem SSH zusätzlich PIV, OpenPGP oder andere Protokolle benötigt werden, ist der YubiKey 5C NFC eine flexible USB-C-Option.
YubiKey 5 NFC
Für klassische USB-A-Arbeitsplätze bietet der YubiKey 5 NFC dieselbe grundsätzliche Multi-Protokoll-Ausrichtung mit USB-A und NFC.
YubiKey 5C
Wer USB-C benötigt, auf NFC aber verzichten kann, kann den YubiKey 5C prüfen.
Praxisbeispiel: DevOps-Team mit Linux-Servern
Ein Unternehmen betreibt 150 Linux-Server in mehreren Cloud-Umgebungen. Zehn DevOps-Mitarbeiter besitzen administrative SSH-Zugänge.
Bisher befinden sich die privaten SSH-Schlüssel verschlüsselt auf den jeweiligen Entwickler-Notebooks.
Ein mögliches Zielbild wäre:
- FIDO-fähige SSH-Schlüssel für privilegierte Administratoren,
- physischer Security Key pro Administrator,
- Benutzerverifikation für besonders sensible Zugänge,
- zweiter registrierter Schlüssel als Backup,
- zentral dokumentierte Ausgabe,
- definierter Prozess bei Verlust und Offboarding.
Damit wird nicht automatisch die gesamte Serverumgebung sicher. Aber eine wichtige Angriffsmöglichkeit wird reduziert: Der alleinige Diebstahl einer klassischen privaten SSH-Key-Datei reicht bei einem korrekt implementierten hardwaregebundenen Verfahren nicht mehr aus.
Praxisbeispiel: Administrator mit mehreren Arbeitsplätzen
Ein Administrator verwendet einen fest definierten Büro-PC, ein Notebook und eine gesicherte Management-Workstation.
Hier können discoverable beziehungsweise resident FIDO-Credentials interessant sein.
Statt einen klassischen privaten SSH-Schlüssel zwischen mehreren Rechnern zu kopieren, kann der physische Authenticator stärker zum portablen Vertrauensanker werden.
Ob dieser Ansatz im konkreten Unternehmen geeignet ist, hängt von der gewünschten Schlüsselverwaltung und den verwendeten OpenSSH-Versionen ab.
Warum ein YubiKey allein kein SSH-Sicherheitskonzept ersetzt
Hardwaregestützte Authentifizierung löst nicht sämtliche Probleme privilegierter Zugänge.
Ein professionelles SSH-Sicherheitskonzept sollte zusätzlich berücksichtigen:
- Welche Benutzer benötigen überhaupt SSH-Zugriff?
- Welche Server dürfen sie erreichen?
- Werden Root-Logins eingeschränkt?
- Wie werden öffentliche Schlüssel verteilt und widerrufen?
- Wie erfolgt das Offboarding?
- Wie werden verlorene Sicherheitsschlüssel behandelt?
- Wie werden Zugriffe protokolliert?
- Wie lange bleiben Berechtigungen gültig?
- Gibt es getrennte administrative Konten?
- Wie werden Notfallzugänge abgesichert?
Der YubiKey ist damit ein wichtiger Baustein – aber nicht die gesamte Privileged-Access-Strategie.
Backup: Was passiert, wenn der YubiKey verloren geht?
Diese Frage muss vor dem Rollout beantwortet werden.
Ein Hardware-Schlüssel erhöht die Sicherheit gerade deshalb, weil die Authentifizierung an ein physisches Objekt gebunden wird. Geht dieses Objekt verloren, muss ein kontrollierter Recovery-Prozess vorhanden sein.
Für kritische Administratoren ist deshalb ein zweiter registrierter Security Key sinnvoll.
Der Backup-Key sollte nicht gemeinsam mit dem täglichen Schlüssel transportiert werden. Sonst können bei Verlust einer Tasche oder eines Schlüsselbunds beide Authenticators gleichzeitig verloren gehen.
Eine bessere Strategie ist:
- primären YubiKey für den täglichen Einsatz registrieren,
- zweiten YubiKey als Backup registrieren,
- Backup an einem sicheren Ort aufbewahren,
- Zuordnung dokumentieren,
- Prozess zum Sperren beziehungsweise Entfernen verlorener Credentials definieren.
Was passiert beim Offboarding eines Administrators?
Auch das Offboarding muss Teil des SSH-Konzepts sein.
Verlässt ein Mitarbeiter das Unternehmen oder wechselt seine Rolle, reicht es nicht, lediglich den physischen YubiKey zurückzugeben.
Die zugehörigen SSH-Berechtigungen beziehungsweise öffentlichen Schlüssel müssen aus den relevanten Systemen entfernt oder zentral widerrufen werden.
Das Prinzip lautet deshalb:
Hardware-Rückgabe und Berechtigungsentzug sind zwei getrennte Prozesse.
Beide müssen abgeschlossen werden.
Kann derselbe YubiKey mehrere Server schützen?
Ja. Ein YubiKey ist nicht grundsätzlich auf einen einzelnen Server beschränkt.
Wie viele Systeme mit einer Identität beziehungsweise einem Credential erreichbar sind, wird durch die jeweilige SSH- und Berechtigungsarchitektur bestimmt.
In Unternehmen sollte allerdings vermieden werden, ohne Konzept einen einzigen hochprivilegierten Schlüssel für sämtliche Systeme einzusetzen.
Trennung von Rollen, Umgebungen und Berechtigungen bleibt auch mit Hardware-Authentifizierung wichtig.
SSH mit YubiKey und GitHub
Auch Git-Plattformen können ein relevanter Anwendungsfall sein.
GitHub unterstützt beispielsweise FIDO2- beziehungsweise Security-Key-basierte SSH-Schlüssel. Dadurch kann ein Hardware Security Key nicht nur für Serverzugriffe, sondern auch für bestimmte Git-Workflows eingesetzt werden.
Für Entwickler ist das besonders interessant, weil Quellcode-Repositories und die dazugehörigen Credentials häufig zu den wertvollsten digitalen Assets eines Unternehmens gehören.
Welche Rolle spielt NFC bei SSH?
NFC ist für den klassischen SSH-Zugriff von einem Notebook nicht automatisch erforderlich.
Für einen Administrator, der seinen YubiKey primär per USB mit einer Workstation verwendet, kann ein Modell ohne NFC vollkommen ausreichend sein.
NFC wird interessant, wenn derselbe YubiKey zusätzlich mit kompatiblen mobilen Geräten oder für andere Authentifizierungsanwendungen verwendet werden soll.
Die Produktauswahl sollte deshalb nicht nach dem Prinzip „mehr Funktionen sind immer besser“ erfolgen, sondern nach den tatsächlich verwendeten Geräten und Anwendungen.
USB-A oder USB-C für Administratoren?
Bei einem Unternehmens-Rollout sollte die vorhandene Geräteflotte analysiert werden.
Moderne Business-Notebooks setzen zunehmend auf USB-C. Ältere Desktop-PCs, Server-Konsolen und Administrationsarbeitsplätze besitzen dagegen häufig weiterhin USB-A.
| Umgebung | Mögliche Auswahl |
|---|---|
| USB-C, nur FIDO benötigt | Security Key C NFC |
| USB-A, nur FIDO benötigt | Security Key NFC |
| USB-C, Multi-Protokoll benötigt | YubiKey 5C NFC oder YubiKey 5C |
| USB-A, Multi-Protokoll benötigt | YubiKey 5 NFC |
Best Practices für einen SSH-YubiKey-Rollout
1. Zuerst den SSH-Use-Case definieren
Entscheiden Sie, ob FIDO/OpenSSH, PIV oder OpenPGP eingesetzt werden soll.
2. Client- und Serverversionen prüfen
Insbesondere bei der direkten FIDO-Unterstützung muss die eingesetzte OpenSSH-Umgebung kompatibel sein.
3. Pilotgruppe verwenden
Beginnen Sie mit einigen erfahrenen Administratoren und testen Sie reale Arbeitsabläufe.
4. Recovery testen
Simulieren Sie bewusst den Verlust eines YubiKeys. Ein Recovery-Prozess, der nur auf Papier funktioniert, ist nicht ausreichend.
5. Backup-Key einplanen
Für kritische Konten sollte ein zweiter Authenticator Bestandteil des Designs sein.
6. Offboarding dokumentieren
Definieren Sie, welche SSH-Berechtigungen beim Ausscheiden eines Mitarbeiters entfernt werden müssen.
7. Nicht alle Administratoren automatisch gleich behandeln
Produktionsserver, Entwicklungsumgebungen, Netzwerkgeräte und Git-Repositories können unterschiedliche Sicherheitsanforderungen besitzen.
FAQ: YubiKey und SSH
Funktioniert ein YubiKey mit SSH?
Ja. Moderne OpenSSH-Versionen können FIDO-Sicherheitsschlüssel direkt verwenden. Die YubiKey 5 Series ermöglicht zusätzlich SSH-Szenarien über PIV und OpenPGP.
Brauche ich einen YubiKey 5 für SSH?
Nicht zwingend. Wenn Sie ausschließlich die direkte FIDO-Unterstützung von OpenSSH nutzen möchten, kann auch die Security Key Series geeignet sein. Für PIV, OpenPGP und weitere Protokolle benötigen Sie dagegen die YubiKey 5 Series.
Ist der private SSH-Schlüssel auf dem YubiKey gespeichert?
Das hängt vom verwendeten Verfahren ab. Bei FIDO-basierten OpenSSH-Schlüsseln ist die kryptografische Authentifizierung an den Hardware-Authenticator gebunden; bei resident beziehungsweise discoverable Credentials können zusätzliche Credential-Daten auf dem Authenticator gehalten werden. PIV und OpenPGP verwenden wiederum ihre jeweiligen Anwendungen auf der YubiKey-5-Plattform.
Kann ich denselben YubiKey auf mehreren Computern verwenden?
Ja, abhängig von der gewählten SSH-Konfiguration. Gerade FIDO2-Resident-Keys können für portable Administrator-Szenarien interessant sein.
Was passiert, wenn ich meinen SSH-YubiKey verliere?
Dann benötigen Sie einen zuvor geplanten Recovery-Weg. Für kritische Administratorzugänge empfiehlt sich ein zweiter registrierter Hardware-Schlüssel beziehungsweise eine andere kontrollierte Notfallmethode. Der verlorene Zugang muss anschließend aus den relevanten Systemen entfernt werden.
Kann ein gestohlener YubiKey sofort für SSH verwendet werden?
Nicht zwangsläufig. Je nach Konfiguration kann zusätzlich eine PIN beziehungsweise Benutzerverifikation erforderlich sein. Trotzdem muss ein verlorener YubiKey als Sicherheitsereignis behandelt und der zugehörige Zugang kontrolliert widerrufen werden.
Ist FIDO2 für SSH besser als PIV?
Nicht grundsätzlich. Für neue moderne OpenSSH-Deployments ist die direkte FIDO-Unterstützung attraktiv, weil sie vergleichsweise geradlinig ist. Unternehmen mit vorhandener PKI- und Smartcard-Infrastruktur können dagegen gute Gründe für PIV haben.
Welcher YubiKey ist für DevOps geeignet?
Wenn ausschließlich FIDO-basiertes SSH benötigt wird, sollte zunächst die Security Key Series geprüft werden. Werden zusätzlich PIV, OpenPGP, OATH oder andere Authentifizierungsverfahren benötigt, ist die YubiKey 5 Series flexibler.
Fazit: SSH ist ein idealer Anwendungsfall für Hardware-Sicherheit
SSH-Schlüssel schützen einige der wertvollsten Zugänge eines Unternehmens: Server, Cloud-Infrastruktur, Entwicklungsumgebungen und administrative Systeme.
Gerade deshalb sollte der private Schlüssel nicht unnötig als kopierbare Datei auf zahlreichen Administrator-Notebooks verteilt werden.
Mit FIDO-Unterstützung in modernen OpenSSH-Versionen können Hardware Security Keys heute vergleichsweise direkt in SSH-Workflows integriert werden. Für bestehende Enterprise-Infrastrukturen bietet die YubiKey 5 Series zusätzlich PIV- und OpenPGP-Möglichkeiten.
Die richtige Entscheidung lautet deshalb nicht einfach „Welcher YubiKey ist der beste?“, sondern:
Welches SSH-Verfahren passt zu unserer Infrastruktur und wie gestalten wir Rollout, Backup, Widerruf und Offboarding?
Für einen reinen FIDO-basierten SSH-Rollout sollten Unternehmen zunächst die Security Key Series prüfen. Werden zusätzliche Protokolle benötigt, bietet die YubiKey 5 Series deutlich mehr Möglichkeiten.
Sie planen die Absicherung Ihrer Administratoren oder einen größeren YubiKey-Rollout? Bei yubikey-shop.at erhalten Unternehmen, Behörden und Bildungseinrichtungen Unterstützung bei der Modellauswahl und können für größere Stückzahlen individuelle Projektkonditionen anfragen.
