Bewährte Methode, um dasselbe SSH-Schlüsselpaar auf mehreren Computern zu verwenden?


12

Ich habe kürzlich einen neuen Laptop für die Arbeit bekommen und mich gefragt, ob es eine gute Übung wäre, weiterhin dasselbe RSA-Schlüsselpaar zu verwenden, das ich auf meinem alten Arbeitslaptop verwende. Ich möchte wirklich kein weiteres Schlüsselpaar erstellen müssen, um den Überblick zu behalten.

Ist dies im Allgemeinen eine akzeptable Praxis? Da das Schlüsselpaar eine Passphrase hat, sollte es ziemlich sicher sein, solange meine physischen Maschinen sicher sind, oder?


Antworten:


4

Ja, es ist sicher, solange es in sicheren Händen ist, dh physische Maschinen sind sicher. Wenn ein Angreifer Zugriff erhält und in der Lage ist, auf einen Computer zu sshen, kann er natürlich den Schlüssel von diesem Computer abrufen und ihn auch für andere Computer verwenden. Sehen Sie diese für weitere Informationen.


2
Nur der Computer, auf dem sich der private Schlüssel befindet, muss sicher sein.
Psusi

7

Um aus den anderen Antworten hier und an anderen Stellen etwas klarer zu werden: Die "Sicherheit" ist nur so sicher wie die Sicherheit des privaten Schlüssels. Wenn jemand Zugriff auf Ihre privaten Schlüssel hat, kann dieser möglicherweise per E-Mail versendet oder auf ein USB-Gerät kopiert werden. Dann könnte der kopierte private Schlüssel von einer anderen Person verwendet werden.

Solange sich der private Schlüssel in einem sicheren System befindet, kann er problemlos auf mehrere Computer übertragen werden.

Aber eine Sache , die ich sagen: Sie nicht kopieren einen privaten Schlüssel zu einem Remote - System. Versuchen Sie, sich auf den SSH-Agenten (ssh-agent oder pageant) und die Agentenweiterleitung zu verlassen. Wenn Sie einen privaten Schlüssel auf einem Remote-System haben, stellen Sie sicher, dass es sich nicht um denselben Schlüssel handelt, der für den Zugriff auf das System verwendet wird.


1

Ein einzelner Schlüssel auf mehreren Rechnern reduziert die Anzahl der Schlüssel, die ein Systemadministrator verarbeiten muss. Ich habe fünf Maschinen, auf denen ich arbeiten könnte (normalerweise ungefähr drei, die sehr aktiv sind, aber eine ist möglicherweise in Reparatur, eine andere in sehr gelegentlichem Gebrauch). Wenn eine Firma acht Leute wie ich hätte, wären 40 statt acht Schlüssel zu verwalten.

Das Problem, auf das Arcege - wenn auch indirekt - sehr klug hingewiesen hat, ist, dass wenn eine einzelne Maschine kompromittiert wird oder für einen kurzen Zeitraum sogar ausfällt, dies bedeuten würde, dass ich von keiner Maschine mehr Zugriff hätte (als mein Schlüssel für alle meine maschinen müssten runtergezogen werden). Es lohnt sich sicherlich, mehrere Schlüssel gleichzeitig zu verwalten, um einen einzigen Schlüssel von einem manipulierten oder gestohlenen Laptop zu entfernen und von einem anderen Computer aus weiterarbeiten zu können.

Stellen Sie sich in einem noch extremeren Beispiel vor, ich wäre der Sysadmin und hätte einen Laptop gestohlen oder gehackt. Mein Schlüssel muss entfernt werden, aber ich brauche Zugriff auf alle Systeme, um dies zu tun. Während es technisch möglich ist, innerhalb einer Sitzung zu ersetzen und zu entfernen, wird das Notfallszenario erheblich verkompliziert, wenn versucht wird, sich schnell zu bewegen und alle Basen abzudecken.

Wenn ich andererseits für jede Arbeitsstation eindeutige Schlüssel habe und eine alternative Arbeitsstation erreichen kann, kann ich den kompromittierten Schlüssel schnell und effizient ausschließen, ohne das Risiko einzugehen, mich selbst auszusperren.

Wenn ich mich eingehender mit dem Sicherheitsansatz von SSH-Schlüsseln befasse, ist klar, dass wir für echte Sicherheit alle beides verwenden sollten:

  • was wir haben (SSH-Schlüssel)
  • was wir wissen (Passwort für den Server)

Die Kennwortanforderung umfasst sowohl den Zugriff auf den Server als auch ein Kennwort für den Schlüssel. Der Ärger steigt, aber an dem Punkt, an dem wir alle drei eingerichtet haben (SSH-Schlüssel, SSH-Schlüsselzugriffspasswort, Serverpasswort), gibt es keinen einzigen Fehler mehr . Ein gemeinsam genutztes Serverkennwort schützt Ihr Team auch vor einem sehr schwachen SSH-Schlüsselkennwort (normalerweise haben wir keine Kontrolle über die von unseren Kollegen generierte Kennwortebene) und einem Kennwortadministrator in einer Unternehmenssituation, in der ich Zugriff auf Tools zur Kennwortprüfung habe Sogar die, die es besser wissen sollten, erstellen manchmal schockierend schwache Passwörter.

Ein Angreifer müsste bestimmt werden, und ein erfolgreicher Angriff kann Monate oder sogar Jahre dauern. Wenn Sie das Serverkennwort gelegentlich ändern (etwa alle sechs Monate, wenn das Serverkennwort mit einem System auf Unternehmensebene wie LastPass geteilt wird - denken Sie daran, dass es auch SSH-Schlüssel gibt), genießen Ihre Server an diesem Punkt eine angemessene Sicherheit (da niemand ein heißes SSH kombinieren kann) Schlüssel mit einem alten Passwort zum Einbruch).

Man muss sich den illegalen Zugang von Insidern (Edward Snowden, Ashley Madison als zweiter) als primäres Risiko vorstellen. Nur durch die Verwendung von Schlüsseln und Passwörtern kann ein Insider wirklich gebremst werden.

Anders als bei der alten chinesischen Methode: Begrabe sie lebendig, wenn ihre Arbeit beendet ist.

Nach dem Begräbnis wurde vermutet, dass es ein schwerwiegender Verstoß wäre, wenn die Handwerker, die die mechanischen Geräte bauten und von ihren Schätzen wussten, diese Geheimnisse preisgeben würden. Nachdem die Trauerzeremonien beendet waren und die Schätze versteckt waren, wurde der innere Durchgang blockiert und das äußere Tor abgesenkt, wodurch alle Arbeiter und Handwerker sofort in der Kammer gefangen waren. Keiner konnte entkommen.


0

Für Benutzerschlüssel - Ja, wenn Sie eine sichere Passphrase verwenden und den Schlüssel auf einem System ohne SSH-Sicherheitslücken erstellt haben.

Für Server-Schlüssel: nein.


0

Ich würde sagen, es ist eine gute Angewohnheit, verschiedene Schlüssel für verschiedene Gruppen zu haben, zum Beispiel: Arbeit, Zuhause, open_source_project.

Je mehr Schlüssel Sie hinzufügen, desto komplexer ist die Verwaltung.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.