SSH Key Management - Tools, Grundlagen und Verständnisfragen!

noLust

Wo fange ich an ... Ich befürchte, ich habe bislang alles falsch gemacht, weil mir die Basics fehlen. Aber der Reihe nach.

Ich kenne die CLI-Tools zum Anlegen, Übertragen, Installieren von SSH-Keys: ssh-keygen, ssh-copy-id und ssh-import-id.

Ich habe einen Computer und ein Smartphone und ein Notebook. Auf dem Computer habe ich einen rsa 4096 key generieren lassen. Diesen habe ich mit copy-id auf den Server geschubst (genauer gesagt, den öffentlichen Schlüssel). Danach habe ich den Server zu gemacht, und Passwort-Logins verboten (vermutlich war das bereits der erste Fehler, siehe zum Beispiel hier: https://security.stackexchange.com/questions/69407/why-is-using-an-ssh-key-more-secure-than-using-passwords, tl;dr: MITM-Attacken drohen).

Nun möchte ich mich natürlich auch mit dem Notebook und mit dem Smartphone mit dem Server verbinden. Darf ich dann einfach den privaten Schlüssel auf diese Geräte übertragen - oder sollten private Schlüssel einmal an einem sicheren Ort aufbewahrt werden, und das Endgerät dann niemals verlassen?!

Und die zweite Frage betrifft Windows ... Ich kenne (die Software) PuTTY, um eine sichere SSH-Verbindung mit einem Server aufzubauen. Aber ist das auch das (einzige) Tool, welches man verwenden sollte?

tl;dr: Wie sind öffentliche und private SSH-Keys zu handhaben, und worauf muss man besonders achten?

SeppJ

Du kannst deinen privaten Key mit dir mitnehmen zu anderen Geräten, die dir gehören. Je nach Vertrauensstand in diese Geräte und deren Admin, ist es ggf. dringend zu empfehlen, den privaten Schlüssel zu verschlüsseln.

PuTTY ist eines von vielen Werkzeugen. SSH ist ein Protokoll, von dem es so manche Umsetzungen geben kann. Wobei die meisten Sachen, die SSH umsetzen, unter der Haube einfach OpenSSH sind. PuTTY ist da eine seltene Ausnahme, da das soweit ich weiß eine eigene Umsetzung von SSH hat.

noLust

@SeppJ Moin

Aber ich dachte, es gäbe eine "Policy/Contract", dass ein privater und öffentlicher Key niemals ein Endgerät verlassen darf ... (oder zumindest "good practice")

Wenn dem aber nicht so ist ... nun ja, dann hab ich eigentlich kein Problem. PuTTY kann den OpenSSH-Key übrigens auch bequem in ein anderes Format bringen, insofern erforderlich.

@noLust sagte in SSH Key Management - Tools, Grundlagen und Verständnisfragen!:

tl;dr: MITM-Attacken drohen

... damit meinte ich eigentlich, es kann ein anderer Server vorgetäuscht werden, was durch Keys ausgeschlossen würde.

Beispiel: Ich will mich mit hallo123.de verbinden, mit der IP 4.3.2.1, stattdessen verbindet sich SSH aber mit 3.4.2.1, welcher jedes Passwort akzeptiert. (Ok, das ist vielleicht nicht ganz realistisch, weil hallo123.de ja auch noch einen Fingerabdruck hat)

Edit: Das war jetzt nur ein Beispiel, ich weiß nicht, ob es die Domain gibt.

Schlangenmensch

@noLust sagte in SSH Key Management - Tools, Grundlagen und Verständnisfragen!:

Danach habe ich den Server zu gemacht, und Passwort-Logins verboten (vermutlich war das bereits der erste Fehler, siehe zum Beispiel hier: https://security.stackexchange.com/questions/69407/why-is-using-an-ssh-key-more-secure-than-using-passwords, tl;dr: MITM-Attacken drohen).

Das verstehe ich gerade nicht, warum sind Man in the middle Attacken gegen ssh Verbindungen "schlimmer" als gegen Password geschützte Server?

@noLust sagte in SSH Key Management - Tools, Grundlagen und Verständnisfragen!:

dass ein privater und öffentlicher Key niemals ein Endgerät verlassen darf

Der "öffentliche" Key heißt doch so, weil er eben für die Öffentlichkeit ist und dein Gerät verlassen darf.

Ansonsten ist SSH halt so vertrauenswürdig, wie das System, auf dem der private Schlüssel gespeichert ist, wobei man den ja auch nochmal verschlüsseln kann. Aber, wenn du deinem System nicht vertauen willst/kannst, wird es eh schwer.

Meiner Meinung nach wäre der Königsweg, das mit einem Fido2 Token zu kombinieren (z.B. einem YubiKey). Das setze ich aktuell selbst noch nicht ein, denn als ich das letzte mal nachgeschaut habe, wurde Fido 2 noch von recht wenigen Anbietern unterstützt. Aber das steht trotzdem auf meiner "ToDo".

noLust

@Schlangenmensch sagte in SSH Key Management - Tools, Grundlagen und Verständnisfragen!:

Das verstehe ich gerade nicht, warum sind Man in the middle Attacken gegen ssh Verbindungen "schlimmer" als gegen Password geschützte Server?

Hier ist eine Zusammenfassung der relevanten Antwort (erstellt von ChatGPT):

Die Antwort auf Security.StackExchange erklärt, warum SSH-Schlüssel im Allgemeinen sicherer als Passwörter sind. Hier sind die wichtigsten Punkte zusammengefasst:

Komplexität: SSH-Schlüssel sind länger und komplexer als Passwörter, was sie schwerer zu knacken macht.
Nicht-Übertragung: Während Passwörter an den Server gesendet werden müssen und daher abgefangen werden können, bleibt der private SSH-Schlüssel stets auf dem Client und wird nicht übertragen.
Menschlicher Faktor: Passwörter sind oft schwach, da Nutzer kurze, einfache Passwörter verwenden und diese wiederverwenden. Dies macht Passwörter anfälliger für Brute-Force-Angriffe.
Passwörter vs. Passphrasen: Obwohl SSH-Schlüssel mit einer Passphrase geschützt werden können, bleibt das grundlegende Problem der Passwortsicherheit bestehen, wenn Nutzer schwache Passphrasen wählen.
Serverkompromittierung: Selbst wenn ein Server kompromittiert ist oder man mit einem gefälschten Server verbunden wird, wird der SSH-Schlüssel nicht offengelegt, was bei Passwörtern nicht der Fall ist.

Die Antwort deutet darauf hin, dass SSH-Schlüssel sicherer sind, weil sie komplexer und lokal gespeichert sind und nicht übertragen werden müssen. Diese Faktoren machen es Angreifern schwieriger, Zugriff zu erhalten. Ich stimme dieser Einschätzung zu, da die genannten Argumente gut begründet sind und die bekannten Schwachstellen von Passwörtern korrekt ansprechen.

Hier ist die Antwort im Original: Warum ist die Verwendung eines SSH-Schlüssels sicherer als die Verwendung von Passwörtern?

Schlangenmensch

@noLust Aber, das widerspricht doch deiner Aussage, dass Passwort Logins zu verbieten ein Fehler war.
Aus dem Post habe ich raus gelesen, dass SSH besonders anfällig für man in the middle sei, was mich gewundert hatte.

Prinzipiell bin ich vollkommen bei dir (soweit ich dich jetzt verstanden habe): Ich halte SSH auch für sicherer als Passwörter.

noLust

Neiin, es ging nur um die (sichere) Verwendung von SSH-Passwörtern versus SSH-Keys für den SSH-Login ...

Und den Punkt 5. (Serverkompromittierung) hab ich fälschlicherweise als MITM-Attacke verstanden.