1. Public-Key-Authentifizierung
Sowohl der GPG-Hauptschlüssel (Signieren / Zertifizieren) als auch die beiden Unterschlüssel für die Verschlüsselung und Authentisierung wurden im letzten Teil der Serie sicher auf dem Nitrokey abgelegt. Damit sind nun alle Voraussetzungen erfüllt, um die Anwendungsszenarien vorzustellen.
Zur Erinnerung: Ein Schlüsselpaar besteht aus einem geheimen Teil (privater Schlüssel) und einem nicht geheimen Teil (öffentlicher Schlüssel). Dieses Pärchen ermöglicht unter anderem eine Authentifizierung gegenüber einem anderen System über das SSH-Protokoll, das insbesondere zur Administration von und Kommunikation mit Servern eingesetzt wird.
Im vorliegenden Beitrag der Serie »Nitrokey« wird der Vorgang beschrieben, wie der GnuPG-Unterschlüssel »Authentisierung« zur passwortlosen Anmeldung an einem SSH-Server genutzt werden kann. Die Verwendung eines kryptografischen Schlüssels anstelle von Passwörtern gilt in der Regel als sicherer.
- Zwei Schlüssel für alle Fälle – Nitrokey Teil1
- GnuPG-Schlüsselerstellung und Smartcard-Transfer – Nitrokey Teil2
- GnuPG-Public-Key-Authentifizierung – Nitrokey Teil3
- GnuPG: E-Mail-Verschlüsselung unter Android – Nitrokey Teil4
2. GPG-Schlüssel für die OpenSSH-Anmeldung
Die Authentifizierung an einem SSH-Server erfolgt in der Regel mittels Passwort. Eine alternative Anmeldemöglichkeit ist die Public-Key-Authentifizierung. Hierbei wird der öffentliche Teil des Schlüssels auf dem Server hinterlegt und die Authentifizierung erfolgt anschließend mit dem privaten Teil des Schlüssels. Dieses Anmeldeverfahren gilt nicht nur als sicherer, sondern ermöglicht ebenfalls, dass sich Clients auch ohne Benutzerinteraktion auf SSH-Servern anmelden können. Zur weiteren Absicherung kann der private SSH-Schlüssel zusätzlich mit einem Passwort geschützt werden.
Für das Public-Key-Anmeldeverfahren werden im Normalfall mittels ssh-keygen ein RSA– oder Ed25519-Schlüsselpärchen erstellt und anschließend zur Authentifizierung benutzt. Das ist allerdings in unserem Fall nicht mehr notwendig, da wir bereits ein GnuPG-Schlüsselpärchen auf Basis von RSA erstellt und auf den Nitrokey übertragen haben. Zur Erinnerung – wir haben uns folgende Schlüssel bzw. Unterschlüssel erstellt:
- GPG-Hauptschlüssel mit der Funktion Signieren und Zertifizieren
- GPG-Unterschlüssel mit der Funktion Verschlüsselung
- GPG-Unterschlüssel mit der Funktion Authentisierung
Der Unterschlüssel mit der Funktion Authentisierung ermöglicht die Anmeldung am SSH-Server. Es ist also nicht notwendig, ein weiteres Schlüsselpärchen zu generieren, sondern das bereits erstellte kann genutzt werden. Dazu sind allerdings je nach System ein paar kleine Anpassungen notwendig, damit GPG als SSH-Agent genutzt wird.
2.1 Vorbereitung auf dem GNU/Linux-Client
Voraussetzung für die nachfolgende Anleitung ist die Verwendung von GnuPG in der Version 2.x. Eure Smartcard bzw. der Nitrokey wird vermutlich bereits einsatzbereit sein. Mit folgendem Befehl könnt ihr Informationen auslesen:
gpg --card-status
Zunächst wird die SSH-Unterstützung im gpg-agent aktiviert:
echo enable-ssh-support >> $HOME/.gnupg/gpg-agent.conf
Anschließend müssen die Umgebungsvariablen des SSH-Agenten angepasst werden, damit dieser weiß, wie man mit dem GPG-Agenten kommuniziert. Dieser Vorgang ist ebenfalls in der Manpage des gpg-agent dokumentiert. Damit die Umgebungsvariablen automatisch beim Aufruf einer Shell gesetzt werden, könnt ihr sie in der .bashrc hinterlegen:
nano $HOME/.bashrc
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi Danach wird der gpg-agent gestoppt:
gpgconf --kill gpg-agent
Sobald der GPG-Agent von einem Prozess oder einem Vorgang wieder benötigt wird, wird er sich selbst starten. Schließt anschließend das Terminal und ruft eine neue Shell-Session auf.
2.2 Vorbereitung auf dem Windows-Client
Im Nitrokey-Wiki ist ausführlich beschrieben, wie ein Windows-Client, in Kombination mit putty, für die GnuPG-Public-Key-Authentifizierung vorbereitet wird.
3. Inbetriebnahme
Sobald die Client-Systeme die Anmeldung via gpg-agent an einem SSH-Server unterstützen, kann der öffentliche Schlüssel auf den Zielserver ausgerollt werden.
Als Beispielkonfiguration nutze ich nachfolgend diese Parameter:
- Den GnuPG-Schlüssel mit der Key-ID
nitrokey@kuketz.de - IP-Adresse des SSH-Servers bzw. der Gegenstelle
46.232.250.175 - Als Nutzer zur Anmeldung
test
Hinweis
Passt die Parameter bitte an euer Setup an. Ihr könnt die Befehle nicht 1:1 übernehmen.3.1 Ausrollen des öffentlichen Schlüssels
Der öffentliche Schlüssel muss dem Server bzw. dem Nutzer, mit dem ihr euch später mittels GnuPG-Public-Key-Verfahren anmelden möchtet, bekannt gemacht werden. Das erfordert einen Eintrag in der Datei ~/.ssh/authorized_keys im Heimatverzeichnis des Benutzers. Ein darin abgelegter Schlüssel wird als autorisierter Schlüssel bezeichnet, mit dem eine Anmeldung am Server möglich ist.
Mit einem Befehl könnt ihr den öffentlichen Teil eures Schlüssels exportieren und direkt auf den Server ausrollen, der später die Anmeldung via SSH entgegennehmen soll:
gpg --export-ssh-key nitrokey@kuketz.de | ssh test@46.232.250.175 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Bei der Übertragung des öffentlichen Teils des Schlüssels müsst ihr euch mit eurem bestehenden Passwort gegenüber dem Server authentifizieren. Sobald ihr am Server angemeldet seid, solltet ihr prüfen, ob ein entsprechender Eintrag in der Datei authorized_keys erfolgt ist. Lasst euch dazu einfach lokal auf eurem Rechner euren öffentlichen Schlüssel im OpenSSH-Format ausgeben und vergleicht die Ausgabe mit dem serverseitigen Eintrag:
gpg --export-ssh-key nitrokey@kuketz.de
Ausgabe:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDC
[…]
y9mRrM2/qbBxv+aiVH3jhEcxgDWvFzgVn9VYNB4xSN==
openpgp:0xDF66A331
3.2 Testbetrieb
Sobald der Eintrag in der Datei authorized_keys erfolgt ist, könnt ihr euch mit eurem GnuPG-Auth-Schlüssel gegenüber dem Server authentifizieren. Öffnet ein neues Terminal und versucht euch einzuloggen:
ssh test@46.232.250.175
Solltet ihr euren privaten Schlüssel mit einem Passwortschutz versehen haben, wird dieser im Zuge der Anmeldung am Server abgefragt:
Nach der Eingabe des korrekten Passworts für den Zugriff auf den privaten Auth-Schlüssel des Nitrokeys, erfolgt die Anmeldung am Server. Geschafft!
Du kannst den Blog aktiv unterstützen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
3.3 Deaktivierung der Passwort-Authentifizierung [optional]
Nachdem sichergestellt ist, dass der GnuPG-Schlüssel für die Anmeldung am Server verwendet wird, kann die Authentifizierung mittels Passwort deaktiviert werden – dies ist ein optionaler Schritt. Anschließend ist die Anmeldung ausschließlich über das Public-Key-Verfahren bzw. den GnuPG-Schlüssel möglich.
Die Deaktivierung erfordert eine Anpassung in der sshd-Konfigurationsdatei des Servers:
nano /etc/ssh/sshd_config
Dort wird der Eintrag #PasswordAuthentication yes wie folgt angepasst:
PasswordAuthentication no
Nach einem Neustart des OpenSSH-Dienstes ist die Anmeldung ausschließlich über das Public-Key-Verfahren möglich:
systemctl restart sshd
Versucht ihr euch an einem SSH-Server anzumelden, der lediglich die Anmeldung via Public-Key-Verfahren unterstützt, erscheint folgende Meldung, falls ihr nicht im Besitz des dazu passenden privaten Schlüssels seid:
user@IP-Address: Permission denied (publickey).
4. Fazit
Der SSH-Zugriff mit einem GnuPG-Schlüssel zur Authentifizierung ist erfolgreich konfiguriert. Das reduziert die Schlüsselverwaltung, da für die Anmeldung am Server nicht extra ein weiteres OpenSSH-Schlüsselpärchen erstellt werden muss. Mit eurem Nitrokey könnt ihr euch bei Bedarf nun an mehreren SSH-Servern anmelden.
Im kommenden Teil der Artikelserie möchte ich euch zeigen, wie man den Nitrokey mit einem Android-Smartphone koppelt. Mithilfe der App OpenKeychain und des E-Mail-Clients FairEmail (Alternativ K-9 Mail) könnt ihr anschließend verschlüsselte E-Mails am Smartphone lesen oder selbst E-Mails für einen Empfänger verschlüsseln.
Bildquellen:
Access: Freepik from www.flaticon.com is licensed by CC 3.0 BY
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
GnuPG-Schlüsselerstellung und Smartcard-Transfer – Nitrokey Teil2
Zwei Schlüssel für alle Fälle – Nitrokey Teil1
Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test
GnuPG: E-Mail-Verschlüsselung unter Android – Nitrokey Teil4
Verschlüsselte E-Mails mit GnuPG als Supergrundrecht
13 Ergänzungen zu “GnuPG-Public-Key-Authentifizierung – Nitrokey Teil3”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Den PGP Key zum authentifizieren gegenüber einem SSH Server zu nutzen ist super. Das kannte ich bis vor ein paar Tagen auch noch nicht. Im Nitrokey Wiki steht eigentlich jeder Schritt genau so wie hier in deinem Beitrag, deshalb nutze ich das gleiche Verfahren aktuell schon.
Mich würde mal deine Meinung interessieren, wie lange der Nitrokey das Passwort, bzw. PIN „merken“ soll? Oder sollte man das Passwort jedes mal abfragen lassen? Ich habe aktuell 15 min merken gesetzt, aber mehr wäre natürlich sehr komfortabel, gerade was E-Mail lesen angeht.
Wie sieht dein Bedrohungsszenario aus?
– Verlässt du dein Gerät und vergisst gerne mal den Nitrokey abzuziehen?
– Rechnest du damit vor dem Gerät überwältigt zu werden ohne Möglichkeit den Stick abziehen / das Gerät ausschalten zu können?
– Bist du diszipliniert genug den Stick abzuziehen, wenn du ihn beim Arbeiten nicht benötigst?
Es kann sicherlich nicht schaden, wenn der Stick nach 30 Minuten erneut nach dem Pin fragt. Wenn du einen Passwortmanager verwendest, wie handhabst du die Sperrung dort?
1. Wenn ich das Gerät kurzzeitig verlasse, sperre ich auf jeden Fall den Bildschirm. Wenn ich es längere Zeit verlasse, nehme ich auch den Nitrokey mit.
2. Nein *schmunzel*
3. Jein. Während ich am Gerät bin steckt der Stick eigentlich immer, da ich ihn regelmäßig brauche. Auf dem Stick liegt auch meine KeePass Datei.
Beim Passwortmanager sperrt sich meine Datenbank nach 10 Minuten inaktivität automatisch. Ebenfalls nach jedem AutoType. Und sollte ich wissen ich brauche den Passwortmanager in nächster Zeit nicht, dann sperre ich die Datei nach Gebrauch auch manuell.
Und wie Teile ich meinem SSH Client mit, welchen Schlüssel er verwenden soll?
Ich hätte erwartet, dass er das braucht und sich anderenfalls mit uid/pw authentisieren möchte.
Musst du nicht, das übernimmt der gpg-agent für dich. Falls er keinen passenden Schlüssel findet, bspw. dann, wenn auf dem Server der Public-Key nicht hinterlegt wurde, dann gibt es einen Fallback auf die Passwort-Authentisierung.
Ich habe soeben versucht mich bei einer SFTP Verbindung über FileZilla mit dem Nitrokey zu authentifizieren. Allerdings schaffe ich es nicht, dass FileZilla die Smartcard nutzt.
Ich kann höchstens eine Schlüsseldatei auswählen, aber das bringt mir beim Nitrokey wohl nicht viel…
Hat jemand eine Idee wie das funktioniert, bzw. ist das überhaupt möglich?
Öffne mal ein Terminal und starte darüber FileZilla. Die Eingabe von „filezilla“ sollte genügen.
Dann sollte es gehen, weil er dann die Umgebungsvariablen aus der Shell kennt.
Alternativ einen Starter mit folgendem Inhalt anlegen:
Dann sollte es funktionieren und es bleibt kein Terminal-Fenster offen.
Der Starter funktioniert leider nicht:
Fehler: Disconnected: No supported authentication methods available (server sent: publickey)
Fehler: Herstellen der Verbindung zum Server fehlgeschlagen
Okay, schade. Bei mir funktioniert das.
Geht hier nicht. Wenn ich
abschicke, kommt Passwort Anfrage. Aber nicht für den Schlüssel sondern für den Account von user.
Jemand eine Idee?
Hast du nach dem Übertragen der Schlüssel auf dem Nitrokey dafür gesorgt, dass dein lokaler Schlüsselbund über den neuen Standort der Schlüssel bescheid weiß?
Führe mal ein „gpg -K“ aus, wird dein Schlüssel dort angezeigt?
Falls nein: „gpg –card-status“ und nochmal ein „gpg -K“.
Sieht es dann anders aus?
Ja. Schlüssel werden gelistet mit „>“
Ich bekam immer, wenn ich versuchte mit ssh eine Verbindung aufzubauen, den Fehler:
Übrigens kann man sich den Verbindungsaufbau mt -v anzeigen lassen und sieht dort mit welchen Schlüssel ssh den Verbindungsaufbau versucht.
Meine .bashrc hat jetzt folgende Erweiterung:
unset SSH_AGENT_PID if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" fi export GPG_TTY=$(tty) gpg-connect-agent updatestartuptty /bye > /dev/null