Sendet ssh das Passwort über das Netzwerk?

8

Grundsätzlich steht die gesamte Frage in der Überschrift: Sendet ssh das Passwort über das Netzwerk? Vorausgesetzt natürlich, dass die Anmeldung über Benutzername und Passwort verwendet wird.

Ich frage, denn wenn ssh das Passwort nicht über das Netzwerk sendet, kann ein Mann in der Mitte das Passwort des Benutzers nicht erhalten, selbst wenn der Benutzer den mutmaßlichen Host zu seiner Datei "unknown_hosts" hinzufügt.

Jemand sagte, dass es muss, also schrieb ich ein Gegenbeispiel in einen Kommentar. Da die Frage, wie es sonst möglicherweise funktionieren könnte, jetzt immer wieder auftauchte, kopiere ich diesen Kommentar hier.

Der Server kann dem Client mitteilen, welcher Hash verwendet werden soll. [Das gleiche, mit dem die Passwörter in der Schattendatei des Servers gehasht werden.] Der Client kann dann den Hash berechnen, der in der Schattendatei des Servers enthalten sein soll, aber wir rufen den auf dem Server auf. So wissen sowohl der Server als auch der Client ψ. Der Client kann dann ein zufälliges Salz σ auswählen und .an den Server senden (Hash (ψ.σ), σ) (wobei der Verkettungsoperator ist). Der Server hasht dann ψ'.σ und prüft, ob das erste Element des vom Client empfangenen Tupels mit diesem Hash übereinstimmt. In diesem Fall kennt der Client das Kennwort.

— UTF-8
quelle

Wie könnte es sonst funktionieren?

— Leichtigkeitsrennen im Orbit

@LightnessRacesinOrbit Ich habe es der Frage hinzugefügt.

— UTF-8

@ UTF-8, ich erwähnte auch, dass für die Authentifizierung mit öffentlichem Schlüssel kein Klartextkennwort gesendet werden muss und dass Dinge wie SRP existieren. Ich dachte, es sei aus dem Kontext klar, dass "muss" keine genaue Aussage ist, sondern ein Hinweis darauf, wie aktuelle, übliche Implementierungen funktionieren. Was getan werden könnte, scheint eine andere Frage zu sein.

— Ilkkachu

Zu Ihrer Information, es gibt echte Sicherheitsprotokolle, die solche wissensfreien Beweise durchführen, wie sie in Sicherheitskreisen genannt werden. Siehe diese verwandte Frage. Es gibt das (etwas zwielichtige) Secure Remote Password-Protokoll (SRP) und das neuere OPAQUE. Die Frage verweist auf diesen Artikel von Matthew Green , der eine schöne Beschreibung gibt.

— JanKanis

SSH, das das Passwort so wie es ist an den Server sendet, hat auch einige Vorteile. SSH verwendet (normalerweise) PAM, den steckbaren Authentifizierungsmanager, um die eigentliche Kennwortüberprüfung durchzuführen. PAM wird auch für die reguläre Desktop-Anmeldung verwendet, sodass es offensichtlich nichts über Netzwerke weiß. PAM bietet viel mehr als nur das Überprüfen des Kennworts. Es kann auch Dinge wie das Einrichten der Sitzung, das Entsperren verschlüsselter Festplatten und Kennwortmanager, das Behandeln des Kennwortablaufs usw. erledigen. Es kann auch für die Zweitfaktorauthentifizierung mit Token konfiguriert werden. Durch die Verwendung von PAM ist alles, was auch in SSH verfügbar ist, kostenlos.

— JanKanis

7

Wenn Sie die Kennwortauthentifizierung verwenden, sendet SSH das Kennwort über das Netzwerk. Die Verbindung ist verschlüsselt, sodass Lauscher das Kennwort nicht sehen können. Die Verbindung wird authentifiziert, vorausgesetzt, Sie klicken nicht blind durch die Meldung "Die Authentizität von ... kann nicht hergestellt werden", sodass Ihr Kennwort nur an den legitimen Server gesendet wird.

Die langweilige Antwort auf das „Warum“ lautet, dass das SSH-Protokoll dies erfordert.

Die weniger langweilige Antwort ist, dass die Passwortauthentifizierung so funktionieren muss. Es gibt Möglichkeiten, eine Authentifizierung durchzuführen, die auf diese Weise nicht funktioniert. Dies ist jedoch keine einfache Kennwortauthentifizierung mehr.

Die meisten Authentifizierungsprotokolle, die weiter fortgeschritten sind als die einfache Kennwortauthentifizierung, haben die nette Eigenschaft, dass der Client keine geheimen Daten an den Server sendet, die ein böswilliger Server verwenden könnte, um sich als Benutzer auf einem dritten Server auszugeben. Bei der Authentifizierung mit öffentlichem SSH- Schlüssel , der häufigsten SSH-Authentifizierungsmethode außer Kennwörtern, funktioniert dies, da der Client eine Signatur (die den privaten Schlüssel erfordert) von Daten sendet, die die Sitzungskennung enthalten. Wenn der böswillige Server versuchen würde, sich bei einem dritten Server zu authentifizieren, müsste er eine Signatur von Daten mit einer anderen Sitzungskennung generieren, was ohne den privaten Schlüssel, der auf dem Client verbleibt, nicht möglich wäre.

Beachten Sie, dass dies keine kennwortbasierte Authentifizierung ist, wenn Sie die Authentifizierung mit öffentlichem Schlüssel verwenden und ein Kennwort eingeben müssen, um den Schlüssel zu verwenden. Das Kennwort zur Verwendung des Schlüssels wird ausschließlich auf der Clientseite verwendet, um den Schlüssel aus der Schlüsseldatei zu lesen. Bei Verwendung der Authentifizierung mit öffentlichem Schlüssel weiß der Server nicht, ob der Schlüssel in einer verschlüsselten Datei gespeichert wurde.

Für die Kennwortauthentifizierung muss das Kennwort an den Server gesendet werden. Das Senden eines Hashs des Passworts anstelle des Passworts selbst hilft nicht, da das Passwort dann zum Hash wird: Ein Angreifer müsste nicht das tatsächliche Passwort finden, sondern nur den Hash. Ein Angreifer könnteAngriff durch Finden des tatsächlichen Passworts, so gibt es keine Verbesserung. Aber wenn der Angreifer in Ihrem vorgeschlagenen Schema den Hash, aber nicht das Passwort gefunden hat, würde dies ausreichen. Im Gegensatz dazu muss der Angreifer bei einer normalen kennwortbasierten Authentifizierung das Kennwort kennen, da er weiß, dass der Hash nicht gut genug ist. Wenn das Kennwort stark genug ist, kann der Angreifer das Kennwort nicht aus dem Hash finden. In der Praxis kennt der Angreifer möglicherweise den Hash, aber nicht das Kennwort, weil es dem Angreifer gelungen ist, die Datenbank mit Kennwort-Hashes vom Server zu extrahieren, möglicherweise aus einer ungeschützten Sicherung oder über eine Sicherheitsanfälligkeit auf dem Server. Solche Schwachstellen auf Websites machen die Nachrichten ziemlich oft.

Ihr vorgeschlagenes Protokoll ist weniger gut als das Standardprotokoll. Rollen Sie nicht Ihre eigene Krypto!

— Gilles 'SO - hör auf böse zu sein'
quelle

2

Oh, du hast Recht. Das würde wirklich bedeuten, dass es ausreicht, den Hash zu kennen. Ich habe mich darauf konzentriert, Benutzer, die Passwörter wiederverwenden, sicher zu halten und nicht an durchgesickerte Schattendateien zu denken. Vielleicht führt das Träumen von etwas innerhalb weniger Sekunden beim Schreiben eines Kommentars unter einer Antwort auf StackExchange doch nicht zu den besten Sicherheitskonzepten. ;-)

— UTF-8

Ich bin etwas anderer Meinung, dass das Senden des Passworts immer besser ist als das Senden eines Hashs. Es gibt gängige Szenarien, in denen Benutzer dasselbe synchronisierte Kennwort für mehrere Systeme verwenden. Eines dieser Systeme kann an Dritte ausgelagert werden. Dann wäre es vorteilhaft, nur den Hash an den Dritten und nicht das Passwort weiterzugeben, da der Hash nicht auf den anderen (anderen) Systemen verwendet werden kann, während das Passwort universell ist und auf allen Systemen verwendet werden kann. (Ich gehe von einem richtigen Hash aus, der auch mit Regenbogentabellen wie bcrypt oder PBKDF2 nicht rückgängig gemacht werden kann.)

— Johannes Overmann

@JohannesOvermann Das ist ein anderes Szenario als das, das ich in meiner Antwort besprochen habe: Meine Antwort handelt nur von einem Zwei-Parteien-Szenario, bei dem sich ein Client bei einem Server authentifiziert. In Ihrem Szenario mit drei Parteien funktioniert die von Ihnen vorgeschlagene Lösung aus dem Grund nicht, den ich in meiner Antwort erläutere: Der Server eines Drittanbieters kann nicht wissen, dass der Anforderer das Kennwort kennt. Es ist auch unsicher, weil der Dritte die Möglichkeit bekommt, den Hash mit brutaler Gewalt umzukehren. Für dieses Szenario gibt es weit verbreitete Lösungen, die tatsächlich sicher funktionieren, z. B. Kerberos.

— Gilles 'SO - hör auf böse zu sein'

@ Gilles Ja, ich bin damit einverstanden, dass Kerberos der richtige Weg ist, dies zu tun. Ich habe immer noch Bedenken, dass über ssh und viele andere passwortbasierte Systeme das Passwort so an die andere Seite übertragen wird, dass die andere Seite das Klartext-Passwort kennt. Meine Hauptpunkte sind: 1. Ja, der Hash ist so gut wie das Passwort, außer dass der Hash vom Anwendungsfall abhängig ist, während das Passwort universell ist. 2. Wenn Sie das Passwort im Klartext (verschlüsselt) übergeben, besteht kein Unterschied zwischen "Ich bin berechtigt, auf das System zuzugreifen" und "Ich vertraue dem System, das ich autorisiere, mein Passwort zu kennen", was unangenehm ist.

— Johannes Overmann

@ Gilles Wie auch immer, ich schätze Ihre Eingabe (es bringt mich immer noch zum Nachdenken) und ich habe das Gefühl, wir sind uns beide einig, dass die passwortbasierte Authentifizierung an sich nicht der beste Weg ist, sich zu authentifizieren. Es ist ein ziemlich grober Fallback.

— Johannes Overmann

12

Ja. Das Kennwort wird über die verschlüsselte Verbindung gesendet, jedoch im Klartext an den Remote-Server.

Die übliche Methode zur Authentifizierung besteht darin, dass der Server einen Hash des Kennworts berechnet und mit einem auf dem Server gespeicherten Wert vergleicht. Es gibt verschiedene Möglichkeiten, Hashes zu speichern, und bei aktuellen Implementierungen weiß der Client nicht, was der Server verwendet. ( siehe zB die cryptManpage ). (Selbst wenn dies der Fall wäre, würde das einfache Senden eines Hashs des Passworts den Hash ohnehin dem Passwort entsprechen.)

Wenn der Server PAM verwendet, implementieren die PAM-Module möglicherweise die Authentifizierung mit nahezu jeder Methode, für die möglicherweise das Kennwort im Klartext erforderlich ist.

Bei der Authentifizierung mit öffentlichen Schlüsseln wird der Schlüssel jedoch nicht an den Remote-Host gesendet. (Einige Erklärungen und Links dazu in einer Frage zu security.SE )

Es gibt auch kennwortbasierte Authentifizierungsalgorithmen wie SRP , bei denen das Kennwort nicht im Klartext an das andere Ende gesendet werden muss. Obwohl SRP nur für OpenSSH als externer Patch implementiert zu sein scheint.

— ilkkachu
quelle

@ UTF-8, so etwas könnte natürlich implementiert werden. Oder so etwas wie CRAM-MD5. Soweit mir bekannt ist, ist dies jedoch nicht der übliche Fall. Auch so etwas würde clientseitige Änderungen erfordern. Wenn Sie das Kennwort einfach senden, kann der Server selbst entscheiden, wie es gehasht werden soll.

— Ilkkachu

1

@ UTF-8, Sie könnten so etwas tun, aber es wäre nicht mehr der passwordAuthentifizierungstyp, der in den SSH-Standards definiert ist. Es wäre eine Variante des keyboard interactiveAuthentifizierungstyps.

— user4556274

1

@ user4556274 oder möglicherweise eine völlig separate Authentifizierungsmethode, da ohnehin Codeänderungen erforderlich wären und der RFC ziemlich stark impliziert, dass keyboard-interactivedies für die Eingabe durch den Benutzer gedacht ist.

— Ilkkachu

2

Es sollte beachtet werden, dass die Kennwortauthentifizierung veraltet ist und viele problematische Konsequenzen für die Sicherheit hat und keyboard-interactivenoch schlimmer ist, wenn kennwortähnliche Geheimnisse aufgrund von Timing-Angriffen übermittelt werden. Moderne Konfigurationen sollten nur die Authentifizierung mit öffentlichem Schlüssel verwenden und die Kennwortauthentifizierung deaktivieren. Es gibt keinen Grund für die Benutzer auch Konten haben mehr Passwörter.

— R .. GitHub STOP HELPING ICE

1

@R .., hast du irgendwelche Referenzen dazu? Probleme mit password, meine ich, und vor allem mit dem Timing-Angriff?

— Ilkkachu

3

Ja, ssh sendet das Passwort über das Netzwerk, aber nachdem die End-to-End-Verschlüsselung ausgehandelt wurde. Siehe Abschnitt 8 von RFC 4252, der besagt, dass eine Kennwortauthentifizierungsnachricht enthältplaintext password in ISO-10646 UTF-8 encoding [RFC3629]

— user4556274
quelle

3

Wenn Sie ein Passwort basiertes Authentifizierungsschema verwenden Sie dann, ja wird das Passwort über das Netzwerk bis zum Endpunkt geführt ...

Aber es ist ein verschlüsselter Kanal.

z.B

% ssh remotehost
user@remotehost's password: 

bash$ logout

In diesem Szenario wurde das Kennwort verschlüsselt über das Netzwerk gesendet.

Aus diesem Grund ist es sehr wichtig, die known_hostsEinträge richtig zu behandeln und viel Aufmerksamkeit zu schenken, wenn Sie die @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @Nachricht sehen! Das ist Ihre Verteidigung gegen einen MITM-Angriff.

— Stephen Harris
quelle

0

SSH sendet die Benutzer-ID und das Kennwort im Klartext innerhalb eines verschlüsselten Kanals über das Netzwerk. Aus diesem Grund werden Sie beim Verbinden eines neuen Hosts aufgefordert, den Schlüssel zu akzeptieren. Im Falle eines Man-in-the-Middle-Angriffs mit einem bekannten Host verweigert SSH die Verbindung, bis Sie den alten Schlüssel entfernen.

Das Klartextkennwort ist an den Endpunkten, Ihrem Computer und dem Remotecomputer verfügbar. Es ist möglich, die Kennwortauthentifizierung zu deaktivieren. In diesem Fall wird das Kennwort weder angefordert noch an den Remote-Host gesendet.

Es ist sicherer, die schlüsselbasierte Authentifizierung mit einem kennwortgeschützten Schlüssel zu verwenden. Sie müssen Ihren Schlüssel zum Remote-System hinzufügen lassen. Der öffentliche Schlüssel ist eine Textdatei, die von vielen Mechanismen übertragen werden kann. Bei Verwendung der schlüsselbasierten Authentifizierung können Einschränkungen für die Verwendung des Schlüssels festgelegt werden.

— BillThor
quelle

Siehe RFC 4252 # 8 .

— user207421

Ihre Antwort widerspricht sich an mehreren Stellen.

— Leichtigkeitsrennen im Orbit

Der erste Satz ist wahr. Dies ist jedoch nicht der Grund, warum Sie aufgefordert werden, den Schlüssel eines neuen Hosts zu akzeptieren.

— Gilles 'SO - hör auf böse zu sein'

"Nur-Text in einem verschlüsselten Kanal" ist jetzt ein Widerspruch.

— user207421

@EJP Das Kennwort ist Klartext, wie er für eines von mehreren Nicht-Klartextformaten verwendet wird. Der Kanal wird entsprechend dem von Telnet verwendeten unverschlüsselten Kanal verschlüsselt. Wenn Sie jemanden dazu bringen, eine Verbindung zu einem Honeypot-Server herzustellen, erfassen Sie ein Nur-Text-Kennwort.

— BillThor