Wie funktionieren SSH-Schlüssel? [duplizieren]

Was macht es im Grunde besser als ein wirklich langes Passwort?

Sie werden nicht auf den Server übertragen (da auch das sehr lange Passwort übertragen werden muss). Es ist im Fall ssh nicht unsicher (der Kanal ist verschlüsselt, es sei denn, Sie verwenden kaputte Chiffren), kann aber theoretisch von Man In the Middle oder böswilligen (Super-) Benutzern abgefangen werden der Remote-Server.

Und wie spielt der öffentliche Schlüssel in die Dinge hinein?

Dies ist der Punkt der asymmetrischen Kryptographie. Der private Schlüssel erstellt eine Signatur und public kann überprüfen, ob die Signatur vom jeweiligen öffentlichen Schlüssel erstellt wurde. Sie senden den öffentlichen Schlüssel und die Signatur der vom Server angebotenen Daten. Dies reicht aus, damit der Server Ihnen den Zugriff ermöglicht (wenn der öffentliche Schlüssel mit dem in authorized_keys übereinstimmt).

Kommentare

• Wenn also der öffentliche Schlüssel übereinstimmt, werden die zurückgehenden Daten mit diesem öffentlichen Schlüssel verschlüsselt, den der private Schlüssel dann entschlüsseln kann ? Und umgekehrt mit der privaten Verschlüsselung und der öffentlichen Entschlüsselung?
• verschlüsselt mit diesem öffentlichen Schlüssel, den der private Schlüssel dann entschlüsseln kann – signiert mit privatem Schlüssel, welcher öffentliche Schlüssel kann Verifizieren.
• Was bedeutet " signiert "? Was verhindert, dass etwas etwas entschlüsselt, auch wenn die Signatur nicht ausgecheckt wird?
• @amflare: en.wikipedia.org/wiki/Digital_signature Wenn überhaupt, dann der eigene Code des potenziellen Entschlüsselers '.
• Richtig, das verstehe ich. Daher meine (anscheinend fehlerhafte) Annahme, dass die Schlüssel die Ver- und Entschlüsselung ermöglichten. Aber wenn ich eine böswillige Partei wäre, könnte ich die Daten abfangen, die Authentizität der Signatur ignorieren und trotzdem versuchen, sie zu entschlüsseln. Ich hatte den Eindruck, dass die Schlüssel dazu dienten, auch Dritte daran zu hindern.

Ich bin nicht sicher, was Sie SSH mit dem „sehr langen Passwort“ vergleichen. SSH bietet eine sichere Möglichkeit, Ihre Benutzeranmeldung und Ihr Kennwort an einen Remote-Server zu senden. Sie können auch den öffentlichen Schlüssel eines Clients verwenden. Asymmetrische Schlüssel sind im Allgemeinen schwerer zu knacken, da sie nicht dazu führen, dass Benutzer falsche Kennwörter erstellen. Aus diesem Grund wird die Authentifizierung auf Basis öffentlicher Schlüssel bevorzugt. Sie können bestimmte öffentliche Schlüssel für Ihren Benutzer (und Ihre IP-Adresse) auf die weiße Liste setzen, damit sich nicht jeder mit Ihrem Benutzernamen und von jedem Computer aus anmelden kann. Diese weiße Liste ist in /home/<user>/.ssh/authorized_keys enthalten.

Grundlagen von SSH:

1. Server präsentiert seinen öffentlichen RSA-Schlüssel an der Kunde. Der Client überprüft manuell, ob er diesem Schlüssel vertraut, bevor er fortfährt.

2. SSH verwendet Diffie Hellman, um einen gemeinsamen geheimen Wert festzulegen.

3. Das gemeinsame Geheimnis wird zusammen mit vielen Schlüsselaustauschdaten zusammen gehasht und mit dem privaten Schlüssel des Servers signiert.

4. Der Client kann diese Signatur mit den vorherigen Servern überprüfen vertrauenswürdiger öffentlicher Schlüssel.

5. Beide Seiten verfügen jetzt über alle Informationen, die zum Generieren von Sitzungsschlüsseln erforderlich sind.

Aus Abschnitt 7.2 von RFC4253

7.2. Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we"ll call it HASH. Encryption keys MUST be computed as HASH, of a known value and K, as follows: o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data. "A" means the single character A, ASCII 65). o Initial IV server to client: HASH(K || H || "B" || session_id) o Encryption key client to server: HASH(K || H || "C" || session_id) o Encryption key server to client: HASH(K || H || "D" || session_id) o Integrity key client to server: HASH(K || H || "E" || session_id) o Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. As many bytes as needed are taken from the beginning of the hash value. If the key length needed is longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is available; the key is taken from the beginning of this value. In other words: K1 = HASH(K || H || X || session_id) (X is e.g., "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH. 

Sobald der verschlüsselte Kanal eingerichtet ist, beginnt das SSH-Protokoll mit der Clientauthentifizierung nach Parametern, die Sie angegeben haben. All dies wird sicher über den verschlüsselten Kanal ausgeführt.

Lassen Sie mich ein Bild auf hoher Ebene liefern. Sie verstehen eindeutig die Notwendigkeit einer sicheren Kommunikation, sei es SSH oder HTTPS. Sichere Kommunikation bedeutet, dass der Kanal verschlüsselt ist.

Im Allgemeinen fallen alle Verschlüsselungsalgorithmen in eine von zwei Kategorien:

• Symmetrische Verschlüsselung. Ein Schlüssel. Der gleiche Schlüssel wird zum Ver- und Entschlüsseln verwendet. Schnell. Z.B. AES.
• Asymmetrische Verschlüsselung. Zwei Schlüssel. Beides kann zum Verschlüsseln verwendet werden, aber nur das andere kann entschlüsseln. Viel langsamer als symmetrische Algorithmen. Z.B. RSA.

Symmetrische Verschlüsselung ist schnell und daher für die Kommunikation mit vielen Daten zwischen zwei Parteien geeignet. Für die Ver- und Entschlüsselung wird derselbe Schlüssel verwendet. Dieser Schlüssel entspricht Ihrem Konzept eines sehr langen Passworts. Problem: Wie teilen Sie Ihren Schlüssel / Ihr Passwort überhaupt? Es stellt sich heraus, dass Sie keinen sicheren Kanal verwenden können, der ausschließlich auf einem symmetrischen Verschlüsselungsalgorithmus basiert, ohne zunächst eine Möglichkeit zu finden, Ihren Schlüssel / Ihr Kennwort gemeinsam zu nutzen.

Hier kommen asymmetrische Algorithmen ins Spiel, die jedoch erheblich langsamer sind als symmetrische Algorithmen. Es ist unpraktisch, große Datenmengen zu übertragen, aber in Ordnung, wenn Sie etwas Kleines wie einen symmetrischen Verschlüsselungsschlüssel / ein symmetrisches Kennwort übertragen oder austauschen. Sobald dies erledigt ist, können Sie jetzt die symmetrische Verschlüsselung für die Kommunikation verwenden.

Einer der beiden Schlüssel für die asymmetrische Verschlüsselung wird als öffentlicher Schlüssel und der andere als privater Schlüssel bezeichnet. Der öffentliche Schlüssel kann an alle verteilt werden. Der private Schlüssel muss jedoch geheim gehalten werden.

You (has pub) Server (has prv + pub) asym-encrypt(pub, sym-key/pwd) ----> asym-decrypt(prv, encrypted-data) => sym-key/pwd 

pub = öffentlicher Schlüssel, prv = privater Schlüssel

In jedem Fall ist diese Erklärung a Vereinfachung der tatsächlichen Funktionsweise von SSH. Zwei weitere Dinge, die hervorgehoben werden sollten:

• Diffie Hellman ist der typische asymmetrische Algorithmus für den Schlüsselaustausch. Mit Diffie Hellman müssen Sie keinen symmetrischen Schlüssel erstellen . Beide Parteien erstellen den symmetrischen Schlüssel zusammen während des Schlüsselaustauschs, was eine nette Sicherheitsfunktion ist. Siehe " Diffie-Hellman-Schlüsselaustausch " im Klartext .

• In meiner Erklärung habe ich angenommen, dass Sie den öffentlichen Schlüssel des Servers gefunden haben und darauf vertrauen, dass er der richtige ist. Aber Sie sollten wirklich vorsichtig sein, welche öffentlichen Schlüssel Sie verwenden Vertrauen. Um einem öffentlichen Schlüssel zu vertrauen, sollte er digital signiert sein. Ein signierter öffentlicher Schlüssel wird auch als Zertifikat bezeichnet.

Hoffentlich werden dadurch die Fragen zu langem Kennwort und geklärt öffentliche Schlüssel und verfügt über genügend Informationen, damit Sie aussagekräftiger tiefer graben können.