Frage Halten Sie private SSH-Schlüssel sicher


Ich habe einen zentralen Server, auf dem ich alle privaten SSH-Schlüssel zu den verschiedenen Maschinen speicherte, die ich an SSH anschließen möchte. Derzeit haben nur Systemadministratoren Zugriff auf diesen "zentralen" Server.

Angesichts des obigen Szenarios möchte ich die folgenden Fragen stellen:

  1. Wie schützen Sie Ihre privaten SSH-Schlüssel? Ich habe über ssh-agent gelesen, aber ich bin mir nicht sicher, wie ich es benutzen soll oder ob es in dieser Situation verwendet werden kann.
  2. Wenn ein Systemadministrator das System verlässt und alle privaten SSH-Schlüssel kopiert, hat er Zugriff auf alle Server. Wie gehst du mit dieser Situation um?

6
2018-01-28 05:47


Ursprung




Antworten:


Private SSH-Schlüssel sollten den Computer, auf dem sie erstellt wurden, niemals verlassen, es sei denn, sie werden in eine sicherere Plattform, z. B. ein HSM, verschoben. Ebenso sollten sie für niemanden zugänglich sein außer für die Person, die sie erzeugt hat und sie verwenden wird, z. die Arbeitsstation eines Administrators oder besser eine HSM / Smartcard. Wenn Sie von mehreren Computern auf einen Server zugreifen, generieren Sie auf jedem Computer einen eindeutigen Schlüssel und stellen Sie die öffentlichen Schlüssel entsprechend bereit, oder fügen Sie einen öffentlichen Schlüssel von einer Smartcard oder einem anderen starken Authentifikator in die autorisierten Schlüssel ein.

Für den Anfang empfehle ich immer, private Schlüssel mit einer Passphrase zu schützen. Dies verringert die Gefahr einer unbefugten Schlüsselbenutzung, wenn sie in die falschen Hände gerät. Eine höhere Sicherheitsmaßnahme besteht darin, den privaten Schlüssel in eine Smartcard einzubetten und die kryptographischen Funktionen über eine Middleware zu nutzen. Redhat macht es einfach, all dies zu tun.

Wie schützen Sie Ihre privaten SSH-Schlüssel? Ich habe über ssh-agent gelesen, aber ich   Ich bin nicht sicher, wie man es benutzt oder ob es in dieser Situation verwendet werden kann.

ssh-agent wird in einer Terminalsitzung verwendet, um die unverschlüsselte Version des privaten Schlüssels zwischenzuspeichern, sodass Sie bei jeder Verwendung nicht die Passphrase des Schlüssels eingeben müssen. Sie können auch einen externen Authentifikator verwenden, mit dem Sie eine Authentifizierungsanfrage / -antwort verwenden, aber niemals auf den Klartext zugreifen können. Bitte werfen Sie einen Blick auf http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards um zu sehen, wie Sie ssh mit einem sicheren Authentifikator verwenden können.

Wenn ein Systemadministrator geht und alle privaten SSH-Schlüssel kopiert, dann er   hat Zugriff auf alle Server. Wie gehst du mit dieser Situation um?

Dies ist ein sehr starkes Argument, warum private Schlüssel sollten noch nie geteilt werden, und sicherlich, warum mehrere Benutzer Schlüssel sollten noch nie zusammen gespeichert werden. Klar und einfach, es gibt keinen Grund dafür. Niemand sonst hat etwas mit Ihrem privaten Schlüssel zu tun. Das heißt, selbst wenn Sie in einer Situation wären, in der jemand eine Menge aktiver privater Schlüssel in die Hände bekommen hat, wäre dies weitgehend kein Problem, wenn sie durch eine starke Passphrase passwortgeschützt wären.

Indem Sie Ihre Benutzer mit einem starken Authentifikator mit kryptografischen Funktionen authentifizieren, können Sie diese Situation vollständig vermeiden. Wenn ein Computer kryptografische Funktionen ausführen muss, anstatt einen privaten Schlüssel im Dateisystem zu speichern, können Sie ihn auf einem HSM speichern, um eine Exfiltration (Diebstahl) der privaten Schlüssel zu verhindern.

SSH-Schlüssel Private Schlüssel können eine Komponente eines Multi-Faktor-Authentifizierungssystems sein, z. B. eine Smartcard oder eine andere Art von Hardwaresicherheitsmodul (USB-Formfaktor, PCIe-Karte, Fortezza, vernetztes HSM usw.) bewusste Unternehmen, Regierungen und das Militär operieren einfach deshalb, weil ein Kompromiss zu einer massiven Exposition führen kann; Passwörter sind zu schwach.

Eine Chipkarte kann, abhängig von ihrer Sicherheit, entweder (A) nicht validiert sein, ein (B) FIPS 140-2 Level 2 Gerät, bis hin zu einem (C) kontrollierten kryptografischen Gerät, das für Top Secret SCI Informationen verwendbar ist Suite B-Algorithmen. Im Fall von (B) hat ein staatlich autorisiertes Labor die Kryptographie unabhängig validiert, und (C) hat die NSA das fragliche Gerät evaluiert. B gilt als die beste Sicherheit für den kommerziellen Bereich und C wird als militärisch / geheimdienstend eingestuft. Die Preise steigen für das robuste Zeug!


11
2018-01-28 06:09



Das Speichern eines privaten SSH-Schlüssels im Dateisystem ist eine falsche Sicherheitsvorkehrung. In Ihrem Kommentar ging es nicht einmal um die große Sicherheitslücke in der Frage des OP. - Brennan
@Brennan - Fühlen Sie sich frei, meine Antwort nach Ihren Wünschen zu bearbeiten. Ja, es gibt immer Wege und Mittel, um Dinge sicherer zu machen, aber wir müssen ein Gleichgewicht zwischen Sicherheit, Kosten und Benutzerfreundlichkeit finden. In 99% der Fälle ist das Speichern passwortverschlüsselter privater Schlüssel auf den fs völlig in Ordnung, insbesondere bei Einzelbenutzern. - EEAA
Das Problem ist die Idee der Schlüsselspeicherung auf dem Servernicht auf der Workstation des Administrators. Ich werde ein paar Updates machen :) - Brennan


Ich stimme ErikA zu. Es gibt jedoch Situationen, in denen Sie keine Passphrasen-geschützten privaten Schlüssel (z. B. für automatische Sicherung) möchten. In diesem Fall haben Sie und jeder Systemadministrator jeweils einen privaten Schlüssel.

Wenn Sie einen gemeinsamen privaten Schlüssel wünschen, können Sie den Zugriff über IP beschränken: Der zentrale Server ist der einzige Ort, von dem aus sich jemand mit anderen Computern verbinden kann.

Abhängig von der Wichtigkeit jeder Maschine können Sie für jede eine andere Lösung wählen.


1
2018-01-28 06:39



Wenn Sie bei automatisierten Aufgaben wie der Sicherung passphrasenlose Schlüssel verwenden, sollten Sie sicherstellen, dass diese Schlüssel in ihrem Gültigkeitsbereich auf den Servern begrenzt sind, für die sie sich anmelden. Lesen Sie den Abschnitt AUTHORIZED_KEYS FILE FORMAT der sshd man-Seite, um Informationen darüber zu erhalten, wie Sie einschränken können, was ein bestimmter Schlüssel auf einem Server tun kann. Im Fall von Backups sollten Sie sicherstellen, dass der Benutzer nur bestimmte Backup-Aufgaben ausführen kann (beispielsweise über sudo, wiederum mit eingeschränktem Zugriff), und Sie wahrscheinlich auch Dinge wie die Deaktivierung der Pty-Zuweisung tun möchten - Daniel Lawson