it-swarm.com.de

Warum ist die SSH-Kennwortauthentifizierung ein Sicherheitsrisiko?

In den meisten Handbüchern zur OpenSSH-Konfiguration wird empfohlen, die Kennwortauthentifizierung zugunsten der schlüsselbasierten Authentifizierung zu deaktivieren. Meiner Meinung nach hat die Passwortauthentifizierung jedoch einen erheblichen Vorteil: Sie kann von absolut überall ohne Schlüssel eine Verbindung herstellen. Bei Verwendung immer mit einem sicheren Passwort sollte dies kein Sicherheitsrisiko darstellen. Oder sollte es?

69
Septagram

Es gibt Vor- und Nachteile für die pw- oder schlüsselbasierte Authentifizierung.

In einigen Fällen ist beispielsweise die schlüsselbasierte Authentifizierung weniger sicher als die Kennwortauthentifizierung. In anderen Fällen ist es pw-basiert, was weniger sicher ist. In einigen Fällen ist man bequemer, in anderen weniger.

Alles läuft darauf hinaus: Wenn Sie eine schlüsselbasierte Authentifizierung durchführen, sichern Sie Ihren Schlüssel muss mit einer Passphrase. Wenn Sie nicht ssh-agent ausführen (ssh-agent befreit Sie jedes Mal von der Eingabe Ihrer Passphrase), haben Sie in Bezug auf die Benutzerfreundlichkeit nichts gewonnen. Sicherheit ist umstritten: Der Angriffsvektor wurde jetzt vom Server auf SIE oder Ihr Konto oder Ihren persönlichen Computer verschoben (...) - diese können leichter zu brechen sein oder auch nicht.

Denken Sie über den Tellerrand hinaus, wenn Sie dies entscheiden. Ob Sie in Bezug auf Sicherheit gewinnen oder verlieren, hängt vom Rest Ihrer Umgebung und anderen Maßnahmen ab.

edit: Oh, habe gerade gesehen, dass es sich um einen Heimserver handelt. Ich war in der gleichen Situation, "Passwort" oder "USB-Stick mit Schlüssel drauf" immer bei mir? Ich habe mich für das erstere entschieden aber den SSH-Listening-Port auf etwas anderes als 22 geändert. Das verhindert, dass all diese lahmen Script-Kiddies ganze Netzwerkbereiche erzwingen.

25
Roman

Die Verwendung von SSH-Schlüsseln hat im Vergleich zur Kennwortanmeldung eine einzigartige Funktion: Sie können die zulässigen Befehle angeben. Dies kann durch Ändern der Datei ~/.ssh/authorized_keys Auf dem Server erfolgen.

Zum Beispiel,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

würde nur den Befehl "/usr/local/bin/your_backup_script.sh" mit diesem bestimmten Schlüssel zulassen.

Sie können auch die zulässigen Hosts für den Schlüssel angeben:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Oder kombinieren Sie beide:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Mit Schlüsseln können Sie einem Benutzer (z. B. einem Berater) auch temporären Zugriff auf einen Server gewähren, ohne das Kennwort für dieses bestimmte Konto preiszugeben. Nachdem der Berater seine Arbeit beendet hat, kann der temporäre Schlüssel entfernt werden.

75

Sie können das Beste aus beiden Welten herausholen, indem Sie die Kennwortauthentifizierung nur in Ihrem Netzwerk zulassen. Fügen Sie am Ende Ihres sshd_config Folgendes hinzu:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes
48
MikeyB

Sie haben teilweise auf Ihre Frage geantwortet: Je mehr Orte Angreifer angreifen können, desto mehr Möglichkeiten hat er, durch Bruteforcing in Ihren Server einzudringen (DDoS in Betracht ziehen).

Vergleichen Sie auch die Länge Ihres Passworts mit der Schlüsselgröße (normalerweise Tausende von Bits).

7
Martin Vejmelka

Wenn Sie sich mit einem Passwort anmelden, senden Sie Ihr Passwort an den Server. Dies bedeutet, dass der Betreiber des Servers die SSHD ändern kann, um Zugriff auf Ihr Kennwort zu erhalten. Bei der Authentifizierung mit öffentlichem Schlüssel können sie Ihren privaten Schlüssel nicht erhalten, da nur Ihr öffentlicher Schlüssel an den Server gesendet wird.

7
Ramon

sSH-Schlüssel verhindern Man-in-the-Middle-basierte Angriffe auf Ihr Passwort.

wenn Sie versuchen, sich mit einem Schlüssel anzumelden, erstellt der Server eine Herausforderung basierend auf Ihrem öffentlichen Schlüssel und sendet sie an Ihren Client. Dadurch wird es entschlüsselt und eine geeignete Antwort zum Senden erstellt.

Ihr privater Schlüssel wird niemals an den Server gesendet, und jeder, der zuhört, kann nur diese einzelne Sitzung abfangen.

mit einem Passwort hätten sie Ihre Anmeldeinformationen.

Meine Lösung besteht darin, einen tragbaren SSH-Schlüssel in geeigneten Formaten auf einer verschlüsselten Partition auf einem USB-Schlüssel zu haben. das erlaubt mir:
Ziehen Sie diesen Schlüssel leicht zurück, falls er verloren geht.
beschränken, auf welche Server ich zugreifen kann
Und immer noch herumtragen

die Installation der Mount-Software ist jedoch ein Problem (TrueCrypt).

6
Tacticus

Es ist ein Kompromiss, wie @MartinVejmelka sagt.

Der Grund, warum Sie die schlüsselbasierte Authentifizierung verwenden, ist, dass der Schlüssel so weit über dem aktuellen oder in naher Zukunft Brute Forcing liegt, dass Sie entweder von Ihrem eigenen PC kommen müssen oder den Schlüssel auf einem USB-Stick oder ähnlichem haben müssen .

Ein Passwort hat folgende Probleme:

  • Wenn es kurz ist, kann es brutal gezwungen werden
  • Wenn es lang ist, wird es leicht vergessen
  • Es könnte schultersurft sein

Ein Schlüssel ist um Größenordnungen länger und wird zu keinem Zeitpunkt angezeigt, sodass diese drei Probleme vermieden werden.

5
Rory Alsop

Ein potenzieller Vorteil von SSH gegenüber Kennwörtern besteht darin, dass Sie, wenn Sie keine SSH-Passphrase angeben, nie wieder ein Kennwort eingeben müssen. Ihr Computer ist auf dem Server von Grund auf vertrauenswürdig, da er über den Schlüssel verfügt. Trotzdem verwende ich normalerweise immer eine SSH-Passphrase, um diesen Vorteil auszuschließen.

Ich finde die beste Antwort dafür, warum Benutzerhandbücher SSH häufig über die Kennwortauthentifizierung empfehlen, aus dem Ubuntu-Handbuch für SSHOpenSSHKeys. Ich zitiere,

Wenn Sie es nicht für wichtig halten, protokollieren Sie alle böswilligen Anmeldeversuche, die Sie für die nächste Woche erhalten. Mein Computer - ein ganz normaler Desktop-PC - hatte allein in der letzten Woche über 4.000 Versuche, mein Passwort zu erraten, und fast 2.500 Einbruchsversuche. Wie viele tausend zufällige Vermutungen wird es Ihrer Meinung nach dauern, bis ein Angreifer über Ihr Passwort stolpert?

Wenn Sie ein solides Passwort mit hoher Länge, Interpunktion, Groß- und Kleinschreibung und Zahlen haben, ist die Passwortauthentifizierung wahrscheinlich in Ordnung. Auch wenn Sie vorhaben, Ihre Protokolle zu überwachen und sowieso keine "supersicheren" Aufgaben im Netzwerk ausführen ... d. H. Sie verwenden sie für einen Heimserver. Dann funktioniert ein Passwort auf jeden Fall gut.

2
MikeMurko

Gute Punkte, die hier bereits erwähnt wurden.

Was ich als das größte Risiko betrachte, ist, dass auf vielen Computern Keylogger installiert sind, ohne dass der Benutzer dies merkt, da Sie sich mit einem sicheren Kennwort um die Grundlagen gekümmert haben. Es gibt sogar Leute, die ganze Websites mit nützlichen Dienstprogrammen erstellen, die Trojaner enthalten, damit es den Besten von uns passieren kann. Ein Keylogger würde beispielsweise die Anmeldedaten per E-Mail an einen Hacker senden, der dann problemlos auf den Server zugreifen könnte.

Ich wurde kürzlich von Norton vor dem Herunterladen des Zombee Mod-Installationsprogramms (nicht des JAR, des Installationsprogramms) gewarnt, um dem Minecraft-JAR einen Flug hinzuzufügen. Ich habe mir die Details angesehen und Norton hat viele Dienstprogramme auf dieser Site aufgelistet, die als Trojaner enthaltend gekennzeichnet waren. Ich weiß nicht, ob dies korrekt ist oder nicht, aber es war ziemlich spezifisch mit Dateinamen. Es ist auch bekannt, dass Trojaner in (einige) Warez gelegt werden, bevor sie verteilt werden.

2
Tedd Hansen

Passwd Auth-Methode ist wirklich unsicher (imho). Mit diesem Mechanismus wird das Passwort an den sshd-Server übertragen (wie @ramon bereits gesagt hat). Dies bedeutet, dass einige Personen den SSHD-Server ändern können, um das Kennwort abzurufen. Mit einem Man-In-The-Middle-Angriff ist dies in einem lokalen Netzwerk sehr einfach zu bewerkstelligen.

Sie können den sshd-Server einfach patchen, indem Sie diesen Patch installieren ( https://github.com/jtesta/ssh-mitm ). Verwenden Sie arpspoof und iptables, um Ihren gepatchten Server zwischen dem Client und dem authentischen sshd-Server zu platzieren.

Bitte deaktivieren Sie die Passwortauthentifizierung: Öffnen Sie die Konfigurationsdatei /etc/ssh/ssh_config und füge die Zeile PasswordAuthentication no.

1
Pioz