Passwortlose SSH-Zugänge
Digitaler Schlüssel
Veröffentlicht in Ausgabe 06/2024 - PRAXIS
Historisch bedingt ist der Einsatz von Passwörtern immer noch sehr weit verbreitet, wenn Benutzer eine Authentisierung an einem System vornehmen. Mehr und mehr setzen sich jedoch moderne und auch sicherere Authentisierungsverfahren durch. Diese erfordern dann meist mehrere Faktoren für eine erfolgreiche Anmeldung (Multifaktor-Authentifizierung, MFA), oft auch kombiniert mit kryptografischen Hardware-Token wie beispielsweise einem YubiKey.
Als Web-SSO (Single Sign-on) wird derweil ein Verfahren bezeichnet, bei dem ein Benutzer für den Zugriff auf einen bestimmten Dienst gar kein Passwort mehr benötigt, sondern stattdessen die Authentifizierung an einen externen Identity-Provider (IdP) abgibt. Mittels OAuth 2.0, einem Protokoll zur Access-Delegierung, und dem darauf aufbauendem OpenID-Connect-Protokoll, führt dann der IdP die Authentifizierung des Benutzers durch.
Passkeys für den sicheren Zugriff auf Webdienste
Immer beliebter werden in letzter Zeit sogenannte Passkeys. Hierbei handelt es sich um einen Ansatz, der Public-Key basierte Kryptographie einsetzt und auf dem FIDO2-Standard [1] basiert. Große Tech-Firmen wie Google oder Apple setzen in den letzten Monaten vermehrt auf dieses Authentifizierungsverfahren, weshalb es immer mehr in den Fokus der Benutzer rückt – auch weil Passkeys eine wesentlich bessere Sicherheit bieten als herkömmliche Passwörter. Selbst beim Einsatz unterschiedlicher Passwörter für den Zugriff auf verschiedene Webservices sind Benutzer nicht vor Phishing-Angriffen geschützt. Anders sieht dies bei Passkeys aus. Durch den Einsatz von Public-Key-Kryptographie ist dieses Verfahren gegen Phishing-Angriffe resistent.
Historisch bedingt ist der Einsatz von Passwörtern immer noch sehr weit verbreitet, wenn Benutzer eine Authentisierung an einem System vornehmen. Mehr und mehr setzen sich jedoch moderne und auch sicherere Authentisierungsverfahren durch. Diese erfordern dann meist mehrere Faktoren für eine erfolgreiche Anmeldung (Multifaktor-Authentifizierung, MFA), oft auch kombiniert mit kryptografischen Hardware-Token wie beispielsweise einem YubiKey.
Als Web-SSO (Single Sign-on) wird derweil ein Verfahren bezeichnet, bei dem ein Benutzer für den Zugriff auf einen bestimmten Dienst gar kein Passwort mehr benötigt, sondern stattdessen die Authentifizierung an einen externen Identity-Provider (IdP) abgibt. Mittels OAuth 2.0, einem Protokoll zur Access-Delegierung, und dem darauf aufbauendem OpenID-Connect-Protokoll, führt dann der IdP die Authentifizierung des Benutzers durch.
Passkeys für den sicheren Zugriff auf Webdienste
Immer beliebter werden in letzter Zeit sogenannte Passkeys. Hierbei handelt es sich um einen Ansatz, der Public-Key basierte Kryptographie einsetzt und auf dem FIDO2-Standard [1] basiert. Große Tech-Firmen wie Google oder Apple setzen in den letzten Monaten vermehrt auf dieses Authentifizierungsverfahren, weshalb es immer mehr in den Fokus der Benutzer rückt – auch weil Passkeys eine wesentlich bessere Sicherheit bieten als herkömmliche Passwörter. Selbst beim Einsatz unterschiedlicher Passwörter für den Zugriff auf verschiedene Webservices sind Benutzer nicht vor Phishing-Angriffen geschützt. Anders sieht dies bei Passkeys aus. Durch den Einsatz von Public-Key-Kryptographie ist dieses Verfahren gegen Phishing-Angriffe resistent.
Hardware- oder Software-Token
Sobald Sie einen Webservice besuchen und dort einen Passkey generieren, wird ein eindeutiges Schlüsselpaar bestehend aus einem öffentlichen und einem privaten Schlüssel generiert. Der öffentliche Schlüssel wird innerhalb des Webservices hinterlegt, der private sicher auf einem Hardware-Token, beispielsweise einem YubiKey. Von dort lässt sich dieser auch nicht mehr exportieren. Somit ist ein Passkey nur für den Benutzer zu gebrauchen, der physischen Zugang zu dem Hardware-Token hat.
Des Weiteren können Sie den Zugriff weiter mit einem zusätzlichen Authentifizierungsfaktor schützen. Hierbei kann es sich um eine einfache PIN oder auch ein biometrisches Merkmal handeln – abhängig davon, welchen Hardware-Token Sie tatsächlich einsetzen. Dieser Vorgang ist als User-Verification (UV) bekannt. Dass ein Authentifizierungsvorgang auch tatsächlich von einem Benutzer angefordert wurde, ist durch das Berühren des Tokens sichergestellt, was als User-Presence (UP) bezeichnet wird.
Die große Popularität haben Passkeys auch dem Umstand zu verdanken, dass durch den immensen Support von Firmen wie Google oder Apple das Handling von FIDO2-Tokens vereinfacht werden sollte und somit nicht mehr nur Hardware-Tokens zum Generieren und Speichern der Tokens zum Einsatz kommen, sondern auch rein softwarebasierte Lösungen unterstützt werden.
Somit können Sie einen Passkey nun auch innerhalb eines Passwortmanagers oder einer Keychain auf Ihrem System, Handy oder Tablet speichern. Aktuell gibt es aber noch keinen einheitlichen Industriestandard, was die Verwaltung solch rein softwarebasierter Passkeys angeht. Von daher gibt es eine Reihe an offenen Fragen, beispielsweise bezüglich des Formats des gespeicherten Passkeys und ob ein Export und Import möglich ist oder sogar eine Interoperabilität mit anderen Passwortmanagern existieren sollte. Es ist jedoch davon auszugehen, dass diese Fragen in der nahen Zukunft beantwortet werden.
Passkeys auf Betriebssystem-Ebene
Auch wenn der Einsatz von Passkeys bisher primär im Webumfeld erfolgte, können Sie mittlerweile auch auf Betriebssystemebene einen Passkey für die Anmeldung an einem System verwenden. Im Open-Source-Tipp der IT-Administrator-Ausgabe 06/2023 [2] haben wir dies anhand der Softwarepakete FreeIPA [3] und SSSD [4] demonstriert. Der Artikel beschreibt, wie Sie einen Passkey erzeugen, den öffentlichen Schlüssel an zentraler Stelle im FreeIPA-Identity-Management-Server ablegen um somit bei der Anmeldung an einem lokalen System ein Kerberos-Ticket ausgestellt zu bekommen.
Mithilfe dieses Kerberos-Tickets können Sie sich dann transparent gegenüber anderen Services authentisieren. Der SSSD erlaubt im Backend neben einem FreeIPA-System allerdings auch einen klassischen LDAP- oder Active-Directory Server. Jedoch bekommt der Benutzer in diesem Fall kein Kerberos-Ticket ausgestellt und ist somit für den Zugriff auf andere Dienste, beispielsweise einen SSH-Server, auf andere Authentifizierungsverfahren angewiesen.
OpenSSH unterstützt FIDO2
Nun ist es so, dass OpenSSH seit der Version 8.2 ebenfalls den Einsatz von FIDO2-Schlüsseln von Hause aus unterstützt. Leider greift die Software hierfür nicht auf den Linux-PAM-Stack zurück, sondern hat den Support fest in den OpenSSH-Code eingebaut. Dies hat zur Folge, dass Sie für den Zugriff auf einen OpenSSH-Server einen neuen Schlüssel generieren müssen und nicht auf einen vielleicht bereits vorhandenen Passkey, der zuvor mithilfe des SSSD für einen Benutzer erzeugt wurde, zurückgreifen können.
OpenSSH verwendet die beiden Public-Key-Typen ecdsa-sk und ed25519-sk. Die Endung "-sk" steht dabei für "Security Key". Für die Benutzerverifizierung arbeitet OpenSSH ausschließlich mit einer PIN. Biometrische Merkmale werden auch in der aktuellen Version nicht unterstützt. Um nun also einen Passkey auf Basis des Public-Key-Typs ecdsa-sk zu erzeugen, rufen Sie das folgende Kommando auf, zum Beispiel:
ssh-keygen -t ecdsa-sk -O resident -O application=ssh:tuxgeek.de -O user=tscherf -O verify-required
Die einzelnen Optionen sind im Abschnitt "FIDO AUTHENTICATOR" der Hilfeseite des Tools ssh-keygen [5] sehr ausführlich dokumentiert. Wie im Bild zu erkennen ist, werden Sie nach Aufruf von
ssh-keygen dazu aufgefordert, eine PIN einzugeben und den Hardware-Token zu berühren, um das Generieren eines Schlüsselpaares zu starten.Im Anschluss werden zwei Dateien erzeugt. Der öffentliche Schlüssel landet in der Datei "id_ecdsa_sk.pub", der private Schlüssel ist nun aber nicht, wie anzunehmen wäre, in der zweiten Datei (id_ecdsa_sk), gespeichert. Dieser liegt auf dem Hardware-Token, wo er auch erzeugt wurde. Die Datei "id_ecdsa_sk" enthält lediglich einige Mapping-Daten, um den korrekten Schlüssel auf dem Token zu identifizieren.
Kommt als Hardware-Token ein YubiKey zum Einsatz, erhalten Sie mithilfe des Tools YubiKey-Manager [6] Zugriff auf den Speicher des Tokens, ohne jedoch die Schlüssel von dort auslesen zu können. Das folgende Beispiel zeigt den soeben erzeugten Schlüssel an:
ykman fido credentials list
Den öffentlichen Schlüssel können Sie nun mithilfe von
ssh-copy-id oder auch manuell auf die Systeme kopieren, auf denen Sie sich mit Hilfe des FIDO2-Schlüssels anmelden möchten:ssh-copy-id -i ~/.ssh/id_ecdsa_sk.pub tscherf@idm
Danach liegt der Schlüssel auf dem Remote-Host in der Datei "~/.ssh/authorized_keys" vor. Der Zugriff auf den Remote-Host erfolgt dann wie gewohnt mittels
ssh und der Angabe der Key-Mapping-Datei. Hier ist ein Beispiel:ssh -i ~/.ssh/id_ecdsa_sk tscherf@idm
Alternativ dazu können Sie natürlich auch einen entsprechenden Eintrag in der Datei "~/.ssh/ssh_config" des Clients vornehmen, um den Schlüssel an einen bestimmten Host zu binden, sodass der Schlüssel nicht bei jedem Aufruf immer wieder mit anzugeben ist:
Host idm.example.com
IdentityFile ~/.ssh/id_ecdsa_sk
Sobald der Aufbau der SSH-Verbindung erfolgt, werden Sie aufgefordert, die PIN des Schlüssels einzugeben und den Hardware-Token zu berühren. War dieser Vorgang erfolgreich, sind Sie schließlich dank des FIDO2-Tokens auf dem Remote-Host angemeldet.
Fazit
Passkeys stehen heute oftmals in Form von Software-Token zur Verfügung, lassen sich aber natürlich auch weiterhin auf Hardware-Token erzeugen und speichern. OpenSSH unterstützt FIDO2-Token seit der Version 8.2 und erlaubt somit das Authentifizieren von Benutzern auf Basis des FIDO2-Standards.
(dr)
Link-Codes
[1] FIDO2: https://fidoalliance.org/fido2/
[2] Open-Source-Tipp 06/2023: https://www.it-administrator.de/heftarchiv-article?xv_article=ADMIN_2023_06_058&issue=062023&toc=2023-06
[3] FreeIPA: https://www.freeipa.org/
[4] SSSD: https://sssd.io
[5] ssh-keygen-Hilfeseite: https://man7.org/linux/man-pages/man1/ssh-keygen.1.html
[6] YubiKey-Manager: https://www.yubico.com/support/download/yubikey-manager/