Warum ist die SSH-Kennwortauthentifizierung ein Sicherheitsrisiko?

In den meisten Handbüchern für die OpenSSH-Konfiguration wird empfohlen, die Kennwortauthentifizierung zugunsten der schlüsselbasierten Authentifizierung zu deaktivieren. Meiner Meinung nach hat die Kennwortauthentifizierung jedoch einen erheblichen Vorteil: Sie kann von jedem Ort aus eine Verbindung ohne Schlüssel herstellen. Wenn dies immer mit einem starken Passwort verwendet wird, sollte dies kein Sicherheitsrisiko darstellen. Oder sollte es?

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

In einigen Fällen ist beispielsweise die schlüsselbasierte Authentifizierung weniger sicher als die Kennwortauthentifizierung. In anderen Fällen ist die pw-basierte Lösung weniger sicher. In einigen Fällen ist einer bequemer, in anderen weniger.

Alles läuft darauf hinaus: Wenn Sie eine schlüsselbasierte Authentifizierung durchführen, müssen Sie Ihren Schlüssel mit einer Passphrase sichern. Sofern Sie nicht ssh-agent ausgeführt haben (ssh-agent befreit Sie von jeder Eingabe Ihrer Passphrase), haben Sie an Komfort nichts gewonnen. Sicherheit ist umstritten: Der Angriffsvektor wurde jetzt vom Server auf SIE oder Ihr Konto oder Ihren persönlichen Computer verlagert (...) - diese können leichter zu brechen sein oder auch nicht.

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

edit: Oh, habe gerade gesehen, dass du von einem Heimserver sprichst. Ich war in der gleichen Situation, "Passwort" oder "USB-Stick mit Schlüssel drauf" immer bei mir? Ich habe mich für den ersten entschieden, aber den SSH-Abhörport auf einen anderen Port als 22 geändert. Das hindert all diese lahmen Skript-Kiddies daran, ganze Netzwerkbereiche zu erzwingen.

Die Verwendung von SSH-Schlüsseln bietet im Vergleich zur Kennwortanmeldung eine einzigartige Funktion: Sie können die zulässigen Befehle angeben. Dies kann durch Ändern der ~/.ssh/authorized_keysDatei 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 erlauben.

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

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

Oder kombinieren Sie die beiden:

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

Mit Schlüsseln können Sie auch einem bestimmten Benutzer (z. B. einem Berater) 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 abgezogen werden.

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

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

Sie haben Ihre Frage teilweise beantwortet. Je mehr Orte ein Angreifer erreichen kann, desto mehr Möglichkeiten hat er, durch Bruteforcing in Ihren Server einzudringen (siehe DDoS).

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

Wenn Sie sich mit einem Passwort anmelden, übermitteln Sie Ihr Passwort an den Server. Dies bedeutet, dass der Bediener des Servers die SSHD ändern kann, um Zugriff auf Ihr Kennwort zu erhalten. Bei der Authentifizierung mit öffentlichem Schlüssel kann Ihr privater Schlüssel nicht abgerufen werden, da nur Ihr öffentlicher Schlüssel an den Server gesendet wird.

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

Wenn Sie versuchen, sich mit einem Schlüssel anzumelden, erstellt der Server eine auf Ihrem öffentlichen Schlüssel basierende Abfrage und sendet sie an Ihren Client. die es entschlüsseln und eine entsprechende Antwort zu senden konstruieren.

Ihr privater Schlüssel wird nie an den Server gesendet, und jeder, der mithört, kann nur diese eine Sitzung abfangen.

mit einem Passwort würden sie Ihre Anmeldeinformationen haben.

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 ermöglicht mir: den
schlüssel einfach zurückzuziehen, falls er verloren geht.
Beschränken Sie, auf welche Server ich zugreifen darf,
und tragen Sie sie trotzdem mit sich herum

Die Installation der Mount-Software ist jedoch ein Problem (truecrypt).

Es ist ein Kompromiss, wie @MartinVejmelka sagt.

Der Grund für die Verwendung der schlüsselbasierten Authentifizierung ist, dass der Schlüssel so weit über dem aktuellen oder in naher Zukunft vorherrschenden Wert liegt, dass Sie entweder von Ihrem eigenen PC kommen 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 schultergesurft sein

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

Gute Punkte, die hier bereits erwähnt wurden.

Was ich für das größte Risiko halte, 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 Hilfsprogrammen erstellen, die Trojaner enthalten, damit es den Besten von uns passieren kann. Ein Keylogger sendet beispielsweise die Anmeldedaten per E-Mail an einen Hacker, der dann problemlos auf den Server zugreifen kann.

Ich wurde kürzlich von Norton davor gewarnt, das Zombee Mod-Installationsprogramm (nicht das Glas, das Installationsprogramm) herunterzuladen, um dem Minecraft-Glas einen Flug hinzuzufügen. Ich habe mir die Details angesehen und Norton hat eine Reihe von Hilfsprogrammen auf dieser Site aufgelistet, die als Trojaner gekennzeichnet waren. Ich weiß nicht, ob das richtig ist oder nicht, aber es war ziemlich spezifisch für Dateinamen. Es ist auch bekannt, dass Trojaner in (einige) Warez gesteckt werden, bevor sie verteilt werden.

Ein möglicher Vorteil von SSH gegenüber Passwörtern besteht darin, dass Sie, wenn Sie keine SSH-Passphrase angeben, nie wieder ein Passwort eingeben müssen. Ihr Computer ist auf dem Server an sich vertrauenswürdig, da er über den Schlüssel verfügt. Das heißt, ich verwende normalerweise immer eine SSH-Passphrase, damit ich diesen Vorteil ausschließe.

Ich finde die beste Antwort, warum Benutzerhandbücher SSH häufig als Alternative zur Kennwortauthentifizierung empfehlen, im 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?

Im Wesentlichen, wenn Sie ein solides, langes Passwort mit Interpunktion, Groß- und Kleinschreibung und Zahlen haben ... werden Sie wahrscheinlich mit der Passwortauthentifizierung einverstanden sein. Auch wenn Sie vorhaben, Ihre Protokolle zu überwachen und sowieso keine "supersicheren" Vorgänge im Netzwerk ausführen, z. B. für einen Heimserver. Dann funktioniert auf jeden Fall ein Passwort gut.

Die Passwd-Authentifizierungsmethode 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 durchzuführen.

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

Bitte deaktivieren Sie die Passwortauthentifizierung: Öffnen Sie die Konfigurationsdatei /etc/ssh/ssh_configund fügen Sie die Zeile hinzu PasswordAuthentication no.

Sie können das mit der -o StrictHostKeyChecking=noOption umgehen . Dies ist sehr nützlich, wenn Sie ssh in einem Shell-Skript verwenden.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost