YubiKey 10 – Öffentlichen GPG-Schlüssel auf Linux-Server übertragen und für passwortlose Anmeldung nutzen

Das ist mittlerweile der 10 Beitrag der Serie über den YubiKey.
Hier geht es darum, wie man einen Linux-Server konfiguriert, damit man sich ohne Passwort-Eingabe nur mit einem YubiKey anmelden kann.

Ich nutze diese Art der Anmeldung seit ich einen YubiKey habe. Der Komfort ist einfach super. Bei der Anmeldung ist kein Passwort mehr einzugeben, sondern es ist lediglich der am PC angeschlossene YubiKey erforderlich.


SSH-Anmeldung nur für definierte Gruppe erlauben

SSH-Zugriff nur noch mir YubiKey erlauben

Einen neuen Benutzer anlegen mit Recht für SSH-Zugriff

Benutzer deaktivieren oder löschen

Passworteingabe zum Ausführen von sudo-Befehlen deaktivieren


Was ihr dafür benötigt sind lediglich euer exportierter öffentlicher Schlüssel und einen Admin-Zugang zum Server.

Euren öffentlichen Schlüssel müsst ihr in die Datei „~/.ssh/authorized_keys“ schreiben und schützen.
Anschließend ist die Datei „/etc/ssh/sshd_config“ noch ein wenig anzupassen.

In die schreibt bzw. kopiert ihr einfach euren öffentlichen Schüssel hinter in eine neue Zeile, gerne mit einem Kommentar für eine bessere Zuordnung.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDPFbvbwFIjSxU6o7lgr7xEaEbmKARa/1JaqzsMU1WLh/i519VQn/BN1BVHMTjxw2I/hNwG7YGpBUuhxAdiK53l/M...........

Ich habe bereits mehrere Artikel zu diesem Thema geschrieben. Die Artikel veranschaulichen an ein paar Beispielen, wofür diese Art der Anmeldung das alles genutzt werden kann.

Schritt 3: Git Server konfigurieren und bare-Repository einrichten

Schritt 4: Zugriff auf Git-Server ausschließlich mit YubiKey möglich

Passwortlose SSH-Anmeldung mit SSH-Schlüsselpaar oder YubiKey am Synology NAS

Ein paar hilfreiche Einstellungen, die die Administration der Linux-Server im Umgang mit den Keys und einem YubiKey etwas erleichtern möchte ich hier noch kurz aufzeigen.

SSH-Anmeldung nur für definierte Gruppe erlauben

Die Anmeldung mit SSH lässt sich auf eine definierte Gruppe einschränken. Das ist sicherlich sinnvoll, wenn viele Benutzer auf einem System angelegt sind und man den Zugriff auf das Terminal einschränken möchte, z.B. auf die Administratoren.

Zu diesem Zweck legen wir eine neue Gruppe für den SSH-Zugriff an

sudo groupadd -r sshadmin

Die bereits angelegten Benutzer auf dem Linux-System lassen sich mit dem Befehl der Gruppe hinzufügen.

sudo usermod -a -G sshadmin BENUTZERNAME

Damit auch wirklich nur diese Gruppe eine SSH-Sitzung starten darf, muss das in der „/etc/ssh/sshd_config“ mitgeteilt werden.
Tragt dazu in der Datei die folgende Zeile ein

sudo nano /etc/ssh/sshd_config

#Laesst nur Mitglieder der Gruppe "sshadmin" eine SSH-Verbindung herstellen
AllowGroups sshadmin

Speichert die Änderung und startet den SSH-Daemon neu.

sudo systemctl restart sshd.service

ACHTUNG, ab diesen Zeitpunkt ist der Zugriff per SSH auch wirklich nur noch für die Mitglieder der Gruppe erlaubt. Alle anderen werden abgewiesen.

Yubico - YubiKey 5C NFC - Two Factor Authentication USB...
Yubico Y-291 Yubikey 5Ci Schwarz

SSH-Zugriff nur noch mir YubiKey erlauben

Damit nur noch die Anmeldung mit einem Schlüsselpaar erlaubt ist, sind noch ein paar Einträge in der „/etc/ssh/sshd_config“ zu erstellen.
Prüft bei dieser Gelegenheit gleich die Datei.
! Die unten gezeigt „sshd_config“ erhebt keinen Anspruch auf Vollständigkeit. Prüft selbst noch einmal die Einträge, beovr ihr die Datei auf einem Systemn verwendet!

Seit euch sicher was ihr macht!
Arbeitet zur Sicherheit mit einer offenen SSH-Sitzung, die ihr nicht schließt. Diese aktive Sitzung ist normalerweise von einem Neustart des SSH-Daemons nicht betroffen.

###
# UsePAM
###
# 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



###
# ChallengeResponseAuthentication
###
# Specifies whether challenge-response authentication is allowed 
# (e.g. via PAM or though authentication styles # supported in login.conf(5)) 
# The default is ''yes''. 

ChallengeResponseAuthentication no


###
# X11Forwarding
###
# Specifies whether X11 forwarding is permitted. The argument must be ''yes'' or ''no''. 
# The default is ''no''. 

X11Forwarding no


### 
# PrintMotd
###
# Specifies whether sshd(8) should print /etc/motd when a user logs in interactively. 
# (On some systems it is # # also printed by the shell, /etc/profile, or equivalent.) 
# The default is ''yes''.

PrintMotd no


###
# LoginGraceTime
###
# The LoginGraceTime parameter specifies the time allowed for successful 
# authentication to the SSH server. The longer the Grace period is the 
# more open unauthenticated connections can exist. Like other session controls 
# in this session the Grace Period should be limited to appropriate organizational 
# limits to ensure the service is available for needed access. 

LoginGraceTime 1m


####
#ClientAliveInterval
###
# Sets a timeout interval in seconds after which if no data has been received from 
# the client, sshd(8) will send a message through the encrypted channel to request 
# a response from the client. The default is 0, indicating that these messages will 
# not be sent to the client. This option applies to protocol version 2 only.

ClientAliveInterval 600


###
# StrictModes
###
# Specifies whether sshd(8) should check file modes and ownership of the user's files 
# and home directory before accepting login. This is normally desirable because novices 
# sometimes accidentally leave their directory or files world-writable. 
# The default is ''yes''. 

StrictModes yes


###
# AllowTcpForwarding
###
# Specifies whether TCP forwarding is permitted. The default is ''yes''. 
# Note that disabling TCP forwarding does not improve security unless users are also 
# denied shell access, as they can always install their own forwarders.

AllowTcpForwarding no


###
# PermitEmptyPasswords
###
# When password authentication is allowed, it specifies whether the server allows 
# login to accounts with empty password strings. 
# The default is ''no''.

PermitEmptyPasswords no


###
# SSH Login Only For Group sshadmin
###
# Only members of goup "sshadmin" are allowed to establish a SSH connection to this server
AllowGroups sshadmin


###
# PasswordAuthentication
###
# Specifies whether password authentication is allowed. The default is ''yes''. 
# no = not required, SSH login is now only possible with SSH key
# yes = required, SSH login is possible with password

PasswordAuthentication no

Anschließend ist der SSH-Daemon neuzustarten

sudo systemctl restart sshd.service

Einen neuen Benutzer anlegen mit Recht für SSH-Zugriff

Ein neuer Benutzer lässt sich auf der Konsole einfach anlegen und auch gleich der sshadmin-Gruppe hinzufügen.
Des weitern wir der Benutzer auch gleich das Recht gewährt „sudo“ zu verwenden.

Für einen Raspberry Pi sieht das dann so aus:

  sudo adduser pi
  sudo usermod -a -G sshadmin pi
  sudo usermod -a -G adm pi
  sudo usermod -a -G dialout pi
  sudo usermod -a -G cdrom pi
  sudo usermod -a -G sudo pi
  sudo usermod -a -G audio pi
  sudo usermod -a -G video pi
  sudo usermod -a -G plugdev pi
  sudo usermod -a -G games pi
  sudo usermod -a -G users pi
  sudo usermod -a -G input pi
  sudo usermod -a -G netdev pi
  sudo usermod -a -G gpio pi
  sudo usermod -a -G i2c pi
  sudo usermod -a -G spi pi

Anschließend müsst ihr darauf achten, dass für den neue Benutzer sein öffentlicher Schlüssel für die Anmeldung in der „authorized_keys“ hinterlegt wird.
Fehlt dort der Schlüssel, funktioniert die Anmeldung, je nach Einstellung, nicht.

Benutzer deaktivieren oder löschen

Ab und zu sind Benutzer auf einem System schnell zu deaktivieren, um einen Zugriff auf ein System komplett zu verhindern.
Auf der Konsole kein Problem!

  sudo usermod -L pi
  sudo passwd -l pi

Alternativ könnt ihr den Benutzer auch komplett löschen. Da müsst ihr aber wirklich sicher sein, dass eine Löschung wirklich sinnvoll ist. Die erste Wahl ist eine Deaktivierung um auch eine Nachvollziehbarkeit zu gewährleisten (siehe Log Files)

  killall -u pi
  userdel -r pi

Passworteingabe zum Ausführen von sudo-Befehlen deaktivieren

Die Anmeldung wurde so konfiguriert, dass kein Passwort mehr erforderlich ist, sondern nur noch ein YubiKey vom System akzeptiert wird. Trotzdem muss vor dem Ausführen der sudo-Befehle noch immer das Passwort eingegeben werden, was recht umständlich ist. Schließlich hat sich der berechtigte Benutzer schon am System legitimiert, mit einer sicheren Anmeldung, seinem YubiKey.
Zudem wurde auch nur einem ausgewählten Kreis an Benutzern der Zugriff via SSH gewährt.

Möchte man die Passworteingabe für die sudo-Befehle deaktivieren muss die Datei „/etc/sudoers“ angepasst werden. Jedoch geht das Ändern nur mit einem speziellen Editor, dem „viduso„.

sudo visudo

In der Datei such t ihr müsst ihr den bestehenden Eintrag aus kommentieren und durch einen neuen ersetzen.

  # aus kommentieren von
  %sudo  ALL=(ALL:ALL) ALL

  # einfügen von
  %sudo  ALL=(ALL) NOPASSWD:ALL

Nach der Anpassung ist die Eingabe des Passworts zum ausführen von „sudo-Befehlen“ nicht mehr notwendig.

Im nächsten Beitrag wird ein Windows System so konfiguriert, dass eine Anmeldung mit einem YubiKey an einem vorbereiteten Linux-Server funktioniert.
Windows System anpassen zur Anmeldung mit einem YubiKey an einem Linux-Server

Anzeige/Werbung

(**) Produktpreise und -verfügbarkeit sind zum angegebenen Datum / Uhrzeit korrekt und können sich ändern. Alle Preis- und Verfügbarkeitsinformationen auf https://www.amazon.de/ zum Zeitpunkt des Kaufs gelten für den Kauf dieses Produkts.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.