Frage:
Kann sowohl die Authentifizierung mit privatem Schlüssel als auch mit Kennwort für die SSH-Anmeldung verwendet werden?
chrisdotcode
2012-07-31 22:46:35 UTC
view on stackexchange narkive permalink

Es scheint, dass sie sich gegenseitig ausschließen, da das Deaktivieren des einen das andere gibt und umgekehrt. Die Zwei-Faktor-Authentifizierung für meine SSH-Server klingt wirklich gut. Gibt es also eine Möglichkeit, dies zu erreichen?

Möchten Sie die SSH-Schlüssel für die Passphrase nicht zählen?
Oh, richtig. Ich hätte das spezifizieren sollen. Nein, das zählt nicht. Ich möchte, dass der Server zweimal authentifiziert werden muss, nicht der Client :-)
AilihygetsCMT - why? What problem are you trying to solve? Can you be more specific? What's your threat model? What risk are you trying to defend against?
@D.W. Bedrohungsmodell dafür: Arbeiten Sie mit Menschen zusammen, denen Sie nicht vertrauen, um die Sicherheit genauso ernst zu nehmen wie Sie. Sie möchten es jemandem unmöglich machen, Ihren Server zu gefährden, wenn sein Laptop mit einem unachtsam unverschlüsselten SSH-Schlüssel gestohlen wird.
@JaneDoe, Wenn dies das Problem ist, kann dies möglicherweise besser durch Richtlinien als durch einen technischen Mechanismus gelöst werden. Das Erfordernis eines Passworts bei jedem Login hat große Nachteile und klingt für mich kontraproduktiv. Ich denke, es ist besser, nur eine Organisationsrichtlinie festzulegen, nach der alle Ihre Systemadministratoren ihren privaten Schlüssel mit einer Passphrase verschlüsseln müssen. (Wenn Sie Ihren Systemadministratoren nicht vertrauen, dass sie diese Richtlinie befolgen, warum lassen Sie sie dann Ihre Systeme verwalten?)
Fünf antworten:
mricon
2012-12-30 19:58:36 UTC
view on stackexchange narkive permalink

In den neuesten Versionen von Fedora und RHEL 6 können Sie RequiredAuthentications2 pubkey, password verwenden, um sowohl die pubkey als auch die Passwortauthentifizierung zu erfordern. In der Regel wird hierfür ein Pubkey- und 2-Faktor-Authentifizierungstoken benötigt, nicht das Kennwort des Benutzers.

Update: Unter RHEL / CentOS 7 und jedem System mit einer neueren Version von OpenSSH können Sie Folgendes verwenden:

  Authentifizierungsmethoden "publickey, password" "publickey, tastaturinteraktiv"  

Es ist auch möglich, die Match-Direktive zu verwenden, um IPs auszuschließen oder Benutzer.

Mit diesen neuen Versionen ist dies die neue (und einfachste) richtige Antwort.
In der Antwort von @Jakuje finden Sie eine neuere SSH-Einrichtung für Linux-Distributionsschlüssel + Passwort. Der Name des Konfigurationsparameters wurde geändert.
Es wäre sinnvoller gewesen, die OpenSSH-Version anstelle eines vagen Bereichs der wichtigsten Distributionsversion zu erwähnen.
dr jimbob
2012-07-31 23:30:42 UTC
view on stackexchange narkive permalink

Sie können sowohl die Authentifizierung mit öffentlichem Schlüssel als auch mit Kennwort auf demselben Server durchführen. Wenn die Authentifizierung mit öffentlichem Schlüssel fehlschlägt, wird die Kennwortauthentifizierung durchgeführt.

Beides zu fordern, erscheint albern und kontraproduktiv, und das Überprüfen von man sshd_config gibt es keine Option Tun Sie dies.

Ihr privater SSH-Schlüssel sollte eine sichere Passphrase haben. Wenn ein Angreifer Ihren privaten Schlüssel erhält, kann er dennoch nichts tun, ohne zuvor Ihre Passphrase erhalten zu haben. Wenn sie diese Passphrase kompromittiert haben (höchstwahrscheinlich mit einem Keylogger oder weil sie eine extrem schwache Passphrase brutal erzwingen), können sie trivialerweise auch jedes gespeicherte Passwort greifen / brutal erzwingen.

Wenn Sie wirklich wollen, könnten Sie es möglicherweise Richten Sie etwas mit beispielsweise ForceCommand ein (z. B. erlauben Sie nur die Authentifizierung mit öffentlichem Schlüssel und leiten Sie den Benutzer dann zu einer Shell, die zur Eingabe eines Kennworts auffordert). Ich empfehle dies nicht.

Eine bessere Alternative, wenn Sie die Gefährdung begrenzen möchten, besteht darin, eine Firewall einzurichten, um IPs zu begrenzen, die den SSH-Port erreichen können. Möglicherweise mit einem zusätzlichen VPN, das irgendwo auf einem Server ausgeführt wird, wenn Sie irgendwann von einem anderen Computer aus tunneln müssen. Sie können auch knockd verwenden, um nach einem bestimmten Port-Klopfmuster ein Loch in einer Firewall zu öffnen. Beachten Sie jedoch, dass jeder, der den Datenverkehr abhört, das Klopfmuster erneut abspielen kann, um einen Port zu öffnen. P. >

Richtig. Ich hätte den Hinweis aus dem Kommentar von @Phillip's übernehmen sollen, da der private Schlüssel bereits ein Passwort benötigt, ist er bereits eine Form der Zwei-Faktor-Authentifizierung. Und ja, ich werde auch einen Port-Knocking-Daemon einrichten, aber ich konnte nicht aus den auf der Website angegebenen Implementierungen auswählen. Vielen Dank für die Überweisung und Antwort.
Betrachten Sie den Fall, in dem der Angreifer die Kontrolle über einen Computer übernommen hat, auf dem der Benutzer einen Authentifizierungsagenten (z. B. "ssh-agent") zum Zwischenspeichern des privaten Schlüssels verwendet hat.Der Angreifer verfügt nicht über die Passphrase, kann jedoch den privaten Schlüssel verwenden, bis der Agent seinen Cache geleert hat.In diesem Szenario kann das Erfordernis des Schlüssels * und * des Anmeldekennworts hilfreich sein.
* "Wenn ein Angreifer also Ihren privaten Schlüssel erhält, kann er immer noch nichts tun, ohne zuvor Ihre Passphrase erhalten zu haben. Wenn er diese Passphrase kompromittiert hat (höchstwahrscheinlich mit einem Keylogger; oder weil er eine extrem schwache Passphrase erzwungen hat), kann er dies trivial tunAuch Grab / Brute erzwingen Sie ein gespeichertes Passwort. "* Richtig, aber es gibt noch einen weiteren Grund für die Verwendung eines serverseitigen Passworts: Verhindern Sie Offline-Cracking.Z.B.Von einem mobilen Gerät aus können 4 Ziffern eine sichere zusätzliche Authentifizierungsmaßnahme sein, wenn sie nach 3 Versuchen auf unbestimmte Zeit gesperrt sind. Mit einer Passphrase auf dem Privkey können Sie jedoch keine Sperrung durchführen.
Jakuje
2015-09-22 21:27:52 UTC
view on stackexchange narkive permalink

(Cross-Posting SO-Antwort mit aktualisierter Lösung bis heute)

Wenn Sie die Handbuchseite für sshd_config (5) dort lesen ist die Option AuthenticationMethods , die die Liste der Methoden enthält, die Sie übergeben müssen, bevor Sie Zugriff erhalten. Ihr erforderliches Setup ist:

  AuthenticationMethods publickey, Kennwort  

Diese Methode sollte auf allen aktuellen Linux-Systemen mit dem neuesten openssh (openssh-6, openssh-7) funktionieren ).

Ältere Systeme

Die einzige mir bekannte Ausnahme ist RHEL 6 (openssh-5.3), bei der unterschiedliche Optionen mit denselben Werten festgelegt werden müssen (wie in der anderen Antwort beschrieben):

  RequiredAuthentications2 publickey, Passwort  
In "AuthenticationMethods" sollte anstelle von "pubkey" "publickey" stehen.Überprüfen Sie: `man sshd_config`
Phillip Nordwall
2012-08-01 00:18:57 UTC
view on stackexchange narkive permalink

Ich habe mich etwas genauer damit befasst und mir Folgendes ausgedacht.

Sie könnten PAM für die Zwei-Faktor-Authentifizierung verwenden, aber dabei werden Sie keine SSH-Schlüssel verwenden, sondern einen verschiedene zwei Faktoren.

Sie können beispielsweise Google mit seiner Zwei-Faktor-Authentifizierung verwenden und pam zur Authentifizierung verwenden, wie unter

http: //www.techrepublic beschrieben. com / blog / opensource / Zwei-Faktor-SSH-Authentifizierung-über-Google-Secures-Linux-Logins / 2607

können wir SSHkeys AND 2FA verwenden?
Die Verwendung eines passphrasierten Schlüssels gibt Ihnen zwei Faktoren, da es sich um etwas handelt, das Sie haben und das Sie kennen.
Luca Scotto Lavina
2018-06-05 13:55:51 UTC
view on stackexchange narkive permalink

Die einzige Lösung, die für mich funktioniert hat, ist das Folgende in der Datei / etc / ssh / sshd_config (getestet mit einem CentOS7):

  PubkeyAuthentication yes AuthenticationMethods publickey passwordAuthorizedKeysFile .ssh / autorisierte_keysPasswordAuthentication yes PermitEmptyPasswords noChallengeResponseAuthentication noUsePAM yes  

Dies bedeutet, dass PAM aktiviert ist, dass jede Zeile, die den Publik-Schlüssel betrifft, aktiviert ist und dass AuthenticationMethods schließlich beide Methoden ordnungsgemäß auflistet Wurde von Jakuje geschrieben, sollten Sie nach AuthenticationMethods kein Komma zwischen publickey und password einfügen.

Sie sollten ein Komma zwischen den Authentifizierungsmethoden einfügen, wenn diese Methoden kombiniert werden sollen, d. H. ** publickey ** UND ** password ** (wie in der Frage).In Ihrem Beispiel ist das Verhalten anders. Entweder ** publickey ** ODER ** password ** wird akzeptiert.
Ich kann nicht glauben, dass das bei mir funktioniert hat.Durch Entfernen des Kommas zwischen "publickey" und "password" kann die Authentifizierung entweder durch dieses oder jenes erfolgen.Danke für diese Lösung


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...