Frage Der Versuch, SSH mit dem öffentlichen Schlüssel (kein Passwort) zu erhalten + Google Authenticator arbeitet an Ubuntu 14.04.1


Ich benutze Ubuntu 14.04.1 (mit OpenSSH 6.6 und libpam-google-authenticator 20130529-2).

Ich versuche, SSH-Logins einzurichten, bei denen der öffentliche Schlüssel authentifiziert wird (ohne ein Passwort) und ein Benutzer zur Eingabe eines Codes aus dem Authenticator von Google aufgefordert wird.

Das Folgen / Anpassen dieser Anweisungen hat mir eine Passwortabfrage sowie eine Google Auth-Eingabeaufforderung erhalten:

Ich habe das Paket installiert, meine bearbeitet /etc/ssh/sshd_config und /etc/pam.d/ssh Dateien

Im /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
AuthenticationMethods  publickey,keyboard-interactive
UsePAM yes

und am unteren Rand von /etc/pam.d/ssh:

auth required pam_google_authenticator.so nullok # (I want to give everyone a chance to set up their 2FA before removing "nullok")

Ich weiß PAM ist abhängig von der Reihenfolge, aber ist sshd_config ebenfalls?

Was mache ich falsch? Jede Hilfe wäre willkommen.


19
2017-09-19 15:42


Ursprung




Antworten:


Habe es gut funktioniert, zuerst tat:

apt-get install libpam-google-authenticator

Im /etc/pam.d/sshd Ich habe die folgenden Zeilen geändert / hinzugefügt (ganz oben):

# @include common-auth
auth required pam_google_authenticator.so

Und in /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
PasswordAuthentication no

Funktioniert gut und ich erhalte jetzt nach der Authentifizierung mit dem öffentlichen Schlüssel eine Bestätigungscode-Eingabeaufforderung. Ich bin mir nicht sicher, wie ich die Authentifizierung mit Passwort + Token ODER Schlüssel + Token erlauben würde, da ich jetzt die Passwortauthentifizierungsmethode von PAM effektiv entfernt habe.

Ubuntu 14.04.1 LTS (GNU / Linux 3.8.0-19-generisch x86_64) mit ssh -v verwenden: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 Jan 2014


27
2017-09-29 19:19



Also, für die Nachwelt, habe ich mein Problem erkannt. Ich hatte es auch versucht PasswordAuthentication noAber das war es nicht. Das Problem ist / war, dass ich / hatte ControlMaster auto und ControlPath Anweisungen in meiner ~ / .ssh / config-Datei. Ich wollte sicherstellen, dass ich mich nicht aussperren würde, also würde ich immer eine SSH-Sitzung offen lassen. Da mein Computer sie einfach wiederverwenden würde, bin ich immer reingekommen, ohne dass das System nach einem Token gefragt hat. Ich habe deine Antwort als korrekt markiert, da jemand, der ihr folgt, tatsächlich ein funktionierendes Setup erhalten würde. Vielen Dank! - JT.
Ich benutze CentOS 7. Ich habe PasswordAuthentication no, ChallengeResponseAuthentication yes, AuthenticationMethods publickey,keyboard-interactive, und UsePAM yes im sshd_config. Es validiert meinen Schlüssel und dann fragt nach meinem Google Authenticator-Token und dann auch fragt mich nach meinem Passwort. Bringt mich dazu, alle drei zu machen - ich kann sie nicht überspringen. Ich habe es auch versucht AuthenticationMethods publickey,keyboard-interactive:pam wie von der man-Seite vorgeschlagen, aber das änderte nichts. Irgendwelche Ideen? - Nick Williams
@NickWilliams Ich hatte das gleiche Problem. Was es für mich reparierte, war, dass ich das empfehlen musste @include common-auth Zeile, die die Antworten zeigen. Ich dachte nur, es war ein Kommentar für die pam_google_authenticator Linie in /etc/pam.d/sshd zuerst. - freb
Vielen Dank! Meine Lösung war nicht genau die gleiche (ich musste kommentieren) auth substack password-auth), aber dein Kommentar hat mein Problem gelöst! - Nick Williams
sysconfig.org.uk/two-factor-authentication-with-ssh.html - Christian


Ich konnte es endlich schaffen, indem ich platzierte auth [success=done new_authtok_reqd=done default=die] pam_google_authenticator.so nullok oben /etc/pam.d/sshd.

Laut pam.d Man Seite:

  • success=done Wenn Google Authenticator abgemeldet wird, wird keine weitere Authentifizierung mehr durchgeführt, dh es wird keine zusätzliche Aufforderung zur Kennworteingabe angezeigt.
  • default=die Wenn Google Authenticator den Anmeldeversuch ablehnt, wird die Authentifizierung sofort fehlschlagen und die Passwortabfrage wird übersprungen.

So [success=done new_authtok_reqd=done default=die] ist eine Art Mischung zwischen den sufficient und requisite Kontrollwerte, da wir Verhalten von beiden wollen: wenn Erfolg, sofort beenden (ausreichend), und wenn Fehler, auch sofort beenden (erforderlich).

Notiere dass der nullok Argument zu pam_google_authenticator.so bedeutet, dass wenn a ~/.google_authenticator Datei für einen Benutzer nicht gefunden wird, wird die Authentifizierung mit öffentlichen Schlüsseln normal ausgeführt. Dies ist nützlich, wenn ich nur eine Teilmenge meiner Konten mit 2FA sperren möchte.


7
2018-02-09 01:07





Linus Kendalls Antwort sollte auf älteren Systemen funktionieren, aber auf neueren Linux-Rechnern ist es problematisch; Auf meinem Arch Linux-basierten Webserver führt diese Konfiguration dazu, dass pam nach meinem Authentifizierungscode und meinem Passwort fragt, nachdem ich meinen ssh-Schlüssel erhalten habe (d. h. ich brauche alle 3).

Eine einfachere Lösung, die dieses Problem verhindert und auf jedem System funktionieren sollte, besteht darin, den Eintrag zu ändern /etc/pam.d/sshdzu:

auth sufficient pam_google_authenticator.so

Und dann, um die gleichen Änderungen an "/ etc / ssh / sshd" vorzunehmen, die Linus erwähnt hat:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
PasswordAuthentication no

Das sollte Sie nach Ihrem Authentifizierungstoken fragen, nachdem der Server Ihren öffentlichen Schlüssel akzeptiert hat. Es sollte nicht nach Ihrem Passwort fragen.

Wenn Sie ein sftp-Benutzerkonto haben möchten, müssen Sie wahrscheinlich den Google Authenticator umgehen, um es zum Laufen zu bringen. Hier ist ein Vorschlag, wie man das mit einem sftp-Jail sicher macht. Im etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Match User ftp-user
  PasswordAuthentication yes
  AuthenticationMethods password
  ChrootDirectory /path/to/ftp/dir
  ForceCommand internal-sftp

Sie müssen die Berechtigungen für / path / to / ftp / dir root nur schreiben (z. chown root:root /path/to/ftp/dir, chmod 755 /path/to/ftp/dir. Alle Eltern über diesem Verzeichnis benötigen ebenfalls sichere Berechtigungen. Die Art, wie ich das normalerweise mache, besteht darin, das Chroot-Verzeichnis zu erstellen /home/shared/userErstellen eines Verzeichnisses dort (z. B. "Daten") und dann mounten jedes Verzeichnis, das ich so teilen möchte: sudo mount -o bind /path/to/ftp/dir /home/shared/user/data

Wenn Sie alle diese Schritte befolgen, haben Sie öffentlichen Schlüssel + Google Authenticator Login für Ihre SSH-Benutzer und ein funktionierendes Passwort geschütztes SFTP-Konto für die Datenübertragung.


6
2017-12-04 20:24



Das funktioniert großartig. Und da ich mich aus irgendeinem Grund nicht dazu entschließen kann, Common-Auth zu kommentieren, war das idealer als Linus 'Lösung. - Luke Sapan
Danke vielmals! verschwendet eine Nacht debugging ssh, wundernd, warum ich noch Passwort nach Pubkey + Authcode eingeben muss ...... - felix021