1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER.GERMAN

  • =?UTF-8?Q?Selbst_gel=c3=b6st=3a_libpam-google-authenticator_unter_s?= =

    From Stefan Baur@21:1/5 to All on Tue Sep 19 16:30:01 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ulf Volmer@21:1/5 to All on Tue Sep 19 17:20:01 2023
    Am Tue, Sep 19, 2023 at 04:26:08PM +0200 schrieb Stefan Baur:

    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.

    Du hast offentsichtlich eine andere man Page als ich sie hier habe.

    Bei mir steht:

    | KbdInteractiveAuthentication
    | Specifies whether to allow keyboard-interactive authentication. The default is yes. The argument to this keyword must be yes or no.
    | ChallengeResponseAuthentication is a deprecated alias for this.

    Du hast also zwei Wege gefunden, die gleiche Einstellung zu
    konfigurieren.

    Viele Grüße
    Ulf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ulf Volmer@21:1/5 to All on Tue Sep 19 17:50:01 2023
    Am Tue, Sep 19, 2023 at 05:27:08PM +0200 schrieb Stefan Baur:

    Jetzt wird's interessant. Hier widerspricht sich die neuere Manpage von Bookworm quasi selbst (zumindest, wenn man nicht genau hinschaut). Sie spricht von "default is yes", im Kopf der selben Manpage steht aber, dass Debian explizit "no" setzt:

    Default meint das Verhalten, wenn der Parameter in der Config nicht
    gesetzt ist. Das Debian selber eine Standard Config ausliefert, ist da
    aus meiner Sicht kein Widerspruch.

    Und die Werte überschreiben sich leider auch nicht in der Reihenfolge ihres Erscheinens in der Config.

    KbdInteractiveAuthentication no
    ChallengeResponseAuthentication yes

    zusammen, in dieser Reihenfolge, ergibt weiterhin keine Login-Möglichkeit
    per Google Authenticator. "deprecated alias" trifft es also nicht so ganz - sonst müsste der zweite Wert ja ein "yes" auch für KbdInteractiveAuthentication erzwingen.

    Das ist in der Tat verwirrend, ja.

    Viele Grüße
    Ulf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ulf Volmer@21:1/5 to All on Tue Sep 19 23:10:01 2023
    Am Tue, Sep 19, 2023 at 05:40:32PM +0200 schrieb Ulf Volmer:
    Am Tue, Sep 19, 2023 at 05:27:08PM +0200 schrieb Stefan Baur:

    Und die Werte überschreiben sich leider auch nicht in der Reihenfolge ihres Erscheinens in der Config.

    KbdInteractiveAuthentication no
    ChallengeResponseAuthentication yes

    zusammen, in dieser Reihenfolge, ergibt weiterhin keine Login-Möglichkeit per Google Authenticator. "deprecated alias" trifft es also nicht so ganz - sonst müsste der zweite Wert ja ein "yes" auch für KbdInteractiveAuthentication erzwingen.

    Das ist in der Tat verwirrend, ja.

    Der sshd scheint bei mehrfachen Directiven in der Config jeweils den
    ersten Eintrag zu nehmen.

    Ein

    PubkeyAuthentication no
    PubkeyAuthentication yes

    verhindert hier das Einloggen per Key.

    Das Verhalten ist damit zumindest konsistent.

    Viele Grüße
    Ulf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)