Generieren von SSH- und GnuPG-Schlüsseln auf einem Remote-Server. Bewährte Methoden zur Schlüsselverwaltung

Generieren von SSH- und GnuPG-Schlüsseln auf einem Remote-Server. Bewährte Methoden zur Schlüsselverwaltung

Ich frage nach Best Practices im Zusammenhang mit der Schlüsselgenerierung, -verwendung und -verwaltung.

In einigen Fällen und aus verschiedenen Gründen habe ich SSH- und GnuPG-Schlüssel erstellt, während ich über SSH bei einem Remote-Multiuser-Server bei der Arbeit (und von zu Hause aus bei meinem Desktop-Computer bei der Arbeit) angemeldet war.

Als ich die Passphrasen für meine neu generierten Schlüssel eingab, fiel mir auf, dass ich keine Kontrolle über die Maschine habe, an der ich angemeldet bin, oder über die Verbindung dazwischen. Ich vertraue den Systemadministratoren bei der Arbeit irgendwie und SSH ist sicher, aber trotzdem ... es fühlte sich komisch an, meine neuen Passphrasen so über die Verbindung zu senden.

Was meint ihr? Ist es klüger, die Schlüssel (SSH, GnuPG oder andere) lokal zu generieren und dann die privaten Schlüssel über SSH zu übertragen, oder bin ich bei der ganzen Sache einfach nur paranoid?

Und wenn ich mit meiner leichten Paranoia recht habe, was denken Sie über den Aufbewahrungsort privater Schlüssel? Sollten sie alle an einem physischen Ort sein? Sollte ich „ gpg-agentund ssh-agentimmer“ häufig verwenden?

Ich arbeite von zwei verschiedenen Rechnern aus und melde mich per SSH bei mehreren verschiedenen Multi-User-Servern an. Ich signiere Git-Commits mit GnuPG von ungefähr vier Standorten aus (lokal und remote).

Ich arbeite an einer Mischung aus Mac OS X- (mit MacPorts) und Linux-Rechnern (mit Pkgsrc), aber immer auf der Befehlszeile.

Antwort1

Was meint ihr? Ist es klüger, die Schlüssel (SSH, GnuPG oder andere) lokal zu generieren und dann die privaten Schlüssel über SSH zu übertragen, oder bin ich bei der ganzen Sache einfach nur paranoid?

Dies macht keinen wirklichen Unterschied, zumindest nicht, wenn die Systemadministratoren den Software-Stack nicht manipuliert haben (aber warum sollten sie, wenn sie sowieso in die Hände der privaten Schlüssel gelangen?).

Solange der private Schlüssel auf dem Remote-Rechner ist, gibt eskein Unterschiedwie es dorthin gelangt ist. Die Systemadministratoren können darauf zugreifen. Eine Passphrase würde außerdem nur zusätzlichen Aufwand bedeuten, um an die Schlüssel zu kommen, da sie auch auf Ihre Eingaben zugreifen könnten.

Und wenn ich mit meiner leichten Paranoia recht habe, was denken Sie darüber, wo private Schlüssel gespeichert werden sollen? Sollten sie alle an einem physischen Ort sein? Sollte ich den GPG-Agenten und den SSH-Agenten immer intensiv nutzen?

Dies hängt von Ihren Anforderungen, Ihrem Grad der Paranoia, Ihrem Vertrauen in die Systemadministratoren und letztendlich von der Verwendung des Schlüssels ab.

Wenn Sie eine privateSSHSchlüssel auf dem Computer für den Zugriff auf einige Dienste (sagen wir, GitHub), generieren Sie einfach einen neuen, der nur auf diesem Computer verwendet und nur für die Authentifizierung bei den benötigten Diensten/Computern akzeptiert wird.

HinsichtlichOpenPGP/GnuPG, das hängt von Ihren Anforderungen ab. Anscheinend möchten Sie Software signieren, und ich habe das Gefühl, dass dies für Ihr Unternehmen geschieht. Wenn der Schlüssel direkt mit dem Unternehmen verknüpft ist und nur für diesen Zweck erstellt wurde, sehe ich keine Einwände, ihn nicht auf deren Maschinen zu haben.

Wenn Sie aus irgendwelchen Gründen Ihren eigenen Schlüssel verwenden müssen, erstellen Sie einen Unterschlüssel, den Sie zumindest auf das Signieren beschränken und jederzeit problemlos widerrufen können. Die Verwendung von Unterschlüsseln ist ohnehin eine gute Praxis! Viele OpenPGP-Poweruser speichern ihre privaten Primärschlüssel tatsächlich offline und verwenden sie eigentlich nur zur Schlüsselverwaltung.

Die Weiterleitung gpg-agentdes Sockets scheint gut möglich zu sein, und natürlich wird der Zugriff des Systemadministrators auf den Schlüssel eingeschränkt (er hat keinen Zugriff mehr auf den vollständigen Schlüssel, sondern kann ihn nur noch verwenden, zumindest ab GnuPG 2.1, dasalleprivate Schlüsseloperationen an den Agenten).

verwandte Informationen