Wird Ihr SSH-Passwort angezeigt, wenn Sie versuchen, eine Verbindung zum falschen Server herzustellen?

192

Wenn Sie versehentlich versuchen, mit Kennwortinformationen eine Verbindung zum falschen Server herzustellen, kann der Administrator dann das von Ihnen verwendete Kennwort lesen und protokollieren?

ssh password

— vfclists
quelle

11

Stellt die SSH-Kennwortauthentifizierung dem Server das Kennwort zur Verfügung?

— Jamesdlin

41

In einem ssh-Client authentifizieren Sie zuerst den Server und sagen dabei "Ich vertraue darauf, dass ich diesem Server mein Passwort mitteilen kann". Achten Sie das nächste Mal genauer auf die Meldung, die Sie zuerst gesehen haben: "Die Echtheit von X kann nicht festgestellt werden. Der RSA-Fingerabdruck lautet" Y ". Sind Sie sicher, dass Z" (Ja / Nein) "ist? jedes Mal automatisch mit Ja antworten .

— Kubanczyk

6

Es ist möglich, PasswordAuthentication noin OpenSSH Standardeinstellungen vorzunehmen und diese nur für vertrauenswürdige Server zu aktivieren (falls erforderlich). In Kombination mit strengen Host - Schlüssel Kontrolle, soll dies vor allem Sie aussetzt Ihr Passwort schützen, zu einem Preis in Bequemlichkeit natürlich.

— Hobbs

6

@kubanczyk, wenn Sie möchten, dass SSH zu "internal-www.my-company.com" wechselt, aber versehentlich "ssh www.my-company.com" eingibt, schützt Sie diese Eingabeaufforderung nicht - wahrscheinlich sind es beide Server Auf Ihrer Vertrauensliste wird nur einer von Ihnen und der andere von einem Dritten geführt.

— Mark

@ Hobbs, ChallengeResponseAuthentication nodenke ich auch

— ilkkachu

215

Einfach ausgedrückt: ja

Mehr Details...

Wenn Sie eine Verbindung zu meinem Computer herstellen, wissen Sie nicht, ob ich einen normalen sshServer oder einen Server verwende, der so geändert wurde, dass das übergebene Kennwort ausgegeben wird.

Weiterhin müsste ich nicht unbedingt modifizieren sshd, sondern könnte ein PAM-Modul schreiben (zB mittels pam_script), dem Ihr Passwort übergeben wird.

Also ja. NIEMALS Ihr Passwort zu einem nicht vertrauenswürdigen Server senden. Der Besitzer des Geräts hätte es leicht so konfigurieren können, dass alle versuchten Kennwörter protokolliert werden.

(Tatsächlich ist dies in der Infosec-Welt keine Seltenheit. Richten Sie einen Honeypot-Server ein, um die versuchten Passwörter zu protokollieren.)

— Stephen Harris
quelle

13

Richtig. Standardmäßig ist der Standard sshdist nicht einloggen Passwörter. (Wenn Sie Ihr Passwort als Anmeldenamen eingeben, wird es protokolliert, aber das ist ein anderes Problem.) Der Standard sshdist ein Sicherheitstool, und so werden Anmeldeinformationen wie diese nicht protokolliert :-)

— Stephen Harris

116

Ein weiterer Grund, um öffentliche / private Schlüsselpaare zu verwenden ...

— gerrit

3

Ich habe mich eine Weile über die Verwendung von Kennwörtern gewundert, und vor kurzem wurde mir klar, dass der Versuch, mich auf den falschen Servern anzumelden, eine gute Möglichkeit ist, mein Kennwort einem böswilligen Serveradministrator mitzuteilen.

— vfclists

10

Die Anmeldung von @vfclists auf dem falschen Server ist auch genau der Grund, warum Ihr sshd-Client den Fingerabdruck für jeden Server speichert. Wenn Sie sich zum ersten Mal verbinden, akzeptieren Sie diesen Fingerabdruck. Wenn er später nicht übereinstimmt, erhalten Sie eine riesige Warnung, die Sie beachten sollten.

— Hometoast

44

Besserer Rat: Verwenden Sie niemals die Kennwortauthentifizierung für ssh. Das Protokoll hat Pubkey-Authentifizierung aus sehr guten Gründen; benutze es!

— R ..

52

Ja.

Das Kennwort wird gesendet, nachdem die verschlüsselte Verbindung hergestellt wurde, der Remote-Server erhält das Kennwort jedoch im Klartext.

Wenn Sie sich dafür interessieren, ist die beste und einfachste Lösung die Verwendung von SSH-Schlüsseln.

Wenn Sie Computer haben, die keine Schlüssel annehmen können, besteht eine Lösung darin, ein Tool zu erstellen, das Ihre Kennwörter sicher speichert und dann verwendet sshpass, um abhängig vom Server, zu dem Sie eine Verbindung herstellen, immer das richtige Kennwort zu senden.

Der Grund, warum das Passwort im Klartext gesendet wird, besteht darin, dass alle Entscheidungen über die Handhabung und Speicherung auf der Remote-Seite liegen und der Client völlig dumm sein kann. In den letzten zehn Jahren wurden in Linux- und BSD-Systemen verschiedene Kennwort-Hashing-Formate (Speicherformate) verwendet ( crypt (3) ), von denen keines vom Client unterstützt werden muss.

Das liegt aber auch teilweise an der Geschichte (dh es war schon immer so). Es gibt bessere Challenge-Response-Authentifizierungsprotokolle, die auch mit Kennwörtern verwendet werden können. Zum Beispiel SRP , die den Parteien während der Authentifizierung ein gemeinsames Geheimnis zur Verfügung stellt. Es wurde für einige SSH-Server implementiert, aber der Patch für OpenSSH ist für eine (sehr) alte Version.

— ilkkachu
quelle

1

Das Problem bei Challenge-Response-Protokollen für die Kennwortauthentifizierung besteht darin, dass einige von ihnen erfordern, dass der Server das Kennwort im Klartext speichert. Wenn das Challenge-Response-Protokoll es dem Server ermöglicht, ein Hash-Passwort zu speichern, ist höchstwahrscheinlich ein sehr spezifischer Hash-Algorithmus erforderlich.

— Kasperd

8

Passwörter werden in der Regel im Klartext gesendet (dh nicht im Klartext, sondern nur mit dem Schutz, den die zugrunde liegende SSH | TLS | -Verbindung bietet). Wenn ein System fordert, dass Kennwörter clientseitig gehasht und der Hash gesendet werden, können die Server das tatsächliche Kennwort nicht ableiten und gewähren stattdessen jedem Zugriff, der den Kennwort-Hash bereitstellen kann , wodurch der Hash- Kennwort-Äquivalent wird .

— Blacklight Shining

1

@BlacklightShining Es gibt zwar wissensfreie Kennwortnachweise, diese werden jedoch in SSH nicht verwendet, da die Standardkennwortdatenbank für sie nicht verwendet werden kann und es keinen wirklichen Grund gibt, sie anstelle der schlüsselbasierten Authentifizierung zu verwenden.

— Random832

Wo kann ich die zur Authentifizierung verwendeten Passwörter sehen? Sie sind nicht in /var/log/auth.log, wo dann?

— アアックス

OpenSSH protokolliert keine fehlgeschlagenen oder sonstigen Passwörter. (Ich bin mit anderen SSH-Servern nicht sehr vertraut.) In fast allen legitimen Installationen würde jeder Wert, den dies bietet, durch das Risiko aufgewogen, das mit dem absichtlichen Aufzeichnen von Passwörtern verbunden ist - von denen einige von legitimen Benutzern bereitgestellt wurden, die einen Tippfehler gemacht haben oder ein falsches, aber für etwas anderes richtiges Passwort ausprobiert haben - im Klartext. Wenn Sie jedoch einen guten Grund dafür haben, ist es einfach, OpenSSH zu patchen.

— musicinmybrain

10

Um auf Stephen Harris 'Antwort aufzubauen, habe ich hier eine Echtzeitansicht erstellt, die zeigt, was ein modifiziertes PAM-Authentifizierungsskript erfassen kann, wenn eine Verbindung zu einer Box über ssh (eine Art Honeypot) hergestellt wird. Ich verwende eine modifizierte Version der PAM-Bibliothek lib-storepw.

https://livesshattack.net

https://livesshattack.net/about

— Gänsehaut.
quelle

4

Antworten, bei denen es sich in erster Linie um Links handelt, sind verpönt, falls der Link nicht mehr verfügbar ist (es scheint, als würden Sie diese Site persönlich pflegen, aber dennoch). Sie sollten ein wenig beschreiben, wie Sie dies mit Ihrem Auth-Skript für Leser geschafft haben.

— Centimane

es funktioniert nicht mehr, ich habe eine riesige Zeichenfolge als Passwort gesendet, ich denke, das hätte es vielleicht kaputt gemacht, sorry: - /

— scottydelta

@scottydelta Obwohl ich nicht darauf eingegangen bin, kann es eine Pufferbeschränkung für die Kennwortgröße geben, die das PAM-Modul oder der SSH-Dämon selbst bei einem Authentifizierungsversuch akzeptieren können. Die Site funktioniert immer noch so, wie ich es beabsichtigt hatte, obwohl sie die vom sshd- oder PAM-Modul akzeptierte Puffergrenze einhält, wenn dies tatsächlich der Fall ist.

— Willie S.

Steht die Quelle für Ihr modifiziertes lib-storepw aus Interesse anderen zur Verfügung?

— Tim Fletcher

2

SSH ist ein Protokoll, das gegenseitiges Vertrauen erfordert. Aus diesem Grund verwaltet der OpenSSH-Client eine Datei known_hosts, um die Vertrauenswürdigkeit bei der ersten Verwendung zu implementieren.

Wenn Sie versuchen, sich bei einem SSH-Server anzumelden, unabhängig davon, wer die Software geliefert hat oder welche Daten für die Protokollierung konfiguriert sind, nehmen Sie an einem Authentifizierungsverfahren teil. Wenn Sie die Kennwortauthentifizierung verwenden, übertragen Sie Ihr Kennwort an diesen Server. Dies ist ein Grund, warum asymmetrische Kryptografie (öffentlicher Schlüssel, Zertifikate) empfohlen wird. Durch die Kryptografie mit öffentlichem Schlüssel wird das Risiko einer Offenlegung Ihrer Anmeldeinformationen erheblich verringert. (Dies schützt Sie jedoch möglicherweise nicht vor einem MitM-Angriff, wenn Sie die Weiterleitung von ssh-agent oder ein ähnliches Schema verwenden.)

— jvoorhis
quelle

SSH erfordert kein gegenseitiges Vertrauen oder zumindest kein symmetrisches Vertrauen. Es ist wichtig, genau zu sein: Bei known_hosts geht es um Authentizität, nicht um Vertrauen. Wie Sie bereits betont haben, ist es sicher, einen öffentlichen Schlüssel auf einem weniger vertrauenswürdigen Host zu platzieren. In der Tat ist die Verwendung eines Kennworts zum Anmelden dort ebenfalls "sicher", vorausgesetzt, Sie verwenden dieses Kennwort nicht erneut. (Es ist natürlich nur so sicher, wie Sie dem Server vertrauen.) Sogar hostbasierte SSH-Anmeldungen sind von asymmetrischer Vertrauenswürdigkeit abhängig.

— Markhahn