[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Selbst gelöst: libpam-google-authenticator unter stable/bookworm funktionierte nicht wie erwartet



Hallo liebe Listenlesende,

ich habe bislang immer libpam-google-authenticator verwendet, wenn ich bequem 2FA nutzen wollte.

Ich weiß, es gäbe auch noch libpam-oath, aber ich fand libpam-google-authenticator immer praktischer - es spuckt an der Textkonsole einen QR-Code aus (den man mit einer beliebigen OTP-App scannen kann, es muss nicht der Google Authenticator sein), und außerdem noch 10 Notfallcodes, die man sich ausdrucken und sicher verstauen kann, für den Fall, dass das Handy mal kaputt ist.

Nur ... mit bookworm funktionierte es nicht mehr wie gewohnt.

Sobald ich in

/etc/pam.d/sshd

unter den zwei bestehenden Zeilen

# Standard Un*x authentication.
@include common-auth

die Zeile

auth    required        pam_google_authenticator.so

ergänzte, wurden Login-Versuche per ssh -p custom_portnr_hier benutzername@127.0.0.1 einfach hart abgelehnt. Egal, welches Passwort ich eingebe, ich bekam sofort ein "Permission denied, please try again.", ich wurde gar nicht erst nach dem 2. Faktor gefragt.

Die Lösung ist, dass die /etc/ssh/sshd_config seit Bookworm ein explizites

KbdInteractiveAuthentication no

enthält.

Ist der Parameter nicht gesetzt, dann gilt laut sshd_config-Manpage, dass der Wert von ChallengeResponseAuthentication übernommen wird - den setze ich für google_authenticator explizit auf yes.

Da aber KbdInteractiveAuthentication nun explizit auf "no" gesetzt ist, wird das "yes" übersteuert.

Deswegen muss man den Parameter KbdInteractiveAuthentication entweder löschen (nehme ich an) oder explizit auf "yes" setzen (habe ich probiert, tut).

Schwupp, schon tut es wieder.

Mag sich vielleicht jemand aus der Security-Fraktion zu Wort melden, ob das sonst irgendwelche schlimmen Konsequenzen hat, diesen Parameter zu aktivieren? Also, im Zusammenspiel mit google_authenticator, natürlich. Dass man heute bei Systemen, die im Internet hängen, keine Passwortabfrage ohne 2FA mehr nutzen sollte, brauchen wir nicht diskutieren.

Gruß
Stefan


Reply to: