Die schlüsselbasierte Anmeldung wird aus der Perspektive eines Brute-Force-Versuchs, Zugriff von einem Drittanbieter-System zu erhalten, als viel sicherer angesehen als kennwortbasierte Anmeldungen: Die Wahrscheinlichkeit, einen Schlüssel zu knacken, ist praktisch Null, während alle falschen Kennwörter vorhanden sind allzu häufig.

Aus der Sicht eines kompromittierten Client-Systems (Ihrer Workstation) gibt es keinen Unterschied, denn wenn die Angreifer Ihren privaten Schlüssel erhalten und / oder eine Sitzung entführen können, können sie wahrscheinlich auch eine Art installieren von Key Logger, wodurch der wahrgenommene Vorteil von Passwörtern unbrauchbar wird.

Es ist so sicher wie Ihr Computer. Der Schlüssel befindet sich unverschlüsselt im RAM. Ein Angreifer mit physischem Zugriff auf Ihren Computer oder Remote-Root-Zugriff könnte ihn erhalten.

Stellen Sie sich das so vor, als hätten Ihre Mitarbeiter ein kennwortsicheres Programm verwendet und es mit dem auf dem Bildschirm belassen Datenbank ohne Passworteingabe verfügbar; Wenn Sie Ihre Workstation sperren, wenn Sie weggehen, und sie vor feindlichen Remote-Aktivitäten schützen, ist sie einigermaßen sicher, aber ein eingefrorener RAM-Angriff könnte theoretisch immer noch den Schlüssel erhalten.

Aber jemand in diesen Positionen könnte leicht installiert werden ein Keylogger auch, wie Sie betonten. Solange Sie auf die Sicherheit Ihrer Workstation achten, würde ich sie nicht als weniger sicher als Passwörter bezeichnen. Die eigentlichen Vorteile von schlüsselbasierten Anmeldungen liegen jedoch im Schutz vor beispielsweise Brute-Force-Kennwortangriffen auf den Server (da Schlüssel kaum brutal zu erzwingen sind).

Eigentlich sind Ihre Mitarbeiter korrekt. Denken Sie darüber nach. Ihre Arbeitsstationen sind kaputt, es ist schon ein paar Tage her und jetzt pwn die Hacker Ihr gesamtes Netzwerk, weil Sie keine ssh-Passphrase verwenden.

Allerdings sind gemeinsam genutzte Passwörter niemals gut und eine große Schwäche des Systems. Ich gehe davon aus, dass Sie über Root-Zugriff sprechen.

Der Punkt, den ich anspreche, ist, dass beide Nachteile haben und wo die Sicherheit sein muss.

Für alle Server, die ich verwalte, verwende ich einen Passphrasen-SSH-Schlüssel. Das gibt mir das Beste aus beiden Welten. Ein Passwort, das nur ich kenne und das kein gemeinsames Passwort für andere Benutzer verwendet.

(und ja, ich habe gesehen, wo ein passphraseless ssh-Schlüssel verwendet wurde, um das gesamte Netzwerk zu gefährden.

Sie sind nur so sicher wie Ihr schwächstes Glied. Wenn Ihre Remoteserver sowohl eine kennwort- als auch eine schlüsselbasierte Authentifizierung zulassen, sind Sie weniger sicher als nur eine.

Ihre zusätzlichen Schwachstellen für ein schlüsselbasiertes System über die Kennwortauthentifizierung (PA) sind:

1. Ein Angreifer erhält eine Kopie Ihres passphrasengeschützten privaten Schlüssels, indem er beispielsweise physischen Zugriff auf eine unverschlüsselte Festplatte auf einem beliebigen System hat (z. B. im Einzelbenutzermodus booten), und führt dann eine GPU-basierte aus Offline-Brute-Force-Angriff auf Ihren Schlüssel und Zugriff auf alle Ihre Systeme, wenn Ihre Passphrase entsprechend schwach ist (z. B. 4 Diceware-Wörter).

2. Sie verwenden so etwas wie ssh-agent, das Ihre Passphrase oder Ihren privaten Schlüssel für die spätere Verwendung im Speicher hält, und ein Angreifer kann ihn irgendwie von Ihrem System entfernen (z. B. einen anderen Root) Benutzer war angemeldet, während Sie das Passwort im Speicher hatten).

3. Ihr Schlüssel war viel weniger sicher als Sie dachten. Zum Beispiel die OpenSSH-Schlüsselschwäche; Die einzige Zufälligkeit kam von der Prozess-ID, sodass nur 65536 Schlüssel generiert wurden. Während diese Art von Problemen hoffentlich schnell bemerkt und behoben werden, ist es für Endbenutzer unmöglich zu sagen, dass es keine gibt Hauptfehler im Zufallszahlengenerator, mit dem Ihre Schlüssel erstellt wurden.

ol>

Ihre zusätzliche Sicherheit bei der Verwendung der schlüsselbasierten Authentifizierung:

1. Brute Force-Angriffe sind über das Leben des Universums nicht möglich, ohne Ihren privaten Schlüssel zu stehlen (und wenn er durch eine Passphrase geschützt war; dann die Passphrase zu brechen).
2. MITM-Angriffe funktionieren nicht (ein böswilliger Remote-Host kann ' t Ihren privaten Schlüssel / Ihre Passphrase herausfinden); ssh warnt jedoch bereits vor MITM-Angriffen, um Administratoren mithilfe von Hostschlüsseln und bekannten_Hosts -Dateien zu warnen.
ol>

In der Praxis sind beide gleichermaßen sicher. Jeder, der SSH-Privatschlüssel aus dem RAM stehlen kann, kann einen Keylogger installieren, um Ihre Passwörter / Passphrasen / Privatschlüssel zu erhalten.

Ich persönlich mag Ihre Lösung, da eine Passphrase bequemer ist (im RAM gespeichert; auf einem Einbenutzer-Computer, der nach 5 Minuten gesperrt wird). obwohl ich meinen passphrasengeschützten privaten Schlüssel immer noch nur auf lokalen Computern ablege, auf denen ich der einzige Benutzer bin.

Ein Grund, von dem ich glaube, dass die schlüsselbasierte Authentifizierung einen leichten Sicherheitsvorteil hat, ist, dass ich manchmal beide Endbenutzer gesehen habe und gelegentlich sogar mein Passwort in ein Feld für den Benutzernamen anstatt in das Passwort eingegeben habe Dialogfeld (abhängig vom SSH-Client). Oder drücken Sie zu schnell die Eingabetaste, und der SSH-Client wurde beendet, und mein Kennwort wurde in meinen Terminalverlauf aufgenommen.

Wenn Sie bei jeder Eingabe Ihres Kennworts nicht vorsichtig sind, besteht die Möglichkeit, dass Ihr Kennwort hinzugefügt wird im Klartext möglicherweise zu mehreren Protokolldateien, möglicherweise zur Shell-Historie oder sogar zu einer Art Trojaner. Im Fall eines kennwortlosen Schlüssels oder eines Schlüssels, den Sie zu Beginn Ihrer Sitzung mit einem SSH-Agenten laden, sollten Sie Ihr Kennwort niemals erneut eingeben, sodass es unwahrscheinlich ist, dass Sie Ihre Anmeldeinformationen an einer falschen Stelle eingeben und Ihre offenlegen Passwort für jemanden oder etwas, das Sie nicht beabsichtigt haben.

In gewisser Weise sind es 6er. Das erste unmittelbare Sicherheitsrisiko einer kennwortbasierten Anmeldung wäre ein nicht autorisierter Benutzer, der (auf welche Weise auch immer) das Kennwort für den Server erhält. Ebenso besteht bei einer schlüsselbasierten Anmeldung das Sicherheitsrisiko, dass nicht autorisierte Benutzer Zugriff auf Ihren Computer erhalten. Wenn Sie ein komplexes Passwort auf dem Server verwenden, besteht die Gefahr, dass die Passwortbenutzer es irgendwo aufschreiben müssen, um sich daran zu erinnern. Bei den Hauptbenutzern besteht die Gefahr, dass sie bei entsperrtem Computer von ihrem Schreibtisch weggehen.

Vieles hängt vom Verhältnis von Risiko zu Benutzerfreundlichkeit ab. Natürlich könnten Sie Passwörter für die Schlüssel benötigen, nur bestimmte IP-Adressen pro Schlüssel und eine andere Anzahl von Sicherheitsmaßnahmen zulassen, aber das macht Ihre Leute unglücklich.

Aber um zu antworten Ihre Frage: Wenn es sich um eine Vanilla-Konfiguration von OpenSSH handelt, haben kennwortbasierte und schlüsselbasierte Anmeldungen ihre eigenen, unterschiedlichen Sicherheitslücken.

Ich deaktiviere die Kennwortanmeldung über ssh für root auf meinen Systemen immer. Auf diese Weise kann ein Angreifer nicht versuchen, das Kennwort brutal zu erzwingen.

Sie sollten dennoch auf der Sicherheit der Client-Systeme vorsichtig sein. Möglicherweise möchten Sie den SSH-Agenten dazu bringen, Ihre Schlüsselanmeldeinformationen zu vergessen, wenn der Sperrbildschirm angezeigt wird. Dies würde verhindern, dass Angriffe auf Ihren Client-Computer Ihren Schlüssel gefährden.

Einige anständige Antworten hier, aber alle scheinen meiner Ansicht nach die Marke zu verfehlen.

Die Verwendung eines Schlüsselpaars zur Authentifizierung ersetzt das "etwas, das Sie wissen" eines passwortbasierten Systems durch ein "etwas" Sie haben "eines Schlüssel- oder Tokensystems. Zurück in einer Sekunde.

Schlüssel sind weitaus komplexer. Ich denke, die meisten SSH-Implementierungen verwenden standardmäßig den RSA-Schlüssel 2048. Vergleichen Sie das mit einem 8-stelligen Passwort. Selbst wenn sie in 256 Bit gehasht werden, können Passwörter, da ihnen die Zufälligkeit der Schlüssel fehlt, brutal erzwungen werden. Schneier hat einige großartige Beobachtungen dazu; Selbst angeblich "gute" Passwörter sind in der Regel nur eine Kombination aus knackbaren Daten (ein Wort mit einer Zahl und möglicherweise einigen einfachen Ersetzungen). Wir Menschen sind einfach zu vorhersehbar.

Da ein Schlüssel nur so sicher ist wie das Passwort für die Anmeldung, ist dies nicht ganz richtig. Indem Sie einen Schlüssel mit einem anderen Kennwort versehen, erhöhen Sie die Sicherheit erheblich, da Sie im Wesentlichen die Zwei-Faktor-Authentifizierung verwenden. Um auf etwas zuzugreifen, das Sie haben (den Schlüssel), müssen Sie etwas verwenden, das Sie kennen (ein Passwort). Ja, die Verwendung Ihres Anmeldekennworts zum Umschließen eines Schlüssels würde dies untergraben.

Zum Originalposter würde ich also sagen, dass Sie und Ihre Mitarbeiter falsch liegen. Sie sind vielleicht weniger als sie, aber die richtige Antwort ist, dass Sie sowohl einen Schlüssel als auch ein Passwort verwenden sollten.