it-swarm.com.de

Der Versuch, SSH mit öffentlichem Schlüssel (kein Passwort) + Google Authenticator unter Ubuntu 14.04.1 zu erhalten

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

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

Durch Befolgen/Anpassen dieser Anweisungen habe ich eine Passwortabfrage sowie eine Google Auth-Eingabeaufforderung erhalten:

Ich habe das Paket installiert und meine Dateien /etc/ssh/sshd_config Und /etc/pam.d/ssh Bearbeitet

In /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
AuthenticationMethods  publickey,keyboard-interactive
UsePAM yes

und am Ende 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ß, dass PAM auftragsabhängig ist, aber ist sshd_config Auch?

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

21
JT.

Habe es gut gemacht, habe zuerst:

apt-get install libpam-google-authenticator

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

# @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 öffentlichem Schlüssel eine Eingabeaufforderung "Bestätigungscode". Ich bin nicht sicher, wie ich die Authentifizierung mit Kennwort + Token OR Schlüssel + Token) zulassen würde, da ich die Kennwortauthentifizierungsmethode jetzt effektiv aus PAM entfernt habe.

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

28
Linus Kendall

Ich konnte dies endlich zum Laufen bringen, indem ich auth [success=done new_authtok_reqd=done default=die] pam_google_authenticator.so nullok Oben auf /etc/pam.d/sshd Platzierte.

Laut der pam.d Manpage :

  • success=done Bedeutet, dass bei der Abmeldung von Google Authenticator keine weitere Authentifizierung durchgeführt wird, dh keine zusätzliche Kennwortabfrage.
  • default=die Bedeutet, dass die Authentifizierung sofort fehlschlägt, wenn Google Authenticator den Anmeldeversuch ablehnt und die Eingabeaufforderung für das Kennwort überspringt.

[success=done new_authtok_reqd=done default=die] Ist also eine Art Mischung zwischen den Kontrollwerten sufficient und requisite, da wir Verhalten von beiden wollen: Wenn Erfolg, sofort beenden (ausreichend), und wenn Fehler, auch sofort kündigen (erforderlich).

Beachten Sie, dass das Argument nullok für pam_google_authenticator.so bedeutet, dass die Authentifizierung mit öffentlichem Schlüssel wie gewohnt fortgesetzt wird, wenn für einen Benutzer keine ~/.google_authenticator - Datei gefunden wird. Dies ist nützlich, wenn ich nur eine Teilmenge meiner Konten mit 2FA sperren möchte.

7
bluegate010

Die Antwort von Linus Kendall sollte auf älteren Systemen funktionieren, auf neueren Linux-Computern ist dies jedoch problematisch. Auf meinem Arch Linux-basierten Webserver führt diese Konfiguration dazu, dass pam nach Erhalt meines SSH-Schlüssels nach meinem Authentifizierungscode und meinem Passwort fragt (d. h. ich benötige alle 3).

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

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.

Nebenbei bemerkt, wenn Sie ein SFTP-Benutzerkonto haben möchten, müssen Sie wahrscheinlich den Google-Authentifikator umgehen, damit es funktioniert. Hier ist ein Vorschlag, wie dies mit einem SFTP-Gefängnis sicher durchgeführt werden kann. In 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 nur für/path/to/ftp/dir root schreiben (z. B. chown root:root /path/to/ftp/dir, chmod 755 /path/to/ftp/dir. Alle Eltern über diesem Verzeichnis benötigen ebenfalls sichere Berechtigungen Normalerweise erstellen Sie dazu das chroot-Verzeichnis /home/shared/user, erstellen dort ein Verzeichnis (z. B. 'data') und hängen dann das Verzeichnis ein, das ich wie folgt freigeben möchte: Sudo mount -o bind /path/to/ftp/dir /home/shared/user/data

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

6
Mike Dacre