Two-Factor-Authentication für SSH-Logins und Sudo

Doppelt gemoppelt

Wer ein Android-Telefon sein Eigen nennt, kann mit Googles Authenticator SSH und Sudo mittels Zwei-Wege-Authentifizierung absichern. Dieser Artikel zeigt wie's geht.
Mit E-Mail-Diensten muss sich jeder Administrator früher oder später einmal beschäftigen. Das zur CeBIT erscheinende ADMIN 02/2012 gibt dazu Praxis-Tipps und ... (mehr)

Eingefleischte Admins halten das Login als »root« für genauso böse wie einfache Passwörter. Während früher das Motto "Was soll schon passieren?" galt, sind sicherheitsrelevante Fragen heute ein großer Teil der Arbeit, die IT-Verantwortliche erledigen. Brute-Force-Angriffe mit riesigen Passwort-Datenbanken haben Systembetreuer gelehrt, dass sogar komplexe Passwörter zu knacken sind, wenn der Angreifer genug Zeit hat. Dass es vielen Benutzern schwerfällt, sich ellenlange Passwörter mit Zahlen, Groß- und Kleinschreibung und Sonderzeichen zu merken, macht das Dilemma perfekt.

Dabei ist es mit relativ wenig Aufwand möglich, den Login von Benutzern sehr viel sicherer zu machen. Das beweist die Zwei-Wege-Authentifizierung. Das Prinzip ist simpel: Zuerst loggt sich der Benutzer mit einem ihm bekannten Passwort ein, anschließend erhält er auf einem zweiten Wege ein Einmal-Passwort, das ihm den Zugriff auf das gewünschte System schließlich erlaubt (Abbildung 1). Erfolgreiche Angriffe setzen also sowohl die Kenntnis des Passworts voraus, als auch den Besitz des Gerätes, über das der Benutzer das Einmalpasswort erhält. Das ist beispielsweise auch das Prinzip des SMS-TAN-Verfahrens, mit dessen Hilfe Hunderttausende Überweisungen tätigen. Auch RSA-Dongles, die vor einigen Jahren en vogue waren, funktionieren nach diesem Schema. Für Systeme mit Linux gibt es dank des Google Authenticators [1] nun auch eine Möglicheit, das Prinzip umzusetzen. Komponenten der Lösung sind ein Erweiterungsmodul für PAM und die Google-Authenticator-App für Android (Abbildung 2).

Abbildung 1: Beim Aufruf von
Abbildung 2: Mittels der Authenticator-App lassen sich auf einem Android-Telefon die Einmal-PINs generieren, die den Zugriff ermöglichen.

Übrigens: Das System verwendet den HOTP-Algorithmus, der in RFC 4226 offen dokumentiert ist. Das Einmal-Passwort, das später zur Anwendung kommt, ist also keines, das zwischen Client und Server ausgehandelt wird. Einerseits ist so sichergestellt, dass die Authentifizierung auch funktioniert, wenn auf dem Android-Smartphone gerade kein Netzwerkzugriff möglich ist. Andererseits ist damit auch klar, dass irgendwelche betriebsspezifischen Daten nicht auf Servern von Google landen.

Das System vorbereiten

Erste Voraussetzung für die Benutzung des Google Authenticators ist ein Google-Account; wer ein Android-Telefon besitzt, wird diesen in aller Regel ohnehin bereits haben. Der nächste Schritt auf dem Weg zu Google Authenticator ist die Vorbereitung der PAM-Bibliothek auf dem Ziel-System. Dazu ist das »pam_google_authenticator« -Modul notwendig. So findet es den Weg auf den Server (im Beispiel Ubuntu 10.04.3): »apt-get install libpam-devel« holt die Header der PAM-Bibliothek. »hg clone https://google-authenticator.googlecode.com/hg/ google-authenticator/« besorgt die Modul-Quellen (der Vorgang kann je nach Geschwindigkeit der Verbindung eine ganze Weile in Anspruch nehmen). Falls »hg« fehlt, ist das Paket »mercurial« noch zu installieren. Für Ubuntu 10.04 sollte dafür allerdings die aktuelle Version für Ubuntu 11.04 oder 11.10 installiert werden, weil die Features unterstützt, die Googles Mercurial-Repository benötigt. Die Version 1.7.5 ist hinreichend aktuell, sie steht unter [2] zum Download bereit. Last but not least muss auch »svn« vorhanden sein, weil in das Hg-Repository bei Google ein Subversion-Verzeichnis verlinkt ist.

Schwierigkeiten

»cd google-authenticator/libpam && make && make install« kompiliert und installiert das PAM-Modul. Je nach eingesetzter Distribution landet auf Systemen mit 32-Bit-Installation das Modul im falschen Ordner und ist gegebenenfalls noch mittels »ln -s /usr/lib/pam_google_authenticator.so /lib/i386-linux-gnu/security/« an die richtige Stelle zu verlinken. Schuld daran ist »multiarch« , das Ubuntu in seinen neuen Distributionen einsetzt. Die LTS-Version 10.04 ist von diesem Problem noch nicht betroffen, die zukünftige LTS-Version 12.04 hingegen schon.

Wer den Authenticator stattdessen auf einem 64-Bit-System mit Ubuntu 11.04 oder neuer kompiliert, ist vor Ärger ebenfalls nicht gefeit: Hier scheitert bereits der Kompiliervorgang, weil »libdl.so« nicht gefunden wird und somit alle »libdl« -Funktionen nicht zur Verfügung stehen. Ein Sed-Aufruf löst das Problem:

»sed -i.orig -e 's!/usr/lib/libdl.so!/usr/lib/x86_64-linux-gnu/libdl.so!' Makefile« Nun sollte der Kompiliervorgang des Authenticators auch auf Ubuntu 11.04 oder einer neueren Version klappen.

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018