Multi-Faktor-Authentifizierung (2FA) problem

  • Hallo Netcup Community,


    ich versuche verzweifelt eine Multi-Faktor-Authentifizierung auf meinem Root Server auf dem Debian 9 läuft zu installieren/integrieren.

    Ich habe schon in Google sämtliche Themen darüber durchstöbert, bis ich an den Punkt der Verwirrung angekommen bin, da in jedem zweiten Thema entweder die hälfte weggelassen oder ich sage mal "Sinnentleert" dahin geschrieben wurde.


    Was ich bis jetzt unternommen habe:


    Installationsschritte:


    - apt-get install libpam-google-authenticator. (Als Root)

    - den Befehl: google-authenticator (als User) eingegeben und die darauffolgenden Fragen beantwortet.


    In der Datei / etc / pam.d / sshd folgendes unternommen:


    In der Datei / etc / ssh / sshd_config folgendes unternommen:


    Was auch funktioniert, wenn ich mich erneut per SSH verbinde werde ich nach meinem Schlüssel (Public-Key) gefragt den ich eingeben soll (was auch vollständig funktioniert) und danach werde ich nach dem Verification code gefragt der auch funktioniert bei der richtigen Eingabe, wenn ich aber eine falsche Eingabe tätige schmeißt er mich raus (soll ja auch so sein) nur dann kann ich mich nicht mehr per SSH, FTP oder sonstiges verbinden, und jetzt ist meine Frage woran das liegt bzw. was das sein könnte.


    Ich hoffe mir kann hier geholfen werden, da ich diesbezüglich nicht mehr weiter weiß.



    Mit freundlichen Grüßen



    Kmdt.Brandt

  • Zitat

    AuthenticationMethods publickey,password publickey,keyboard-interactive

    Die Zeile sieht seltsam aus. Ansonsten, ist Fail2ban aktiv? Das erkennt so etwas und blockiert dich.


    Siehe auch dieser Blog:

    https://infosec-handbook.eu/blog/wss1-basic-hardening/#s4


    AuthenticationMethods publickey,keyboard-interactive


    Normalerweise wird der Public Key ohne Eingabe automatisch erkannt (oder hast du ein Passwort für die Nutzung des Keys vergeben?). Du musst nur den Verification Code eingeben.

  • Die Zeile sieht seltsam aus. Ansonsten, ist Fail2ban aktiv? Das erkennt so etwas und blockiert dich.

    Meinst du damit, wenn ich den Befehl etc/init.d/fail2ban status eingebe und etwas weiter unten

    Active: active (running) steht?


    AuthenticationMethods publickey,keyboard-interactive

    Was ist hier mit password publickey, ist das nicht für die Eingabe der Passphrase des Benutzers? Oder wozu?


    Normalerweise wird der Public Key ohne Eingabe automatisch erkannt (oder hast du ein Passwort für die Nutzung des Keys vergeben?). Du musst nur den Verification Code eingeben.

    Also wenn ich mich per SSH anmelde muss ich das Passwort für Passphrase for key "Brandt@server": und Verification code: eingeben.

  • Meinst du damit, wenn ich den Befehl etc/init.d/fail2ban status eingebe und etwas weiter unten

    Active: active (running) steht?

    Dann hast du ziemlich sicher ein Jail für SSH in Fail2ban aktiv und deshalb wirst du geblockt. Entweder deaktivierst du Fail2ban oder du setzt deine IP auf eine Whitelist (bei dynamischer IP sinnlos) oder du entblockst dich via VNC über Server Control Panel (fail2ban-client set ssh unbanip IPADDRESSHERE).


    Was ist hier mit password publickey, ist das nicht für die Eingabe der Passphrase des Benutzers? Oder wozu?

    Wenn du password aktiv lässt, kann man sich nicht nur mit dem Public Key anmelden (das ist der wünschenswerte Zustand) sondern auch mit einem Passwort (das sollte deaktiviert sein). Da sollte nur AuthenticationMethods publickey,keyboard-interactive stehen. keyboard-interactive ist für Eingabe des Verification Codes notwendig.


    Also wenn ich mich per SSH anmelde muss ich das Passwort für Passphrase for key "Brandt@server": und Verification code: eingeben.

    Dann hast du deinen SSH-Key auf deinem lokalen Rechner mit einem Passwort geschützt. Jedes Mal, wenn du ihn nutzen willst, musst du ihn mit einem Passwort entschlüsseln. Das hat aber nichts mit dem eigentlichen SSH-Zugriff zu tun und passiert nur lokal.


    Die Idee ist:


    1. Verbindungsaufbau zum Server
    2. Nachweis der Client-Identität mit Public Key
    3. Bestätigung mit zweitem Faktor (OATH-TOTP)
    4. Verbunden
  • Ich bin mir nicht sicher ob ich etwas überlesen oder nicht ganz verstanden habe?


    Dann hast du ziemlich sicher ein Jail für SSH in Fail2ban aktiv und deshalb wirst du geblockt.

    Die sshd Jail habe ich auf enabled = true stehen.


    Entweder deaktivierst du Fail2ban oder du setzt deine IP auf eine Whitelist.

    Das geht mit meiner IP leider nicht, und deaktivieren möchte ich es ungern.


    Gibt es eine Möglichkeit über eine neue Jail den google-authenticator hinzuzufügen, und somit einstellen zu können nach wie vielen Versuchen man gelockt wird oder hängt gerade das mit der sshd Jail zusammen?


    Wenn du password aktiv lässt, kann man sich nicht nur mit dem Public Key anmelden (das ist der wünschenswerte Zustand) sondern auch mit einem Passwort (das sollte deaktiviert sein). Da sollte nur AuthenticationMethods publickey,keyboard-interactive stehen. keyboard-interactive ist für Eingabe des Verification Codes notwendig.

    Ist damit gemeint dass wenn ich nur AuthenticationMethods publickey,keyboard-interactive verwende, das denn beim erneuten SSH Login nur Verification code: angezeigt wird und der Public Key im Hintergrund "abgefragt" wird nur ohne eine Passwort Aufforderung bzw. Eingabe?

  • Das Passwort für den SSH-Key dient ausschließlich zum lokalen Schutz des Keys, es wird nicht an den Server übertragen. Du solltest es nicht mit dem Passwort des serverseitigen User-Accounts verwechseln.

  • Noch einmal zusammengefasst (steht ja eigentlich schon da):


    1. Du hast ein Schlüsselpaar aus Private Key und Public Key auf dem lokalen Rechner
    2. Du kopierst den Public Key auf deinen Server. Der Private Key bleibt auf dem lokalen Rechner
      1. Jedes Mal, wenn du den Private Key nutzen willst, musst du ein Passwort lokal eingeben. Das liegt daran, dass der Private Key verschlüsselt auf deinem lokalen Rechner gespeichert ist und sozusagen entsperrt werden muss, bevor du ihn für irgendetwas nutzen kannst.
    3. Du richtest einen TOTP-Client ein, der dir die Verification Codes (zeitbasierte Einmalpasswörter) generiert

    Wenn du dich verbindest:

    1. Verbindungsaufbau
    2. Dein lokaler Rechner weist sich gegenüber deinem Server mit einer Signatur aus (dazu ist der Private Key notwendig und den entsperrst du eben lokal mit deinem lokalen SSH-Key-Passwort)
    3. Der Server prüft die Signatur anhand des Public Keys
    4. Wenn alles passt, musst du den zweiten Faktor (TOTP) eingeben
    5. Dann zwei Möglichkeiten:
      1. Du gibst das Einmalpasswort korrekt ein → eingeloggt
      2. Du gibst das Einmalpasswort x-Mal falsch ein → Fail2ban erkennt das anhand der Log-Files → Fail2ban sperrt dich gemäß den Einstellungen deines sshd-Jails


    Gibt es eine Möglichkeit über eine neue Jail den google-authenticator hinzuzufügen, und somit einstellen zu können nach wie vielen Versuchen man gelockt wird oder hängt gerade das mit der sshd Jail zusammen?

    Das hängt direkt damit zusammen. Da definierst du, wie viele Fehlversuche bis zur Sperrung erlaubt sind und wie lange gesperrt wird.


    Ist damit gemeint dass wenn ich nur AuthenticationMethods publickey,keyboard-interactive verwende, das denn beim erneuten SSH Login nur Verification code: angezeigt wird und der Public Key im Hintergrund "abgefragt" wird nur ohne eine Passwort Aufforderung bzw. Eingabe?

    Du musst in deiner sshd Konfiguration nur aktivieren: AuthenticationMethods publickey,keyboard-interactive

    • publickey = Authentifizierung mit Public Key erlaubt
    • keyboard-interactive = Ist notwendig, damit du den Verification Code eingeben kannst; sozusagen interaktiver Eingabemodus erlaubt

    Wenn da noch "password" steht, dann ist damit nicht das Passwort zum Entsperren deines lokalen SSH Private Keys gemeint, sondern die Möglichkeit, sich via SSH mit einem Passwort + Nutzernamen anzumelden. Das willst du aber nicht. Also kein "password". Siehe auch den von mir verlinkten Blog-Artikel.

  • Vielen Dank Martha es Funktioniert jetzt.


    Ich habe aber jetzt noch eine "Kleinigkeit" bei der ich nicht so ganz weiterkomme, ich versuche (und das jetzt schon etwas länger) es so einzustellen, dass der User (Brandt) und dessen Gruppe (SSHManager) sich im Gegensatz zu den Gruppen/Usern (GameserverRoot & VoiceserverRoot) ohne ein Passwort und die anderen beiden mit einem Passwort anmelden sollen. Leider meldet sich der User (Brandt) jetzt mit einer 3 Schritte Authentifizierung an.

    Einmal mit dem Public_key, dem Passwort und dem Verification code.

    Wobei das Passwort nicht bei dem User Brandt auftauchen sollte.


    Hier mal die Dinge die ich geändert bzw. Unternommen habe:


    Die Datei aus /etc/pam.d/sshd


    Die sshd-config



    Ich hoffe mir kann erneut geholfen werden und vielleicht könnt Ihr mir helfen die sshd_config ein wenig zu "entmüllen" oder mir Tipps geben was da eigentlich total "unnötig" ist.


    Ich hoffe ich habe alles verständlich aufgeschrieben.



    Mit freundlichen Grüßen


    Brandt

  • Moin,


    um zu Testen, ob die Matches in der sshd.config richtig triggern kann man die Optionen -T und -C des sshd verwenden.

    Hier das Ende meiner sshd_config:


    Code
    ChallengeResponseAuthentication yes
    # exceptions for special users without yubikey
    Match Group user1
            AuthenticationMethods  publickey,password
            PasswordAuthentication yes
    
    # defaults for all yubikey users (pub-key + yubikey)
    Match all
            AuthenticationMethods publickey,keyboard-interactive
            PasswordAuthentication no

    Mit dem user1 der Mitglied von group1 ist ergibt sich dann z.B. dies:

    Code
    # sshd -T -C user=user1 -C host=localhost -C addr=127.0.0.1|grep -i AuthenticationMethods
    exposeauthenticationmethods never
    authenticationmethods publickey,password

    Das heißt, der Match auf Group user1 hat getriggert. Damit sollte sich das Verhalten des sshd nachvollziehen lassen. Eine andere Baustelle ist PAM. Evtl. wird in der PAM-Config des sshd password-auth getriggert...


    Gruß,


    Kalle.

  • Kalle12 vielen dank für deine Hilfe, leider funktioniert es nur würde ich sagen teilweise.



    Es funktioniert alles außer mit dem User (Brandt) leider nicht, wenn ich mich hierüber versuche anzumelden, erhalte ich folgendes Problem:


    Aus irgendeinem mir nicht bekannten Grund wird das Passwort nicht angenommen, wobei hier auch gar keins auftauchen/abgefragt werden soll, sondern nur der publickey und der Verification code.



    Hier nochmals meine sshd_config



    Und die Datei aus /etc/pam.d/sshd


    Mit freundlichen Grüßen



    Brandt

  • Hay,


    es wäre vielleicht noch gut, für den mißglückten Einloggversuch den entsprechenden Ausschnitt aus der /var/log/auth.log zu sehen (bzw. je nach System das äquivalente log dazu).


    P.S.: und ich würde mal PasswordAuthentication explizit nicht auskommentieren, sondern auf no setzen.

    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Hay,


    ok, ich glaube, ich habe es. Oben das PasswortAuthentication so entkommentieren wie ich geschrieben habe und dafür machst Du das unten beim match all komplett weg. Ich glaube, das überschreibt dann Deinen match-Block mit den Einschränkungen.


    AuthenticationMethods publickey,password auch vor Deinen Matchblock verlegen, so dass zum Schluß NUR noch match all steht.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Moin,


    ich bin mit CentOS 7.5 unterwegs mit PAM Version 1.1.8-22.el7. Dort sieht /etc/pam.d/sshd deutlich anders aus, sodass ich zu Deiner PAM-config nicht viel sagen kann. Ich hänge hier mal den Anfang meiner /etc/pam.d/sshd rein:


    Code
    #%PAM-1.0
    auth required  pam_yubico.so nullok [Rest yubico weggelassen]
    # Der User Willi muss sich nicht per Passord authentifizieren, alle anderen schon
    # success=1 überspringt die Zeile 'auth       substack     password-auth'
    auth       [default=ignore success=1]  pam_succeed_if.so user = willi
    auth       substack     password-auth
    auth       required     pam_sepermit.so
    auth       include      postlogin
    [...]

    Als erstes wird das Yubikey PAM-Modul eingebunden. Wenn die Yubikey-Auth erfolgreich war wird mit 'auth substack password-auth' zusätzlich die Unix-Passwort-Abfrage gestartet, sodass man eine 3-Faktor Authentifizierung hat, außer der Username ist willi. (Man kann natürlich die password-auth Zeile einfach auskommentieren und die pam_succeed_if Geschichte weglassen und hat dann eine reine 2-Faktor-Authentifizierung).


    Viele Anleitungen mit Bezug auf pam_google_authenticator und Debian 9 schalten in der PAM-Config des sshd 'common-auth' ab. Bei Dir ist das aktiv, was vermutlich die zusätzliche Passwortabfrage nach erfolgreicher Google-Authentifizierung zur Folge hat. Siehe auch:


    Anleitung Debian 9 und Google-Auth


    Dort sieht das so aus:


    Code
    Find the line @include common-auth and comment it out, like what is shown below.
    
    # Standard Un*x authentication.
    #@include common-auth

    Probier das doch mal aus.


    Ich habe bei mir 3 Varianten aktiv (je nach user):


    1.) Nur Yubikey OTP

    2.) Yubikey OTP + Unix Password

    3.) Publickey + Unix Password


    Ich hoffe das hilft etwas weiter.


    Gruß,


    Kalle.

  • Moin,


    die Auflistung am Ende sollte eigentlich so aussehen:


    1.) Publickey + Yubikey OTP (Sonderfall)

    2.) Publickey + Yubikey OTP + Unix Password (Standardfall)

    3.) Publickey + Unix Password (Sonderfall)


    Gruß,


    Kalle.

  • Es tut mir leid dass ich mich erst jetzt wieder melde, hatte etwas viel um die Ohren und konnte den Server im moment nicht weiter betreiben/betreuen.


    Ich habe jetzt das problem, dass der user Brandt funktioniert aber die User GameserverRoot und VoiceserverRoot nicht wirklich.


    Wenn ich mich versuche mit einen der beiden per SSH zu verbinden werde ich nach dem Passwort gefragt, wenn ich dieses jedoch eingebe erhalte ich ein Access denied.


    Hier meine Config´s


    /etc/pam.d/sshd


    /etc/ssh/sshd_config


    Ich hoffe man kann mir erneut weiterhelfen.



    Mit freundlichen Grüßen



    Brandt

  • //Edit:


    Habe es bis jetzt soweit, dass man sich mit den User GameserverRoot und VoiceserverRoot zwar per SSH einloggen kann, jedoch werde ich nach der Passphrase gefragt und anschließend nach dem Passwort, allerdings gibt es mit der Passworteingabe ein Problem, egal was ich eingebe, ich werde mit dem Server verbunden.


    Hier nochmal meine Konfigurationsdateien.



    /etc/pam.d/sshd



    /etc/ssh/sshd_config


    Ich bitte für das "Spammen" um Entschuldigung, bin aber langsam aber sich mit meinen Latein am ende und weiß nicht mehr weiter.



    Mit freundlichen Grüßen



    Brandt

  • Moin,


    da @include common-auth in der PAM-Config des sshd auskommentiert ist, funktioniert die Passwortüberprüfung für den Fall AuthenticationMethods password,publickey nicht.


    Um den Fall 'AuthenticationMethods publickey,keyboard-interactive' ohne Passwortüberprüfung abzudecken könntest Du versuchen @include common-auth mittels pam_succeed_if.so mit einem Match auf "user ingroup SSHManager" zu überspringen. Siehe auch "man pam_succeed_if". Am besten in den anderen PAM-Files Deiner Distribution nachsehen, wie das dort gehandhabt wird.

    Unter CentOS 7.5 funktioniert das selektive Überspringen der Passwortüberprüfung (substack password-auth) für den User sonderfall so: (Anfang von /etc/pam.d/sshd)

    Code
    %PAM-1.0
    auth required  pam_yubico.so nullok id=1 key...
    auth       [default=ignore success=1]  pam_succeed_if.so user = sonderfall
    auth       substack     password-auth
    auth       required     pam_sepermit.so
    auth       include      postlogin
    [...]



    Gruß,


    Kalle.