How To Set Up Multi-Factor Authentication for SSH on CentOS 7

Introduction

Ein Authentifizierungsfaktor ist eine einzelne Information, die verwendet wird, um zu beweisen, dass man die Rechte hat, eine Aktion auszuführen, wie z.B. sich bei einem System anzumelden. Ein Authentifizierungskanal ist die Art und Weise, wie ein Authentifizierungssystem einen Faktor an den Benutzer liefert oder vom Benutzer eine Antwort verlangt. Passwörter und Sicherheits-Token sind Beispiele für Authentifizierungsfaktoren; Computer und Telefone sind Beispiele für Kanäle.

SSH verwendet standardmäßig Passwörter zur Authentifizierung, und die meisten SSH-Härtungsanweisungen empfehlen stattdessen die Verwendung eines SSH-Schlüssels. Dies ist jedoch immer noch nur ein einziger Faktor. Wenn ein bösartiger Akteur Ihren Computer kompromittiert hat, kann er Ihren Schlüssel verwenden, um auch Ihre Server zu kompromittieren.

In diesem Lernprogramm werden wir eine Multi-Faktor-Authentifizierung einrichten, um dies zu verhindern. Die Multi-Faktor-Authentifizierung (MFA) erfordert mehr als einen Faktor, um sich zu authentifizieren bzw. anzumelden. Das bedeutet, dass ein bösartiger Akteur mehrere Dinge kompromittieren müsste, z. B. Ihren Computer und Ihr Telefon, um sich Zugang zu verschaffen. Die verschiedenen Arten von Faktoren werden oft wie folgt zusammengefasst:

1. Etwas, das Sie wissen, wie ein Passwort oder eine Sicherheitsfrage
2. Etwas, das Sie haben, wie eine Authenticator-App oder ein Sicherheits-Token
3. Etwas, das Sie sind, wie Ihr Fingerabdruck oder Ihre Stimme

Ein gemeinsamer Faktor ist eine OATH-TOTP-App, wie Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) ist ein offenes Protokoll, das ein Einmal-Passwort generiert, in der Regel eine 6-stellige Zahl, die alle 30 Sekunden wiederholt wird.

In diesem Artikel wird erläutert, wie man die SSH-Authentifizierung mit einer OATH-TOTP-App zusätzlich zu einem SSH-Schlüssel aktiviert. Die Anmeldung bei Ihrem Server über SSH erfordert dann zwei Faktoren über zwei Kanäle und ist damit sicherer als ein Passwort oder ein SSH-Schlüssel allein. Darüber hinaus gehen wir auf einige weitere Anwendungsfälle für MFA und einige hilfreiche Tipps und Tricks ein.

Voraussetzungen

Um diesem Tutorial zu folgen, benötigen Sie:

• Einen CentOS 7-Server mit einem sudo-Nicht-Root-Benutzer und einem SSH-Schlüssel, den Sie mit diesem Tutorial zur Ersteinrichtung des Servers einrichten können.
• Ein Smartphone oder Tablet mit einer installierten OATH-TOTP-App, wie z.B. Google Authenticator (iOS, Android).

Schritt 1 – Installation von Googles PAM

In diesem Schritt werden wir Googles PAM installieren und konfigurieren.

PAM, was für Pluggable Authentication Module steht, ist eine Authentifizierungsinfrastruktur, die auf Linux-Systemen verwendet wird, um einen Benutzer zu authentifizieren. Da Google eine OATH-TOTP-Anwendung entwickelt hat, hat es auch ein PAM entwickelt, das TOTPs generiert und mit jeder OATH-TOTP-Anwendung wie Google Authenticator oder Authy vollständig kompatibel ist.

Zuerst müssen wir das EPEL (Extra Packages for Enterprise Linux) Repo hinzufügen.

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Nächste Schritte: Installieren Sie das PAM. Sie werden möglicherweise aufgefordert, den EPEL-Schlüssel zu akzeptieren, wenn Sie das Repo zum ersten Mal verwenden. Sobald Sie den Schlüssel akzeptiert haben, werden Sie nicht mehr dazu aufgefordert.

sudo yum install google-authenticator

Nach der Installation des PAMs verwenden wir eine Hilfsanwendung, die mit dem PAM geliefert wird, um einen TOTP-Schlüssel für den Benutzer zu generieren, dem Sie einen zweiten Faktor hinzufügen möchten. Dieser Schlüssel wird für jeden einzelnen Benutzer generiert, nicht systemweit. Das bedeutet, dass jeder Benutzer, der eine TOTP-Authentifizierungsanwendung verwenden möchte, sich anmelden und die Hilfsanwendung ausführen muss, um seinen eigenen Schlüssel zu erhalten; Sie können sie nicht nur einmal ausführen, um sie für alle zu aktivieren (aber es gibt einige Tipps am Ende dieses Tutorials, um MFA für viele Benutzer einzurichten oder zu verlangen).

Starten Sie die Initialisierungsanwendung.

google-authenticator

Nach der Ausführung des Befehls werden Ihnen einige Fragen gestellt. Die erste fragt, ob die Authentifizierungs-Tokens zeitbasiert sein sollen.

Output
Do you want authentication tokens to be time-based (y/n) y

Dieses PAM erlaubt zeitbasierte oder sequenzbasierte Tokens. Bei der Verwendung von sequenzbasierten Token beginnt der Code an einem bestimmten Punkt und wird dann nach jeder Verwendung erhöht. Bei zeitbasierten Token ändert sich der Code nach Ablauf einer bestimmten Zeit zufällig. Wir bleiben bei den zeitbasierten Token, weil Anwendungen wie Google Authenticator dies erwarten. Beantworten Sie also die Frage y mit Ja.

Nach der Beantwortung dieser Frage wird eine Menge Ausgabe eingeblendet, darunter ein großer QR-Code. Verwenden Sie nun Ihre Authenticator-App auf Ihrem Telefon, um den QR-Code zu scannen, oder geben Sie den geheimen Schlüssel manuell ein. Wenn der QR-Code zu groß zum Scannen ist, können Sie die URL über dem QR-Code verwenden, um eine kleinere Version zu erhalten. Nach dem Hinzufügen wird in Ihrer App ein sechsstelliger Code angezeigt, der sich alle 30 Sekunden ändert.

Hinweis: Achten Sie darauf, dass Sie den geheimen Schlüssel, den Verifizierungscode und die Wiederherstellungscodes an einem sicheren Ort aufbewahren, z. B. in einem Passwortmanager. Die Wiederherstellungscodes sind die einzige Möglichkeit, den Zugang wiederzuerlangen, wenn Sie z. B. den Zugang zu Ihrer TOTP-App verlieren.

Die verbleibenden Fragen informieren den PAM über seine Funktionsweise. Wir gehen sie der Reihe nach durch.

Output
Do you want me to update your "/home/sammy/.google_authenticator" file (y/n) y

Dies schreibt den Schlüssel und die Optionen in die Datei .google_authenticator. Wenn du nein sagst, wird das Programm beendet und nichts geschrieben, was bedeutet, dass der Authentifikator nicht funktioniert.

Output
Do you want to disallow multiple uses of the same authenticationtoken? This restricts you to one login about every 30s, but it increasesyour chances to notice or even prevent man-in-the-middle attacks (y/n) y

Wenn du hier mit ja antwortest, verhinderst du einen Wiederholungsangriff, indem du jeden Code sofort nach der Benutzung ablaufen lässt. Dadurch wird verhindert, dass ein Angreifer einen Code, den Sie gerade benutzt haben, abfängt und sich damit anmeldet.

Output
By default, tokens are good for 30 seconds. In order to compensate forpossible time-skew between the client and the server, we allow an extratoken before and after the current time. If you experience problems withpoor time synchronization, you can increase the window from its defaultsize of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n

Wenn Sie hier mit Ja antworten, sind bis zu 8 gültige Codes in einem Zeitfenster von vier Minuten möglich. Wenn Sie mit Nein antworten, sind nur 3 gültige Codes in einem gleitenden Zeitfenster von 1:30 Minuten möglich. Sofern Sie keine Probleme mit dem 1:30-Minuten-Fenster haben, ist die Antwort „Nein“ die sicherere Wahl.

Output
If the computer that you are logging into isn't hardened against brute-forcelogin attempts, you can enable rate-limiting for the authentication module.By default, this limits attackers to no more than 3 login attempts every 30s.Do you want to enable rate-limiting (y/n) y

Die Ratenbegrenzung bedeutet, dass ein Angreifer nur eine bestimmte Anzahl von Versuchen unternehmen kann, bevor er blockiert wird. Wenn Sie die Ratenbeschränkung noch nicht direkt in SSH konfiguriert haben, ist dies eine großartige Abhärtungstechnik.

Hinweis: Wenn Sie Ihren geheimen Schlüssel nach Abschluss dieser Einrichtung sichern möchten, können Sie die Datei ~/.google-authenticator an einen vertrauenswürdigen Ort kopieren. Von dort aus können Sie ihn auf weiteren Systemen bereitstellen oder nach einer Sicherung erneut bereitstellen.

Nachdem Googles PAM nun installiert und konfiguriert ist, besteht der nächste Schritt darin, SSH für die Verwendung Ihres TOTP-Schlüssels zu konfigurieren. Wir müssen SSH über das PAM informieren und SSH dann so konfigurieren, dass es es verwendet.

Schritt 2 – Konfiguration von OpenSSH

Da wir SSH-Änderungen über SSH vornehmen werden, ist es wichtig, dass Sie Ihre erste SSH-Verbindung niemals schließen. Eröffnen Sie stattdessen eine zweite SSH-Sitzung, um Tests durchzuführen. So vermeiden Sie, dass Sie sich selbst von Ihrem Server aussperren, falls Sie einen Fehler in Ihrer SSH-Konfiguration gemacht haben. Sobald alles funktioniert, können Sie alle Sitzungen sicher schließen.

Zu Beginn bearbeiten wir die Konfigurationsdatei sshd. Hier verwenden wir nano, das unter CentOS nicht standardmäßig installiert ist. Sie können ihn mit sudo yum install nano installieren oder Ihren bevorzugten alternativen Texteditor verwenden.

sudo nano /etc/pam.d/sshd

Fügen Sie die folgende Zeile am Ende der Datei ein.

. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Das nullok-Wort am Ende der letzten Zeile sagt dem PAM, dass diese Authentifizierungsmethode optional ist. Dies ermöglicht es Benutzern ohne OATH-TOTP-Token, sich trotzdem mit ihrem SSH-Schlüssel anzumelden. Sobald alle Benutzer ein OATH-TOTP-Token haben, können Sie nullok aus dieser Zeile entfernen, um MFA obligatorisch zu machen.

Speichern Sie die Datei und schließen Sie sie.

Als Nächstes werden wir SSH so konfigurieren, dass diese Art der Authentifizierung unterstützt wird. Öffnen Sie die SSH-Konfigurationsdatei zur Bearbeitung.

sudo nano /etc/ssh/sshd_config

Suchen Sie nach ChallengeResponseAuthentication Zeilen. Kommentieren Sie die Zeile no aus und heben Sie die Kommentierung der Zeile no auf.

. . .# Change to no to disable s/key passwordsChallengeResponseAuthentication yes#ChallengeResponseAuthentication no. . .

Speichern und schließen Sie die Datei und starten Sie dann SSH neu, um die Konfigurationsdateien neu zu laden. Der Neustart des sshd-Dienstes schließt keine offenen Verbindungen, so dass Sie nicht riskieren, sich mit diesem Befehl selbst auszusperren.

sudo systemctl restart sshd.service

Um zu testen, ob bisher alles funktioniert, öffnen Sie ein anderes Terminal und versuchen Sie, sich über SSH anzumelden. Wenn Sie zuvor einen SSH-Schlüssel erstellt haben und diesen verwenden, werden Sie feststellen, dass Sie weder das Passwort Ihres Benutzers noch den MFA-Verifizierungscode eingeben müssen. Das liegt daran, dass ein SSH-Schlüssel standardmäßig alle anderen Authentifizierungsoptionen außer Kraft setzt. Andernfalls hätten Sie eine Aufforderung zur Eingabe des Kennworts und des Verifizierungscodes erhalten müssen.

Wenn Sie sicherstellen möchten, dass das, was Sie bisher getan haben, funktioniert, navigieren Sie in Ihrer geöffneten SSH-Sitzung zu ~/.ssh/ und benennen Sie die Datei authorized_keys vorübergehend um, öffnen Sie eine neue Sitzung und melden Sie sich mit unserem Kennwort und Verifizierungscode an.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Wenn Sie sichergestellt haben, dass Ihr TOTP-Token funktioniert, benennen Sie die Datei „authorized_keys.bak‘ wieder in die ursprüngliche Datei um.

mv authorized_keys.bak authorized_keys

Als Nächstes müssen wir einen SSH-Schlüssel als einen Faktor und den Verifizierungscode als zweiten Faktor aktivieren und SSH mitteilen, welche Faktoren verwendet werden sollen, und verhindern, dass der SSH-Schlüssel alle anderen Typen außer Kraft setzt.

Schritt 3 – SSH für MFA sensibilisieren

Öffnen Sie erneut die Konfigurationsdatei sshd.

sudo nano /etc/ssh/sshd_config

Fügen Sie die folgende Zeile am Ende der Datei hinzu. Damit wird SSH mitgeteilt, welche Authentifizierungsmethoden erforderlich sind. Diese Zeile teilt SSH mit, dass wir einen SSH-Schlüssel und entweder ein Passwort oder einen Verifizierungscode (oder alle drei) benötigen.

. . .# Added by DigitalOcean build processClientAliveInterval 120ClientAliveCountMax 2AuthenticationMethods publickey,password publickey,keyboard-interactive

Speichern Sie die Datei und schließen Sie sie.

Öffnen Sie als Nächstes die PAM sshd-Konfigurationsdatei erneut.

sudo nano /etc/pam.d/sshd

Finden Sie die Zeile auth substack password-auth am Anfang der Datei. Kommentieren Sie sie aus, indem Sie ein #-Zeichen als erstes Zeichen in die Zeile einfügen. Dadurch wird PAM angewiesen, nicht nach einem Passwort zu fragen.

. . .#auth substack password-auth. . .

Speichern und schließen Sie die Datei und starten Sie dann SSH neu.

sudo systemctl restart sshd.service

Versuchen Sie nun, sich mit einer anderen Sitzung erneut beim Server anzumelden. Anders als beim letzten Mal sollte SSH Sie nach Ihrem Bestätigungscode fragen. Wenn Sie ihn eingeben, werden Sie angemeldet. Auch wenn Sie keinen Hinweis darauf sehen, dass Ihr SSH-Schlüssel verwendet wurde, hat Ihr Anmeldeversuch zwei Faktoren verwendet. Wenn Sie dies überprüfen wollen, können Sie nach dem SSH-Befehl -v (für verbose) einfügen:

Example SSH output\
. . .debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering RSA public key: /Users/sammy/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 279Authenticated with partial success.debug1: Authentications that can continue: keyboard-interactivedebug1: Next authentication method: keyboard-interactiveVerification code:

Am Ende der Ausgabe sehen Sie, dass SSH Ihren SSH-Schlüssel verwendet und dann nach dem Bestätigungscode fragt. Sie können sich nun über SSH mit einem SSH-Schlüssel und einem Einmalpasswort anmelden. Wenn Sie alle drei Authentifizierungsarten erzwingen wollen, können Sie den nächsten Schritt ausführen.

Schritt 4 – Hinzufügen eines dritten Faktors (optional)

In Schritt 3 haben wir die zugelassenen Authentifizierungsarten in der Datei sshd_config aufgeführt:

1. publickey (SSH-Schlüssel)
2. password publickey (Passwort)
3. keyboard-interactive (Verifizierungscode)

Obwohl wir drei verschiedene Faktoren aufgelistet haben, sind mit den bisher gewählten Optionen nur ein SSH-Schlüssel und der Verifizierungscode möglich. Wenn Sie alle drei Faktoren (SSH-Schlüssel, Passwort und Verifizierungscode) haben möchten, können Sie mit einer kurzen Änderung alle drei aktivieren.

Öffnen Sie die PAM sshd-Konfigurationsdatei.

sudo nano /etc/pam.d/sshd

Suchen Sie die Zeile, die Sie zuvor auskommentiert haben, #auth substack password-auth, und entfernen Sie das Zeichen # aus der Zeile. Speichern und schließen Sie die Datei. Starten Sie nun SSH erneut.

sudo systemctl restart sshd.service

Durch Aktivieren der Option auth substack password-auth fragt PAM nun nicht nur nach einem SSH-Schlüssel und einem Verifizierungscode, sondern auch nach einem Passwort, was vorher funktioniert hat. Jetzt können wir etwas, das wir kennen (Passwort), und zwei verschiedene Arten von Dingen, die wir haben (SSH-Schlüssel und Verifizierungscode), über zwei verschiedene Kanäle verwenden.

So weit hat dieser Artikel beschrieben, wie man MFA mit einem SSH-Schlüssel und einem zeitbasierten Einmalpasswort aktiviert. Wenn das alles ist, was Sie brauchen, können Sie hier aufhören. Dies ist jedoch nicht die einzige Möglichkeit, eine Multi-Faktor-Authentifizierung durchzuführen. Im Folgenden finden Sie einige weitere Möglichkeiten, dieses PAM-Modul für die Multi-Faktor-Authentifizierung zu verwenden, sowie einige Tipps und Tricks für die Wiederherstellung, die automatisierte Verwendung und mehr.

Tipp 1 – Wiederherstellung des Zugangs

Wie bei jedem System, das Sie härten und sichern, sind Sie für die Verwaltung dieser Sicherheit verantwortlich. In diesem Fall bedeutet das, dass Sie Ihren SSH-Schlüssel oder Ihren geheimen TOTP-Schlüssel nicht verlieren und sicherstellen müssen, dass Sie Zugang zu Ihrer TOTP-App haben. Manchmal kann es jedoch passieren, dass Sie die Kontrolle über die Schlüssel oder Anwendungen verlieren, die Sie für den Zugang benötigen.

Verlust eines SSH-Schlüssels oder eines geheimen TOTP-Schlüssels

Wenn Sie Ihren SSH-Schlüssel oder Ihren geheimen TOTP-Schlüssel verlieren, kann die Wiederherstellung in mehrere Schritte unterteilt werden. Der erste besteht darin, sich wieder anzumelden, ohne den Verifizierungscode zu kennen, und der zweite darin, den geheimen Schlüssel zu finden oder ihn für die normale MFA-Anmeldung zu regenerieren.

Um sich nach dem Verlust des geheimen Schlüssels, der den Verifizierungscode auf einem DigitalOcean-Droplet generiert, anzumelden, können Sie einfach die virtuelle Konsole von Ihrem Dashboard aus verwenden, um sich mit Ihrem Benutzernamen und Passwort anzumelden.

Ansonsten benötigen Sie einen administrativen Benutzer mit sudo-Zugriff; stellen Sie sicher, dass Sie MFA für diesen Benutzer nicht aktivieren, sondern nur einen SSH-Schlüssel verwenden. Wenn Sie oder ein anderer Benutzer seinen geheimen Schlüssel verlieren und sich nicht mehr anmelden können, kann sich der administrative Benutzer anmelden und dabei helfen, den Schlüssel für jeden Benutzer mit sudo wiederherzustellen oder zu regenerieren.

Wenn Sie eingeloggt sind, gibt es zwei Möglichkeiten, das TOTP-Geheimnis zu erhalten:

1. Wiederherstellen des vorhandenen Schlüssels
2. Generieren eines neuen Schlüssels

Im Home-Verzeichnis jedes Nutzers sind der geheime Schlüssel und die Google Authenticator-Einstellungen in ~/.google-authenticator gespeichert. Die allererste Zeile dieser Datei ist ein geheimer Schlüssel. Ein schneller Weg, den Schlüssel zu erhalten, ist die Ausführung des folgenden Befehls, der die erste Zeile der Datei google-authenticator (d. h. den geheimen Schlüssel) anzeigt. Nehmen Sie dann diesen geheimen Schlüssel und geben Sie ihn manuell in eine TOTP-Anwendung ein.

head -n 1 /home/sammy/.google_authenticator

Wenn es einen Grund gibt, den vorhandenen Schlüssel nicht zu verwenden (z. B. weil es nicht möglich ist, den geheimen Schlüssel mit dem betroffenen Benutzer sicher zu teilen, oder weil der vorhandene Schlüssel kompromittiert wurde), können Sie die Datei ~/.google-authenticator vollständig entfernen. Dadurch kann sich der Benutzer wieder mit nur einem einzigen Faktor anmelden, vorausgesetzt, Sie haben MFA nicht durch Entfernen von „nullok“ in der Datei „/etc/pam.d/sshd“ erzwungen. Sie können dann google-authenticator ausführen, um einen neuen Schlüssel zu generieren.

Verlust des Zugriffs auf die TOTP-App

Wenn Sie sich bei Ihrem Server anmelden müssen, aber keinen Zugriff auf Ihre TOTP-App haben, um Ihren Verifizierungscode zu erhalten, können Sie sich immer noch mit den Wiederherstellungscodes anmelden, die bei der ersten Erstellung Ihres geheimen Schlüssels angezeigt wurden. Beachten Sie, dass diese Wiederherstellungscodes nur einmal verwendet werden können. Sobald ein Code zur Anmeldung verwendet wurde, kann er nicht mehr als Verifizierungscode verwendet werden.

Tipp 2 – Ändern der Authentifizierungseinstellungen

Wenn Sie Ihre MFA-Einstellungen nach der Erstkonfiguration ändern möchten, können Sie, anstatt eine neue Konfiguration mit den aktualisierten Einstellungen zu erstellen, einfach die Datei ~/.google-authenticator bearbeiten. Diese Datei ist folgendermaßen aufgebaut:

<secret key><options><recovery codes>

Optionen, die in dieser Datei festgelegt werden, haben eine Zeile im Abschnitt „Optionen“; wenn Sie bei der Ersteinrichtung eine bestimmte Option mit „Nein“ beantwortet haben, wird die entsprechende Zeile aus der Datei ausgeschlossen.

Hier sind die Änderungen, die Sie an dieser Datei vornehmen können:

• Um sequenzielle Codes anstelle von zeitbasierten Codes zu aktivieren, ändern Sie die Zeile " TOTP_AUTH in " HOTP_COUNTER 1.
• Um die mehrfache Verwendung eines einzelnen Codes zu ermöglichen, entfernen Sie die Zeile " DISALLOW_REUSE.
• Um das Ablauffenster für Codes auf 4 Minuten zu erweitern, fügen Sie die Zeile " WINDOW_SIZE 17 hinzu.
• Um mehrere fehlgeschlagene Anmeldungen zu deaktivieren (Ratenbegrenzung), entfernen Sie die Zeile " RATE_LIMIT 3 30.
• Um den Schwellenwert der Ratenbegrenzung zu ändern, suchen Sie die Zeile " RATE_LIMIT 3 30 und passen Sie die Zahlen an. Die 3 im Original gibt die Anzahl der Versuche über einen bestimmten Zeitraum an, und die 30 gibt den Zeitraum in Sekunden an.
• Um die Verwendung von Wiederherstellungscodes zu deaktivieren, entfernen Sie die fünf achtstelligen Codes am Ende der Datei.

Tipp 3 – Vermeidung von MFA für einige Konten

Es kann eine Situation geben, in der ein einzelner Benutzer oder einige Dienstkonten (d. h. Konten, die von Anwendungen und nicht von Menschen verwendet werden) SSH-Zugriff benötigen, ohne dass MFA aktiviert ist. Einige Anwendungen, die SSH verwenden, wie z. B. einige FTP-Clients, unterstützen möglicherweise keine MFA. Wenn eine Anwendung keine Möglichkeit hat, den Verifizierungscode anzufordern, kann die Anfrage stecken bleiben, bis die SSH-Verbindung eine Zeitüberschreitung aufweist.

Solange einige Optionen in /etc/pam.d/sshd korrekt eingestellt sind, können Sie steuern, welche Faktoren für jeden einzelnen Benutzer verwendet werden.

Um MFA für einige Konten und nur SSH-Schlüssel für andere zuzulassen, stellen Sie sicher, dass die folgenden Einstellungen in /etc/pam.d/sshd aktiv sind.

#%PAM-1.0auth required pam_sepermit.so#auth substack password-auth. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Hier ist auth substack password-auth auskommentiert, weil Passwörter deaktiviert werden müssen. MFA kann nicht erzwungen werden, wenn einige Konten MFA deaktiviert haben sollen, also lassen Sie die Option nullok in der letzten Zeile.

Nach dem Einrichten dieser Konfiguration führen Sie einfach google-authenticator für alle Benutzer aus, die MFA benötigen, und führen Sie es nicht für Benutzer aus, bei denen nur SSH-Schlüssel verwendet werden sollen.

Tipp 4 – Automatisieren der Einrichtung mit Konfigurationsmanagement

Viele Systemadministratoren verwenden Konfigurationsmanagement-Tools wie Puppet, Chef oder Ansible, um ihre Systeme zu verwalten. Wenn Sie ein solches System verwenden möchten, um einen geheimen Schlüssel einzurichten, wenn ein neues Benutzerkonto erstellt wird, gibt es eine Methode, dies zu tun.

google-authenticator unterstützt Befehlszeilenschalter, um alle Optionen in einem einzigen, nicht interaktiven Befehl festzulegen. Um alle Optionen zu sehen, können Sie google-authenticator --help eingeben. Im Folgenden finden Sie den Befehl, mit dem Sie alles wie in Schritt 1 beschrieben einrichten würden:

google-authenticator -t -d -f -r 3 -R 30 -W

Dies beantwortet alle Fragen, die wir manuell beantwortet haben, speichert sie in einer Datei und gibt dann den geheimen Schlüssel, den QR-Code und die Wiederherstellungscodes aus. (Wenn Sie das Flag -q hinzufügen, erfolgt keine Ausgabe.) Wenn Sie diesen Befehl automatisiert verwenden, stellen Sie sicher, dass Sie den geheimen Schlüssel und/oder die Wiederherstellungscodes erfassen und dem Benutzer zur Verfügung stellen.

Tipp 5 – Erzwingen von MFA für alle Benutzer

Wenn Sie MFA für alle Benutzer erzwingen möchten, selbst bei der ersten Anmeldung, oder wenn Sie sich nicht darauf verlassen möchten, dass Ihre Benutzer ihre eigenen Schlüssel generieren, gibt es eine einfache Möglichkeit, dies zu tun. Sie können einfach dieselbe .google-authenticator-Datei für jeden Benutzer verwenden, da in der Datei keine benutzerspezifischen Daten gespeichert sind.

Zu diesem Zweck muss ein privilegierter Benutzer nach der anfänglichen Erstellung der Konfigurationsdatei die Datei in das Stammverzeichnis eines jeden Home-Verzeichnisses kopieren und ihre Berechtigungen auf den entsprechenden Benutzer ändern. Sie können die Datei auch nach /etc/skel/ kopieren, damit sie bei der Erstellung automatisch in das Heimatverzeichnis eines neuen Benutzers kopiert wird.

Warnung: Dies kann ein Sicherheitsrisiko darstellen, da alle Benutzer denselben zweiten Faktor verwenden. Das bedeutet, dass es so ist, als ob jeder Benutzer nur einen Faktor hätte, wenn er ausspioniert wird. Beachten Sie dies, wenn Sie diesen Ansatz verwenden möchten.

Eine andere Methode, um die Erstellung des geheimen Schlüssels eines Benutzers zu erzwingen, ist die Verwendung eines Bash-Skripts, das:

1. ein TOTP-Token erstellt,
2. den Benutzer auffordert, die Google Authenticator-App herunterzuladen und den angezeigten QR-Code zu scannen, und
3. die google-authenticatorAnwendung für ihn ausführt, nachdem überprüft wurde, ob die .google-authenticator-Datei bereits existiert.

Um sicherzustellen, dass das Skript ausgeführt wird, wenn sich ein Benutzer anmeldet, können Sie es .bash_login nennen und im Stammverzeichnis des Home-Verzeichnisses des Benutzers ablegen.

Fazit

Das heißt, dass Sie mit zwei Faktoren (einem SSH-Schlüssel und einem MFA-Token) über zwei Kanäle (Ihren Computer und Ihr Telefon) es einem externen Agenten sehr schwer gemacht haben, sich mit roher Gewalt über SSH Zugang zu Ihrem Computer zu verschaffen, und dass Sie die Sicherheit Ihres Computers erheblich erhöht haben.