Zwei-Faktor Authentifizierung

Vorwort:

Je intensiver ich an meinen Servern arbeite, desto sicherer müssen sie für mich sein.
Angefangen mit einem Telegram-Bot, der mir Notifications schickt, wenn sich jemand an meinem System anmeldet, bis hin zur Zwei-Faktor Authentifizierung, mit hinterlegtem SSH-Key und Passphrase. Ist das wirklich alles notwendig? Nicht unbedingt, doch Spaß an der Freude und Paranoia gehen hier Hand in Hand.

Für das folgende Szenario ist es besonders wichtig, dass bei allen beteiligten Komponenten die Uhrzeit so genau wie möglich übereinstimmt. Denn zu jeder Uhrzeit ist ein anderer, errechneter Token notwendig und zu verwenden. Deshalb empfiehlt es sich die Zeit mittels NTP zu synchronisieren.

Zusätzlich muss bedacht werden, dass hier eine Gefahr besteht sich auszusperren.

Im folgenden Artikel erkläre ich, wie ich das umgesetzt habe.

Schritt 1 – SSH Key

Hier gibt es mehrere Methoden. Ich erkläre wie es über einen Linux Client funktioniert.

~$ ssh-keygen -b 4096

Generating public/private rsa key pair.
Enter file in which to save the key (/home/singer/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/singer/.ssh/id_rsa.
Your public key has been saved in /home/singer/.ssh/id_rsa.pub.
The key fingerprint is:
36:0f:03:9c:3f:6e:11:63:07:9b:2b:e9:2f:1a:13:ee singer@singer-nb
The key's randomart image is:
+--[ RSA 4096]----+
|        .        |
|     . . +       |
|      + * .      |
|       = =       |
|    . o S        |
|   . o + B       |
|    + . o .      |
|   . o.o         |
|    E. ..        |
+-----------------+

Natürlich geben wir eine Passphrase an, um die Sicherheit nochmals zu erhöhen.
Der Key ist nun generiert und muss auf den Server übertragen werden. Das geht wie folgt.

~$ ssh-copy-id -i .ssh/id_rsa.pub singer@192.168.32.128

Folgendes wird ausgegeben:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
singer@192.168.32.128's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'singer@192.168.32.128'"
and check to make sure that only the key(s) you wanted were added.

Auf dem Server wurde jetzt die Datei .ssh/authorized_keys erzeugt.

~ $ cat .ssh/authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC+a/GSI7r3x243A8dHnPIore80GsX6frpfqpUSBDn5TyGh6k4tiirYLMSuS9xxMjj9eagq1gl9sKtHTR7L23rR9UPBSI0nAx2PyFvlZrOeFPBKTKwxlWhinQGV4Agtjb2EHoqFnrxKNLrRDeTsdgFJNSUOqZyV/zY+x/0BiPkUBRRB4LMSPwpw2RDugBW6sR5GQna9HXG676fCQq379L51BASQHV02l9JsLMzSELLBpl50rfXPgtsUgWlmcDhpU9hnPnFGz1FoKSbQB+GbOZy0fr4BKpTsr+kvaPfbMahv8vbocGPXF3+0iVHkM0jzZg6gcdxFKZlXvGFY4rFQkptYh+zkwCDvNdw0VrjJIfNbDf+lXymVnFYgg6GZKvPH7ZGCegBBSeDs3+9SLCi5m3DWQFlrXedrGDFdXu1NdgS9dJg+c5ZbHTeksQKksd58aGkK4GZbpeAAYX83AiNxaSRrK6gfLbc9/vncr4igoyxUHmvwpzjyk/GIz0j7ay0W2TX6DlBYWsRHyJnhwe673C1I2II4X0s9o391cK/IL3tCFm6LtZAX8qUI9acwmsjEqC8a0XId4adZxty+wKlFZW4cGtffm7o0TWeqDK2lQ6i3jtODzUWzKb8AzI9PsbfhGwGOWmD7pm3bP/k325RvaNhWWPs7AXz2lljQW8XuyeALZQ== singer@singer-nb

Die Authentifizierung via SSH Key sollte nun funktionieren.
Im Anschluss noch testen mittels:

~$ ssh -i .ssh/id_rsa singer@192.168.32.128

Enter passphrase for key '.ssh/id_rsa':

Nun kann der Login mittels Passwort deaktiviert werden. Dazu in der /etc/ssh/sshd_config die Einstellung PasswordAuthentication yes zu PasswordAuthentication no ändern und den SSH Server neu starten /etc/init.d/ssh restart.

Schritt 2 – Google Authenticator

Auf dem Server wird folgender Befehl ausgeführt, um den Google Authenticator zu installieren.

~ $ sudo apt-get install libpam-google-authenticator

Nun muss die Konfigurationsdatei des SSH-Servers angepasst werden.

~ $ sudo vi /etc/ssh/sshd_config

Dort die Zeile ChallengeResponseAuthentication no durch ChallengeResponseAuthentication yes ersetzen. Außerdem muss UsePAM auf yes stehen.
ACHTUNG: Hier kommt nun die Eigenheit des Public-Keys ins Spiel. Falls KEIN Key verwendet wird, kann folgende Zeile ignoriert werden, andernfalls unbedingt einfügen:
AuthenticationMethods publickey,keyboard-interactive

Im Anschluss folgende Datei anpassen:

~ $ sudo vi /etc/pam.d/sshd

Den Eintrag @include common-auth auskommentieren
#@include common-auth
Somit wird bei der Anmeldung nicht noch zusätzlich nach einem Passwort gefragt.
Und am Ende der Datei folgendes eintragen:
#Google Authenticator
auth required pam_google_authenticator.so
Optional kann noch nullok am Ende der Zeile hinzugefügt werden, dadurch kann sich auch noch ohne Authenticator authentifiziert werden. Aber natürlich mit SSH-Key und Passphrase

Nun den SSH-Server neustarten - /etc/init.d/ssh restart

Nun muss der Google Authenticator mit dem Benutzer aufgerufen werden, mit man sich authentifizieren will.

~ $ google-authenticator

Nun wird folgendes ausgeben:

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

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/singer@Singer-Lab-Debian%3Fsecret%3DTDVDO4S3CTY7M4X4GJRELEUT6I%26issuer%3DSinger-Lab-Debian

Your new secret key is: TDVDO4S3CTY7M4X4GJRELEUT6I
Your verification code is 071650
Your emergency scratch codes are:
  65215138
  50889194
  54334774
  69674206
  10560369

Der QR-Code kann dann über die Smartphone App (erhältlich für iOS und Android) eingelesen werden. Nach dem Scan erscheint schon der Token.

Falls der QR-Code zu groß für das Fenster ist, kann auch die Eingabe des „secret key“ erfolgen. Außerdem sind fünf Notfall Codes verfügbar, die man sich aufschreiben und benutzen kann, wenn man das Smartphone verliert oder es gerade nicht griffbereit hat.

Um die Konfiguration abzuschließen, die restlichen Fragen mit y beantworten.

Do you want me to update your "/home/singer/.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) 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, tokens are good for 30 seconds. 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. If you experience problems with
poor time synchronization, you can increase the window from its default
size of +-1min (window size of 3) to about +-4min (window size of
17 acceptable tokens).
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

Nun ist die Konfiguration abgeschlossen. Um jetzt in das System zu gelangen muss der SSH-Key hinterlegt, die dazugehörige Passphrase bekannt und der Token vorhanden sein.

Viel Spaß beim Ausprobieren.

Sven Singer

System Engineer

Sven ist unter den Kollegen dafür bekannt alle Probleme „glatt zu ziehen“. War in seinem ersten Leben Fliesenleger: manche Dinge lassen einen nie mehr los. Beschützt alles was ihm lieb und teuer ist. Das gilt nicht nur für seinen 3er BMW, sondern auch für die Daten in der Cloud.