Mit einem YubiKey lässt sich die Benutzeranmeldung an einem Linux-PC mit einem zweiten Faktor (U2F) absichern. Den U2F kann man dabei global für jede Benutzeranmeldung, sei es die grafische Anmeldung, via SSH, etc. vorgeben.
Auch eine feinere Granulierung nach Anmeldeverfahren ist möglich.
Der YubiKey kann auch für die Absicherung des Logins bei Windows-Clients verwendet werden, dabei muss der Benutzer neben seinem Benutzernamen und Passwort auch den YubiKey am PC anschließen und dessen Kontakte drücken. Werden beide Login Credentials vom System erkannt, wird der Login erlaubt und der Benutzer erhält Zugang zu seinem Benutzerkonto.
Microsoft bietet seit einiger Zeit die Möglichkeit an, sich an Microsoft 365 mit einem Sicherheitsschlüssel, z.B. einem YubiKey, anzumelden.
Das Hinzufügen der neuen Anmeldemethode ist sehr einfach und schnell erledigt und dauert nur ein paar Minuten.
In meinem letzten Beitrag habe ich beschrieben, wie man seinen eigenen Git-Server konfiguriert und einrichtet und darauf ein öffentliches bare-Git-Repository bereitstellt.
➡ Schritt 3: Git Server konfigurieren und bare-Repository einrichten
Der Zugriff erfolgt dabei über ein ausgetausches SSH-Schlüsselpaar, der öffentlicher Schlüssel wurde in der „authorized_key-Datei“ des Users „git“ abgelegt.
In meinem Blog habe ich bereits öfters Beiträge über den YubiKey veröffentlicht. Nun ist es auch möglich den Zugriff auf den Server mit einem YubiKey weiter abzusichern und damit jeden Commit nur mit diesem Hardware-Token zu erlauben.
Das Ganze funktioniert dann so:
Auf dem YubiKey wird ein privater OpenGPG-Schlüssel hinterlegt.
Der öffentliche Schlüssel wird geteilt und kann auch auf einem OpenGPG-Server für alle einsehbar hinterlegt werden.
Der öffentliche OpenGPG-Schlüssel kann „umgemodelt“ werden und für die Anmeldung an einem Linux-System verwendet werden, d.h. es wird kein klassisches SSH-Schlüsselpaar mehr benötigt.
Die Anmeldung per SSH am Server ist nur noch mit dem Hardwaretoken erlaubt, die Passworteingabe für die Benutzer wird komplett deaktiviert.
Die Anmeldung und der Git Clone, Commit, Push, Pull, etc. funktioniert nur noch mit dem angeschlossenen YubiKey am Git-Client.
YubiKey vorbereiten
Auf der Seite von itemis.com gibt es eine sehr gute Anleitung zum einrichten eures Windows-Rechners und des YubiKey. Ich finde die Blogeinträge gut nachvollziehbar und auch umsetzbar. Am Ende habt ihr auf eurem Windows-PC die Tools, um euch mit einem Hardwaretoken an Remote-Servern anzumelden. Des weiteren sollte der YubiKey entsprechend für die passwortlose Anmeldung eingerichtet sein.
Also schaut euch die paar Blogeinträge auf ➡ https://blogs.itemis.com/de/openpgp-im-berufsalltag-teil-1-was-ist-das an, bevor ihr weitermacht.
Gib mir gerne einen Kaffee ☕ aus!
Wenn dir meine Beiträge gefallen und geholfen haben, dann kannst du mir gerne einen Kaffee ☕ ausgeben.
bc1qfuz93hw2fhdvfuxf6mlxlk8zdadvnktppkzqzj
Git-Server konfigurieren
Nachdem eurer GPG-Schlüssel und YubiKey eingerichtet sind, kann der Server für die Anmeldung via Hardwaretoken konfiguriert werden.
Geht zur Datei „/etc/ssh/sshd_config„.
Bei mir sieht die Datei so aus (Ich habe nur die aktiven Abschnitte hier eingefügt):
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
#Laesst nur Mitglieder der Gruppe "sshadmin" eine SSH-Verbindung herstellen
AllowGroups sshadmin
#Erlaubt die Benutzung von pub keys
PubkeyAuthentication yes
#Passwort-Eingabe ist beim Anmelden
# no = nicht erforderlich, SSH-Anmeldung ist nur noch mit SSH-Schlüssel moeglich
# yes = erforderlich, SSH-Anmeldung ist mit Passwort moeglich
PasswordAuthentication no
PermitEmptyPasswords no
# YubiKey Anmeldung
AuthenticationMethods publickey
Die Zugriffsrechte auf die Datei sollten von euch geprüft und ggf. angepasst werden:
sudo chown root:root
sudo chmod 600
ACHTUNG!
In dieser Konfiguration wird nur der Mitglieder der Gruppe „sshadmin“ erlaubt sich via SSH an dem Server anzumelden. –> Alle Benutzer und Git-Benutzer müssen der Gruppe hinzugefügt werden!
Die neue Gruppe legt ihr so an:
sudo groupadd -r sshadmin
Benutzer fügt ihr der Gruppe mit dem Befehl hinzu:
sudo usermod -a -G sshadmin benutzername
Benutzer entfernt ihr aus der Gruppe, falls erforderlich mit dem Befehl:
sudo deluser benutzername sshadmin
Die Gruppenzugehörigkeit der Benutzer zu sshadmin könnt ihr einfach in der Datei „/etc/group“ prüfen.
cat /etc/group
Der Vorteil dieses Vorgehens ist eine zusätzliche Sicherheit. Benutzer können solange auf den Server per SSH zugreifen solange sie der Gruppe „sshadmin“ angehören. Werden die Benutzer aus der Gruppe entfernt, ist keine SSH-Anmeldung mehr möglich, auch wenn noch ein gültiger SSH-Schlüssel in der „authorized_keys„-Datei im Home-Verzeichnis des Users gespeichert ist.
Natürlich ist andersherum darauf zu achten, dass für die zugriffberechtigten Benutzer ein gültiger Schlüssel in der „authorized_keys“ hinterlegt ist. Fehlt der Schlüssel kommt die Meldung:
„No supported authentication methods available (server sent: publickey)“
Fehlermeldung bei Anmeldung
Nach den Ganzen Anpassung ist der SSH-Dienst neu zu starten. Ab diesem Zeitpunkt ist nur noch die Anmeldung mit dem YubiKey unf für die freigeschalteten Benutzer möglich. Eine lokale Anmeldung für die Benutzer ist weiterhin möglich, solang sie als aktive Benutzer geführt werden. Also sicherheitshalber eine SSH-Sitzung offen lassen, damit ihr weiterhin auf den Server zugreifen könnt, sollte es ein Konfigurations-Problem geben. 😉
sudo systemctl restart sshd
Git und YubiKey
Nun da alles eingerichtet ist, sieht das Ganze bei einer Anmeldung an Git dann so aus. Es wird der „push„-Befehl ausgeführt und je nachdem, ob der YubiKey verfügbar ist oder nicht wird der Zugriff erlaubt.
Ohne YubiKey
„Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct acces rights and the repository exists.“
Ohne YubiKey
Mit YubiKey
Mit YubiKey
Nach der Eingabe eurer persönlichen PIN für den YubiKey erhaltet ihr Zugriff auf das Git-Repository.
In diesem Beitrag möchte ich kurz aufzeigen, wie man ganz einfach für die Nextcloud eine Zwei-Faktor-Authentifizierung einrichten kann.
Cookie-Zustimmung verwalten
Wir verwenden Cookies, um unsere Website und unseren Service zu optimieren.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.