SSH-Server mit Zwei-Faktor-Authentifizierung (2FA) auf Debian einrichten

Die Zwei-Faktor-Authentifizierung für den SSH Login bietet eine zusätzliche Sicherheitsebene. Bei der Zwei-Faktor-Authentifizierung wird zum Systembenutzerkennwort ein weiteres Kennwort erforderlich, ein PIN oder auch bekannt als OTP (One-Time-Password), es ist ein sechsstelliger Code der auf einem Mobilgerät angezeigt wird. Dadurch wird eine stärkere Authentifizierungsmethode für den Zugang zum Server erreicht.

In diesem Tutorial wird gezeigt, wie der SSH-Server mit Zwei-Faktor-Authentifizierung (2FA) abgesichert wird, für SSH Schlüsselbasierte Authentifizierung bei der SSH Keys verwendet werden.

Systemvoraussetzung

• Debian 10 (buster) Ubuntu 20.04 (Focal Fossa), Linux Mint 20
• Ein sudo privilegierter User Account mit $home Verzeichnis
• Authentifizierung mittels SSH Key (publickey) ~/.ssh/authorized_keys

  Wichtig! es wird empfohlen, sich während der Konfiguration der Authentifizierungseinstellungen eine zweite Terminalsitzung offen zu halten. Auf diese Weise wird man vom System nicht ausgesperrt, wenn die Verbindung beim Testen getrennt wird, weil etwa die Konfiguration noch nicht vollständig ist.

  Im weiteren Verlauf werden wir nicht mehr root sein, sondern als Voraussetzung im Rahmen dieses Tutorials weiter nur noch mit sudo arbeiten. Bei Debian muss möglicherweise das sudo Paket erst installiert werden.

Falls sudo nicht vorliegt, wird das sudo Paket als root installiert.

$ su -
Password:
apt install sudo

Dann unserem Beispiel „john“ die sudo-Berechtigungen erteilen.

$ usermod -aG sudo john

Google Authenticator PAM-Modul Installation

Um den SSH-Server für die Zwei-Faktor-Authentifizierung einzurichten, wird das Google Authenticator PAM-Modul auf dem Debian System installiert. Wir sind als nicht-root, mit john eingeloggt dieser nun Mitglied der Gruppe sudo ist.

$ sudo apt install -y libpam-google-authenticator

Führe nach der Installation des Google Authenticator den folgenden Befehl aus.

$ google-authenticator

Während der Ausführung müssen einige Fragen wie unten gezeigt beantwortet werden.

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

Warning: pasting the following URL into your browser exposes the OTP secret to Google:
  https://www.google.com/chart?XYZl=otpauth://totp/root@debian%3Fsecret%34YNE6ZI3XCLUQLBD862UR6NAL2A%36ixxuer%3Ddebian

Drücke y und die Enter Taste um fortzufahren. Im folgenden wird im Terminal ein QR-Code angezeigt werden.

Öffne als nächstes die Google Authenticator App auf dem Handy und scanne den QR-Code im Terminal, mit dem + unten rechts. Alternativ kann man über den Link oben den QR-Sicherheitscode im Browser öffnen.

In der Ausgabe oben ist auch der geheime TOTP Schlüssel, den Bestätigungscode und die Notrufcodes zu sehen. Es wird empfohlen, diese für die spätere Verwendung an einem sicheren Ort aufzubewahren.

Beantworte als nächstes alle Fragen mit y um die Google Authenticator-Konfigurationsdatei wie unten gezeigt zu aktualisieren.

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

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

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) y

If the computer that you are logging into isn't hardened against brute-force
login 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 Datei .google_authenticator im $home Verzeichnis ist für die 2FA Authentifizierung erforderlich.

SSH für die Verwendung von Google Authenticator Konfigurieren

Als nächstes muss der SSH-Server für die Verwendung von Google Authenticator konfiguriert werden, in dem wir sshd_config bearbeiten.

$ sudo vi /etc/ssh/sshd_config

Für die 2FA Authentifizierung werden folgende Zeilen benötigt.

PermitRootLogin prohibit-password
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes
UseDNS no
AuthenticationMethods publickey,keyboard-interactive password,keyboard-interactive

Die geänderte SSH-Dienst Konfiguration übernehmen.

$ sudo systemctl restart sshd

SSH Schlüsselbasierte Authentifizierung

Insbesondere Linux-Systemadministratoren sollten statt Passwörter SSH-Keys als Authentifizierungsmethode verwenden, wie es in obiger sshd_config konfiguriert ist. Eine Anleitung für die SSH-Public-Key-Authentifizierung gibt es hier. In unserem Beispiel soll der User john sich mit SSH-Key und 2FA anmelden.

Als nächstes müssen die PAM-Regeln für den SSH-Dienst in der Datei /etc/pam.d/sshd definiert werden.

$ sudo vi /etc/pam.d/sshd

Die Zeile @include common-auth mit # auskommentieren und nachfolgend zwei PAM-Regeln hinzufügen.

# Standard Un*x authentication.
#@include common-auth
auth  required  pam_google_authenticator.so nullok
auth  required  pam_permit.so

  Das Wort nullok am Ende der Zeile teilt PAM mit, dass diese Authentifizierungsmethode optional ist. Dadurch können sich Benutzer ohne OATH-TOTP-Token weiterhin mit nur dem SSH-Key anmelden. Sobald alle Benutzer über ein OATH-TOTP-Token verfügen, kann man nullok aus dieser Zeile entfernen, um 2FA obligatorisch zu machen. Die zweite Zeile mit pam_permit.so ist erforderlich, um die Authentifizierung zu ermöglichen, auch wenn ein Benutzer kein 2FA-Token verwendet.

Bei der Anmeldung benötigt jede Methode ein SUCCESS, um die Authentifizierung zu ermöglichen. Wenn ein Benutzer das 2FA-Authentifizierungstool nicht verwendet, gibt die Verwendung der Option nullok ein IGNORE für die interaktive Tastaturauthentifizierung zurück. pam_permit.so gibt dann SUCCESS zurück und ermöglicht die Fortsetzung der Authentifizierung.

SSH Login mit Zwei-Faktor-Authentifizierung Testen

Der SSH-Server ist jetzt mit Zwei-Faktor-Authentifizierung konfiguriert, damit ist nun die Gelegenheit gekommen es mit john zu testen.

$ ssh -v john@10.0.0.7
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\john/.ssh/debian ECDSA SHA256:cxoaQ9ccAAqS563BnOnFf2Ru6I3dc5uAeblO/8ua5Md explicit
debug1: Server accepts key: C:\\Users\\john/.ssh/debian ECDSA SHA256:cxoaQ9ccAAqS563BnOnFf2Ru6I3dc5uAeblO/8ua5Md explicit
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
Verification code:

Troubleshooting

Gibt es Fehler bei der Authentifizierung mit 2FA, kann für des PAM-Modul die debug Funktion aktiviert werden.

auth required pam_google_authenticator.so debug nullok

Anschliessend öffnet man die Logdatei auth.log

$ sudo less /var/log/auth.log

Mit debug werden Fehler in der Authentifizierung rasch erkannt.

Oct 22 17:59:32 debian sshd(pam_google_authenticator)[3938]: debug: shared secret in "/home/john/.google_authenticator" processed
Oct 22 17:59:32 debian sshd(pam_google_authenticator)[3938]: Invalid verification code for john
Oct 22 17:59:32 debian sshd(pam_google_authenticator)[3938]: debug: "/home/john/.google_authenticator" written
Oct 22 17:59:32 debian sshd[3938]: Failed password for john from 10.0.0.8 port 55673 ssh2

Hier versuchte john sich ohne SSH-Key zu Authentifizieren.

  Existiert im user home ~/.google_authenticator, so erwartet der Google Authenticator ein SUCCESS von der SSH-Key (publickey) Authentifizierungsmethode.

Wichtig ist eine korrekte Zeit, damit die TOTP-Token synchron sind, bei grösserer Abweichung kann es zu abgelaufenen OATH-TOTP-Token kommen. Der NTP-Dienst sollte daher auf dem Server entsprechend eingerichtet und konfiguriert sein, für eine präzise Zeitsynchronisation.

Zum Schluss

Gratulation! Du hast eben den SSH-Server mit Zwei-Faktor-Authentifizierung für Debian oder Ubuntu erfolgreich eingerichtet. Wir hoffen, wir konnten die nötigen Grundlagen Kenntnisse vermitteln, um den SSH-Server mit Google Authenticator zu schützen.