Wie speichere ich SSH-Schlüssel?

Ich habe erst kürzlich angefangen, SSH-Schlüssel anstelle von Passwörtern zu verwenden (natürlich dank GitHub). Denken Sie also daran, dass ich mit diesem ganzen Konzept ziemlich neu bin. Momentan liegen meine Schlüssel einfach unter ~ / .ssh, aber ich bin nicht sicher, ob dies eine gute Praxis ist. Wenn ich beispielsweise mehrere Computer habe, muss ich meine privaten Schlüssel duplizieren, was ich für unerwünscht halte. Oder wenn meine Festplatte kaputt geht, dann verliere ich diese Schlüssel, was (ich denke) auch unerwünscht ist.

Was sind also bewährte Methoden zum sicheren, bequemen und zuverlässigen Speichern von SSH-Schlüsseln?

Die Verwendung einer Smartcard scheint eine Option zu sein (siehe Smartcards zum Speichern von gpg / ssh-Schlüsseln (Linux) - was brauche ich? ). Ist dies die beste Option ?

Update: Der Grund für die Frage war, dass viele Dienste (wie GitHub, AWS EC2) Anleitungen zum Einrichten von SSH-Schlüsseln für die Verwendung des Dienstes bereitstellen, aber nur wenige oder gar keine Hintergrundinformationen (z. B. was zu tun ist, wenn Sie bereits einen Schlüssel generiert haben) von ssh-keygen[1], welche Sicherheitsmaßnahmen werden empfohlen). Und es ist nicht klar, ob diese Informationen tatsächlich unwichtig sind oder ob Sie sie "standardmäßig" kennen.

Um die Antworten bis zu diesem Punkt zusammenzufassen (aber lesen Sie sie bitte durch, und wenn Sie etwas hinzuzufügen haben - bitte tun Sie dies): In diesem Fall scheint es in Ordnung zu sein, wenn Sie Ihre privaten Schlüssel einfach so lange in ~ / .ssh belassen, wie Sie möchten halte sie von anderen Menschen fern; Stellen Sie jedoch sicher, dass Sie eine andere Möglichkeit haben, auf den Dienst zuzugreifen, um einen neuen Schlüssel hochzuladen oder zu generieren, falls Sie einen verlieren (was normalerweise der Fall ist).

[1] GitHub wurde verwendet, um Hilfe zum Verwalten mehrerer Schlüssel bereitzustellen .

Wenn ich beispielsweise mehrere Computer habe, müsste ich private Schlüssel duplizieren, was ich für unerwünscht halte.

Nein, das tust du eigentlich nicht. Wenn Sie mehrere Computer haben, erstellen Sie auf jedem einen separaten privaten Schlüssel. Laden Sie für jeden privaten Schlüssel einfach den entsprechenden öffentlichen Schlüssel nach demselben Verfahren auf GitHub hoch.

Auch wenn meine Festplatte kaputt geht, verliere ich meinen privaten Schlüssel, was (ich denke) auch unerwünscht ist.

Nicht wirklich; Wenn Sie Ihren privaten Schlüssel verlieren, erstellen Sie einfach einen neuen und laden Sie den entsprechenden öffentlichen Schlüssel hoch.

Sie haben Recht, dass das Duplizieren eines privaten Schlüssels höchst unerwünscht ist. Im Idealfall sollte ein privater Schlüssel ( ~/.ssh/id_rsazum Beispiel) in einer Datei generiert werden und diese Datei niemals verlassen - das heißt, er sollte niemals kopiert, verschoben und insbesondere nicht über ein Netzwerk übertragen werden. (Ich schließe sie z. B. von Sicherungen aus.) Aufgrund der Art der asymmetrischen Authentifizierungsprotokolle müssen Sie sich nur darum kümmern, dass Ihr privater Schlüssel nicht in die Hände anderer gelangt. Wenn Sie etwas über Bord gehen und selbst den Überblick verlieren, ist dies im Allgemeinen keine große Sache. (Dies ist nicht zu verwechseln mit privaten Schlüsseln mit asymmetrischer Verschlüsselung , z. B. GPG-Schlüsseln, an denen Sie wahrscheinlich festhalten möchten.)

Ich würde hinzufügen, dass ~ / .ssh / von Ihrem Browser gelesen werden kann, wenn Sie dasselbe Benutzerkonto verwenden, um beide auszuführen.

Versuch es! Zeigen Sie mit Ihrem Browser auf Ihren privaten Schlüssel in Ihrem Home-Verzeichnis. Es macht Spaß.

Daher würde ich empfehlen, ssh-keys im Home-Verzeichnis eines anderen Benutzerkontos zu speichern.

Ein Wort zum Passwortschutz

• Das Knacken nicht randomisierter Passwörter ist heutzutage superschnell. Karo heraus Haschkatze
  • (Obwohl zufällige und lange 12+ Zeichen-Passwörter noch einigermaßen lange dauern, bis sie brachial sind)
  • AES-verschlüsselte SSH-Schlüssel sind daher auf absehbare Zeit nicht zu knacken, solange Sie gute lange Passphrasen verwenden. Siehe Github-Empfehlungen
• Einige Websites können also Ihren Schlüssel ohne JavaScript erraten. Und dann den Schlüssel offline brute-force.
• Und Browser können auch in Ihre Zwischenablage mit JS schauen. Wenn Sie also sehr lange Passphrasen kopieren, sind Sie auch einem Risiko durch die ausgefeilteren Javascript-Angriffe ausgesetzt.

look_at_keys.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

Es gibt ein sehr schönes Tool namens KeePass2 ( http://keepass.info/ ) mit der Erweiterung ( http://lechnology.com/software/keeagent/ )

Sie können dort Passwörter, SSH-Schlüssel und vieles mehr speichern (auf der offiziellen KeePass-Seite finden Sie weitere nützliche Erweiterungen).
Wenn Sie sich automatisch mit Ihren SSH-Schlüsseln anmelden möchten, müssen Sie nur PuTTY, Pageant und KeePass mit KeeAgent installieren. Wenn Sie es richtig konfigurieren, müssen Sie die Keys nicht in PuTTY, Pageant oder FileZilla einrichten.

Ich benutze es selbst und bin ziemlich glücklich darüber. Ich habe über 30 VPS und Root-Server mit einer bestimmten Anzahl von verschiedenen SSH-Schlüsseln und das einzige, was ich tun muss, ist KeePass zu öffnen (es ist nicht mein primäres Passwort-Safe) und dann muss ich nur meine Passphrase in die Konsole eingeben.

Ich würde empfehlen, private Schlüssel zu speichern:

• offline (nicht in der Cloud)
• an mehr als einem Ort
• Speichern Sie Ihre verschlüsselten Daten, abgesehen von allem, was damit zusammenhängt, z. B. einem Schlüssel, an einem anderen Ort als den Daten

Ich würde sagen, der beste Ort wäre:

• eine externe Festplatte
• eine Flash-Taste
• Ein Computer, der nicht mit dem Internet verbunden ist

Noch besser, drucken Sie es einfach aus und legen Sie es in einen feuerfesten Safe.

Ich habe eine tar-Datei, deren Benutzerverzeichnis (.bashrc, .ssh / und andere Konfigurationsdateien) ich an einem sicheren Ort verwahre. Wenn ich irgendwo ein neues Shell-Konto erhalte, entpacke ich die tar-Datei.

Sie sollten Ihre privaten Schlüssel nur auf Servern ablegen, denen Sie vertrauen, andernfalls sollten Sie einen neuen privaten Schlüssel auf dem Server nur für diesen Server erstellen und ihm Zugriff auf Dinge gewähren, auf die er Zugriff haben soll.

Persönlich fühle ich mich wohl, wenn ich meine .ssh / -Dateien überall kopiere (dies bedeutet auch, dass der reguläre ssh-Schlüssel sofort Zugriff auf ssh erhält, da er bereits in der authorized_keys-Datei enthalten ist).

Sie können Ihre SSH-Schlüssel in einem separaten Verzeichnis in einer verschlüsselten Partition speichern. Dann können Sie mit ssh auf dieses Verzeichnis zeigen -i:

ssh -i identity_file me@example.com

Vollständige Beschreibung ( man ssh):

-i identitätsdatei

Wählt eine Datei aus, aus der die Identität (privater Schlüssel) für die Authentifizierung mit öffentlichem Schlüssel gelesen wird. Die Standardeinstellung ist ~ / .ssh / identity für Protokollversion 1 und ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 und ~ / .ssh / id_rsa für Protokollversion 2. Identitätsdateien können Kann auch in der Konfigurationsdatei für jeden Host einzeln angegeben werden.
Es können mehrere -i-Optionen (und mehrere in Konfigurationsdateien angegebene Identitäten) angegeben werden. Wenn in der CertificateFile-Direktive keine Zertifikate explizit angegeben wurden, versucht ssh auch, Zertifikatinformationen aus dem Dateinamen zu laden, der durch Anhängen von -cert.pub an Identitätsdateinamen erhalten wurde.

Mein Sicherheitsansatz besteht darin, Informationen in private und allgemeine zu unterteilen. Ich möchte nicht meine gesamte Home-Partition verschlüsseln, deshalb kopiere ich geheime Dateien (wie die in ~/.ssh) in eine verschlüsselte Partition.

Ich denke, dies bietet eine ziemlich effiziente Sicherheit, da Malware in ~ / .ssh nichts findet und wahrscheinlich nicht Ihr gesamtes System oder Ihre Shell-Profile nach diesem Speicherort durchsucht.

-F configfile 

Setzt den Pfad zur Konfigurationsdatei.

PS Ich würde einen Alias ​​erstellen alias ssh='ssh -i ... -F ...'und ihn in Ihr Profil einfügen.

PPS Ich habe dies noch nicht überprüft und ich weiß nicht, wie andere Programme (wie Git) mit diesen SSH-Einstellungen arbeiten werden.