Frage Warum sollte ich die Public-Key-Authentifizierung für SSH verwenden?


Ich betreibe einen SSH-Server und verwende weiterhin eine einfache Passwort-Authentifizierung. Überall, wo ich über Sicherheit lese, wird empfohlen, die Public-Key-Authentifizierung zu verwenden. Aber ich bekomme die Vorteile nicht. Sie zu benutzen ist in meinen Augen entweder unsicher oder handlich.

Natürlich, wenn jemand versucht, die Anmeldung auf meinem SSH-Server Brute-Force ist Public-Key viel stärker als jedes Passwort. Aber abgesehen davon ist es völlig unsicher.

Die Berater argumentieren meistens, dass Sie sich kein Passwort merken müssen. Wie unsicher ist das? Wenn also jemand in meinen Computer eindringt, bekommt er nicht nur meinen Computer, sondern auch meinen Server? Wenn ich SSH von verschiedenen Clients verwende, muss ich die Public Keys einzeln speichern, was die Wahrscheinlichkeit erhöht, dass sie in falsche Hände geraten. Ich könnte sie auf einem USB-Stick speichern, den ich bei mir trage, aber es kann verloren gehen und der Finder hat Zugriff auf meinen Server.

Möglicherweise bin ich besser mit Zwei-Faktor-Authentifizierung bedient.

Gibt es Argumente, die ich vermisse? Was ist der beste Weg für mich?


26
2018-02-19 12:21


Ursprung


Wenn richtig gemacht, Authentifizierung mit öffentlichem Schlüssel ist eine Form von 2FA mit etwas, das du kennst (die Passphrase zum privaten Schlüssel) und etwas, das du hast (der private Schlüssel). - Sven♦
@EEEAA Warum ist es so wichtig wie? Ihre privater Schlüssel hat einen? - immibis
Wenn ich Sie mit einem privaten Schlüssel dazu verleite, versehentlich eine Verbindung zum falschen Server herzustellen, geben Sie Ihr Kennwort nicht in meinen Server ein. - immibis
Viele Organisationen müssen (aus welchen Gründen auch immer) verlangen, dass Zwei-Faktor-Authentifizierung verwendet wird. Das ist unmöglich, wenn man sich auf verschlüsselte private Schlüssel verlässt. - EEAA
Für das, was es wert ist, stimme ich mit Sven tief über die Einstufung des privaten Schlüssels als etwas, was du hast. Es versagt den grundlegenden Test von a etwas, was du hastweil es beliebig reproduzierbar ist und einfach digitale Daten sind. Public-Key-Authentifizierung für sich ist nicht 2FA; Wenn du dir sagst, dass es so ist, täuschst du dich selbst wegen deiner Sicherheit. - MadHatter


Antworten:


Wenn jemand in meinen Computer eindringt, bekommt er nicht nur meinen Computer, sondern auch meinen Server?

Das ist bei Keyloggern sowieso möglich: Sobald Sie sich vom kompromittierten Computer aus bei Ihrem Server anmelden, erhalten sie das Passwort.

Aber es gibt 3 Vorteile für Schlüssel:

1) Cache-fähige Authentifizierung. Geben Sie Ihre Passphrase einmal ein, führen Sie mehrere SSH-Befehle aus. Dies ist sehr nützlich, wenn Sie etwas verwenden, das ssh als Transport verwendet, wie scp, rsync oder git.

2) Skalierbare Authentifizierung. Geben Sie Ihre Passphrase einmal ein, Loggen Sie sich in mehrere Maschinen ein. Je mehr Maschinen Sie haben, desto nützlicher ist das. Wenn du 100 Maschinen hast, was machst du? Sie können nicht dasselbe Kennwort verwenden (es sei denn, es handelt sich um eine Clone-Farm), und Sie können sich nicht an so viele erinnern. Sie müssen also einen Passwort-Manager verwenden, und Sie sind zurück zu einem einzigen Punkt der Kompromittierung. Effektiv die Schlüsselpassphrase ist Dein Passwortmanager.

2b) Anders skaliert, wenn mehrere Administratoren die gleichen Systeme verwenden, da Sie Schlüssel von Benutzer A entziehen können, ohne dass B, C, D, E, F ... mitgeteilt werden muss, dass sich das Passwort geändert hat.

(Dies kann auch mit einzelnen Konten und sudo gemacht werden, aber dann müssen Sie diese Konten irgendwie bereitstellen)

3) Automatisierung und teilweise Delegation. Sie können SSH auf einrichten Führen Sie einen bestimmten Befehl aus, wenn ein Schlüssel eine Verbindung herstellt. Dies ermöglicht einem automatisierten Prozess auf System A, etwas auf System B zu tun, ohne zwischen den beiden uneingeschränkt passwortlos zu vertrauen.

(Es ist ein Ersatz für Rlogin / Rsh, die urkomisch unsicher war)

Bearbeiten: Ein weiterer Vorteil öffentlicher Schlüssel anstelle von Kennwörtern ist das häufige Szenario, in dem der Server durch eine Sicherheitsanfälligkeit kompromittiert wird. In diesem Fall beeinträchtigt die Anmeldung mit einem Passwort das Passwort sofort. Anmeldung mit einem Schlüssel nicht! Ich würde sagen, dass dies häufiger vorkommt, als dass der Desktop des Administrators kompromittiert wird.


32
2018-02-19 21:43



2b ist sehr wichtig. autorisierte Schlüssel können einfach zentral verwaltet werden, das Ändern eines Kennworts und das Verteilen an alle Benutzer erfordert mehr Arbeit. - Jonas Schäfer
Welche Techniken zur zentralen Verwaltung von autorisierten Schlüsseln gibt es? (Ich kenne authorized_keys-Dateien auf einem freigegebenen Dateisystem, aber es muss andere geben) - pjc50
An dem Punkt, an dem Sie mehrere zehn oder Hunderte von Servern haben, verwenden Sie wahrscheinlich Chef, Ansible, Puppet, Holo oder etwas ähnliches, das diese verwaltet. Oder Sie haben die autorisierten Schlüssel in einer LDAP- oder anderen Datenbank. - Jonas Schäfer
Vergessen Sie nicht Agentenweiterleitung: Sie können sich mit anmelden ssh -Aund von dort loggen Sie sich in Maschinen ein, die die Öffentlichkeit Ihres Ursprungshosts erlauben. - Halfgaar
@Halfgaar ... ohne speziell etwas auf dem Host zu ändern, von dem aus du dich verbindest. Ich habe gerade dieses Feature gelernt, und ich liebe es! - Canadian Luke


Wenn Sie gute Passwörter verwenden, kann dies sicher genug sein. Normalerweise beschränke ich die Anzahl der öffentlich zugänglichen Server auf das Minimum und erlaube SSH von bestimmten IP (s) wann immer möglich.

Sie können Ihre Schlüssel auch mit einer Passphrase (Passwort) schützen. Daher muss diese Passphrase immer dann eingegeben werden, wenn Sie sich bei Ihrem Server anmelden müssen. Niemand kann dann Ihren Schlüssel verwenden, wenn nicht die richtige Passphrase angegeben ist.

Es gibt ähnliche Beiträge:

  1. Beitrag von Serverfehler.
  2. Beitrag von Sicherheitsstapelexchange.
  3. Beitrag von Superuser.

12
2018-02-19 12:47



Schlüsselwort ist ein Muss IMHO. Wenn Sie ssh-agent verwenden, werfen Sie einen Blick auf die Option -t von ssh-add, um die Schlüssel nach einer bestimmten Zeit zu entladen. - fuero


Eine Art, bei der die Autorisierung mit öffentlichen Schlüsseln sicherer ist, besteht darin, dass der Angreifer zwischen Ihrem Clientcomputer und dem Server als Man-in-the-Middle (MitM) fungiert und Sie den sich ändernden Hostschlüssel nicht bemerken (möglicherweise weil Sie dies nicht getan haben) habe den alten Schlüssel nicht, z. B. weil dieser Client zum ersten Mal verwendet wird.

(Das gleiche gilt, wenn der Angreifer die Kontrolle über den Server übernimmt und es auf anderen Servern die gleichen Anmeldeinformationen gibt.)

Bei der standardmäßigen kennwortbasierten Authentifizierung senden Sie Ihr Kennwort (innerhalb der verschlüsselten Verbindung) im Nur-Text-Format. Der echte Server wird das Kennwort normalerweise prüfen und das Ergebnis mit einem in der Kennwortdatenbank gespeicherten Hashwert vergleichen. Ein MitM-Angreifer könnte stattdessen dieses Passwort nehmen, eine Verbindung zum echten Server herstellen und sich dort anmelden ... und entweder den Inhalt an Sie weiterleiten (damit Sie nichts bemerken) oder einfach nur seine eigenen bösen Dinge auf Ihrem Server erledigen .

Bei der Public-Key-Authentifizierung signiert der Client grundsätzlich einige Daten, die sowohl vom Server als auch vom Client bekannt sind, um zu beweisen, dass er im Besitz des privaten Schlüssels ist, und sendet die Signatur an den Server. Diese signierten Daten enthalten einen Sitzungsidentifizierer, der von Zufallszahlen abhängt, die sowohl vom Client als auch vom Server ausgewählt werden und daher für jede Sitzung unterschiedlich sind. Wenn der MitM eine eigene SSH-Verbindung zu dem realen Server öffnet, hat dieser eine andere Sitzungs-ID, und daher wird die vom Client bereitgestellte Signatur dort nicht funktionieren.

Wie andere Antworten bereits gesagt haben, müssen Sie natürlich Ihren privaten Schlüssel, z.B. verschlüsselt mit einer Passphrase oder auf einem separaten Gerät möglich, das erst nach Eingabe einer PIN Signaturen erstellt.


12
2018-02-19 20:01





OpenSSH kann seine eigene CA für die Verwaltung von SSH-Host- und Client-Schlüsseln behalten und Sperrlisten für sie verwenden. Dies könnte die Sicherheit der schlüsselbasierten Authentifizierung erhöhen.


2
2018-02-19 14:03





Sie haben recht mit der Behauptung "Sie brauchen kein Passwort". Das ist auf der Clientseite wirklich unsicher.

Was macht erlaubt nur Öffentliche Schlüssel für die Anmeldung viel sicherer ist die Tatsache, dass es keine Möglichkeit gibt, Brute-Force-Zugriff auf Ihren Server. Alles, was ein Angreifer erreichen kann, ist es, Ihren Server etwas zu belasten - Sie können ihn einsetzen fail2ban das in Schach zu halten.

Zur Sicherheit auf der Client-Seite müssen Sie den privaten Schlüssel mit einer guten Passphrase schützen. Natürlich ist die Verbindung zum Server nun mühsamer als mit einem Passwort. Um dies zu überwinden, können Sie Gebrauch machen SSH-Agent um den privaten Schlüssel im Speicher zu speichern, wenn Sie mehrmals hintereinander eine Verbindung zum Server herstellen möchten. Es empfiehlt sich, die Zeit für die Speicherung eines Schlüssels zu begrenzen.


2
2018-02-19 16:41



keine Möglichkeit, Brute-Force-Zugriff ... ich würde nicht nein sagen ... Sie können den privaten Schlüssel auf die gleiche Weise wie das Passwort bruteforce, aber Sie haben viel mehr der Entropie im privaten Schlüssel als im allgemeinen Passwort, was es ziemlich nutzlos macht (bisher ohne Quantencomputer). - Jakuje


Möglicherweise bin ich besser mit Zwei-Faktor-Authentifizierung bedient.

Eine Möglichkeit für 2FA für SSH (und eine, die relativ wenig Setup / Komplexität erfordert) verwendet tatsächlich einen öffentlichen Schlüssel und ein Passwort.

Ich glaube etwas in der Art von AuthenticationMethods publickey,keyboard-interactive kann hinzugefügt werden /etc/ssh/sshd_config um diese Arbeit zu machen.

Allgemeiner ist das Problem mehr, dass Passwörter (alleine) keine gute Methode zur Authentifizierung sind, weil sie oft von zweifelhafter Qualität sind. Ein sehr einfaches "Argument" für Schlüssel gegen Kennwörter ist, dass ein Schlüssel im Allgemeinen mindestens 2048 Bit und oft mehr (für EC-Schlüssel ist dies die effektive Stärke und nicht die tatsächliche Größe) sein wird. Diese Bits werden auch durch einen kryptologisch sicheren (oder geeigneten) Mechanismus erzeugt.

Ein Passwort ist oft weniger als 2048 Bit und wird oft nicht von einer kryptographisch sicheren Quelle abgeleitet.

Sie können Ihre Schlüssel auch mit einem Passwort sichern, um sich vor Problemen zu schützen, die mit dem Verlust der Schlüssel zusammenhängen (obwohl jemand versuchen könnte, dieses Passwort brutal zu erzwingen).

Im Grunde genommen können die Unterschiede zwischen Schlüsseln und Passwörtern ziemlich transparent gemacht werden, und mit Schlüsseln erwerben Sie ein besseres Passwort, als ein Mensch verarbeiten könnte. Das soll nicht heißen, dass sie ein Allheilmittel sind, aber im Durchschnitt bieten sie mehr Sicherheit als Passwörter.


0
2018-03-13 10:47