2FA für Linux-SSH mit pam_radius – Telefonbestätigung für SSH und sudo

Derselbe Notakey Auth-Proxy, der bereits Ihr VPN und die Admin-Anmeldung am MikroTik schützt, kann auch Linux-Anmeldungen absichern. Der PAM-Stack von Linux bringt ein Standard-RADIUS-Modul mit: Richten Sie es auf den Proxy, und SSH, sudo und su verlangen zusätzlich zum Passwort eine Bestätigung auf dem Telefon.

sshd / sudo ──PAM──▶ pam_radius ──RADIUS──▶ Notakey auth-proxy ──▶ your RADIUS server
                                                    │
                                                    └──▶ push ──▶ user's phone

Diese Anleitung gilt für Debian/Ubuntu (libpam-radius-auth); auf Distributionen der RHEL-Familie heißt das Paket pam_radius (EPEL), und die PAM-Dateien liegen im gleichen Layout unter /etc/pam.d/.

Voraussetzungen

Ein funktionierender Auth-Proxy vor einem RADIUS-Server, eingerichtet genau wie in den Schritten 1–3 der VPN-Anleitung.
Derselbe Benutzername im nachgelagerten RADIUS-Server, im Notakey-Dienst (mit registriertem Telefon) und als Konto auf dem Linux-Rechner. PAM übernimmt nur die Authentifizierung; der Benutzer braucht weiterhin ein lokales Konto (oder eines im Verzeichnisdienst), mit dem er sich anmelden kann.
Der Linux-Rechner muss den Proxy über UDP 1812 erreichen. Das Passwort läuft zwischen beiden als PAP. Halten Sie diese Strecke daher in einem Management-Netz, oder lassen Sie den dockerisierten Proxy direkt auf dem Host laufen.

Schritt 0: Richten Sie zuerst den Notausgang ein

Bevor Sie PAM anfassen, stellen Sie sicher, dass eine rein lokale Anmeldung funktioniert: Geben Sie root (oder einem dedizierten Break-Glass-Admin) ein starkes lokales Passwort und prüfen Sie es an der Konsole. Die folgende Konfiguration fällt immer auf lokale Passwörter zurück; dieses Konto ist also Ihr Weg hinein, falls Proxy, RADIUS-Server oder Netzwerk einmal ausfallen. Erledigen Sie das zuerst, nicht erst, wenn etwas kaputt ist.

Schritt 1: Modul installieren

sudo apt-get install libpam-radius-auth

Schritt 2: Modul auf den Proxy richten

Bearbeiten Sie /etc/pam_radius_auth.conf und ergänzen Sie eine Zeile mit der Adresse des Proxys, dem Shared Secret (dem Gegenstück zum vpn_secret_in des Proxys) und dem Timeout in Sekunden:

# server[:port]    shared_secret            timeout (s)
10.0.1.20          secret_to_radius_server  60

Schränken Sie anschließend die Dateirechte ein, denn die Datei enthält das Secret:

sudo chmod 0600 /etc/pam_radius_auth.conf

Der Timeout ist dieselbe Falle wie überall sonst in dieser Serie. Der Standardwert des Moduls beträgt 3 Sekunden: für eine Passwortprüfung völlig ausreichend, für eine menschliche Bestätigung aussichtslos. Setzen Sie ihn mindestens auf das vpn_message_ttl des Proxys (30 s); mit 60 haben Sie bequem Spielraum.

Schritt 3: In PAM aktivieren

Fügen Sie für jeden zu schützenden Einstiegspunkt eine Zeile direkt oberhalb der Zeile @include common-auth ein. Für SSH:

sudo nano /etc/pam.d/sshd

auth sufficient pam_radius_auth.so
@include common-auth

sufficient bedeutet: Antwortet RADIUS mit Access-Accept (Passwort nachgelagert geprüft und Push bestätigt), ist die Anmeldung sofort erfolgreich. Andernfalls fällt PAM auf die normale lokale Passwortprüfung darunter zurück.

Ergänzen Sie dieselbe Zeile nach Bedarf auch hier:

/etc/pam.d/login – Anmeldungen an der Konsole
/etc/pam.d/sudo – jedes sudo fragt auf dem Telefon nach (streng, aber gesprächig; erträglich bleibt es, weil sudo die Authentifizierung eine Weile zwischenspeichert)
/etc/pam.d/su – Benutzerwechsel

Bearbeiten Sie zum Schluss /etc/pam.d/common-auth und ergänzen Sie try_first_pass in der vorhandenen pam_unix.so-Zeile:

auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass

(Die übrigen Optionen dieser Zeile variieren je nach Release; nur try_first_pass kommt hinzu.) Ohne diese Option wird ein Benutzer, der auf die lokale Authentifizierung zurückfällt, ein zweites Mal nach dem Passwort gefragt; mit ihr wird das bereits eingetippte Passwort stillschweigend weiterverwendet.

Schritt 4: Prüfen, ob sshd PAM wirklich nutzt

In /etc/ssh/sshd_config braucht die PAM-basierte Authentifizierung:

UsePAM yes
KbdInteractiveAuthentication yes

(beides entspricht den Voreinstellungen unter Debian/Ubuntu). Eines sollten Sie wissen: SSH-Anmeldungen per Public Key überspringen die Auth-Phase von PAM vollständig, eine schlüsselbasierte Anmeldung löst also keinen Push aus. Wenn Sie Schlüssel plus Push wollen, setzen Sie AuthenticationMethods publickey,keyboard-interactive; testen Sie diese Variante aber separat, bevor Sie sie ausrollen.

Schritt 5: Nur-Push-Benutzer anlegen

Und hier der Kniff, der das Setup sauber macht: Legen Sie Benutzer ohne lokales Passwort an.

sudo useradd -m -G sudo john

Kein passwd danach: Das lokale Passwort des Kontos bleibt gesperrt. Dieser Benutzer hat damit genau einen Weg hinein: RADIUS über den Proxy, also Passwort und Telefonbestätigung. Lokal gibt es nichts, das sich per Brute-Force knacken ließe. Ihr Break-Glass-Admin aus Schritt 0 bleibt das einzige Konto mit rein lokalem Passwort.

Testen – mit Bedacht

Lassen Sie Ihre funktionierende Sitzung offen und melden Sie sich aus einem zweiten Terminal per SSH mit einem RADIUS-Benutzernamen an:

Die Passwortabfrage verhält sich wie gewohnt; nach der Eingabe wartet die Sitzung. Das ist der Proxy, der den Austausch offen hält.
Die Push-Benachrichtigung erscheint auf dem Telefon. Bestätigen → Shell. Ablehnen oder ignorieren → die Anmeldung schlägt nach dem Timeout fehl.
Vergewissern Sie sich, dass das Break-Glass-Konto weiterhin mit seinem lokalen Passwort hineinkommt.

Schließen Sie Ihre ursprüngliche Sitzung erst, wenn beide Prüfungen bestanden sind.

Fehlerbehebung

Anmeldung schlägt sofort fehl, kein Push. Der Timeout in /etc/pam_radius_auth.conf steht noch auf dem 3-Sekunden-Standardwert, oder das Secret passt nicht zum vpn_secret_in des Proxys.
Kein Push, aber die Wartezeit tritt ein. Der Benutzername stimmt zwischen RADIUS und dem Notakey-Dienst nicht überein, oder das Telefon ist für diese Anwendung nicht registriert.
Passwort wird zweimal abgefragt. try_first_pass fehlt in der pam_unix-Zeile in common-auth.
Schlüsselbasierte SSH-Anmeldungen lösen keinen Push aus. Das ist so vorgesehen; die Public-Key-Authentifizierung umgeht die Auth-Phase von PAM (siehe Schritt 4).

Einordnung

Ein Proxy, ein RADIUS-Server – und jetzt verlangen das VPN, die Admin-Ebene des Routers und Ihre Linux-Flotte allesamt eine Bestätigung auf dem Telefon. Alles, was RADIUS oder PAM spricht, kann sich demselben Setup anschließen.