Jak fungují klíče SSH? [duplicate]

Čím je v podstatě lepší než opravdu dlouhé heslo?

Nepřevádějí se na server (protože je třeba přenést i velmi dlouhé heslo). V případě ssh není kanál nejistý (kanál je šifrovaný, pokud nepoužíváte poškozené šifry), ale teoreticky jej může zachytit Man In the middle nebo škodlivý (super) uživatel na vzdálený server.

A jak hraje veřejný klíč věci?

Toto je bod asymetrické kryptografie. Soukromý klíč vytvoří podpis a veřejný může ověřit, že podpis byl vytvořen příslušným veřejným klíčem. Odešlete veřejný klíč a podpis dat nabízených serverem a to je dost, aby vám server umožnil přístup (pokud se veřejný klíč shoduje s klíčem v authorized_keys).

Komentáře

• Takže odešle veřejný klíč, pokud se shoduje, data vracená zpět jsou zašifrována tímto veřejným klíčem, který může soukromý klíč poté dešifrovat ? A naopak se soukromým šifrováním a veřejným dešifrováním?
• šifrované tímto veřejným klíčem, který může soukromý klíč poté dešifrovat – podepsáno soukromým klíčem, který veřejný klíč může ověřit.
• Co znamená " podepsáno "? Co brání tomu, aby něco dešifrovalo, i když se podpis neodhlásí?
• @amflare: en.wikipedia.org/wiki/Digital_signature Pokud něco, pak vlastní kód potenciálního decryptora '.
• Dobře, chápu. Proto můj (zjevně chybný) předpoklad, že klíče umožňovaly šifrování a dešifrování. Ale zdá se, že kdybych byl nebezpečnou stranou, mohl bych zachytit data a ignorovat autentičnost podpisu a pokusit se je stejně dešifrovat. Měl jsem dojem, že klíče sloužily jako prostředek, který také bránil třetím stranám v tom.

Nejsem si jistý, co porovnáváte SSH s „velmi dlouhým heslem“. SSH poskytuje bezpečný prostředek k odeslání vašeho uživatelského jména a hesla na vzdálený server. Nebo můžete použít veřejný klíč klienta. Asymetrické klíče je obecně těžší prolomit, protože „nepodléhají tomu, aby uživatelé vytvářeli špatná hesla. Z tohoto důvodu je upřednostňováno ověřování na základě veřejného klíče. Můžete povolit konkrétní veřejné klíče pro svého uživatele (a IP), takže se kdokoli může přihlásit pomocí vašeho uživatelského jména a z libovolného počítače. Tento bílý seznam je obsažen v /home/<user>/.ssh/authorized_keys.

Základy SSH:

1. Server představuje svůj veřejný klíč RSA pro klient. Klient před pokračováním ručně ověří, že tomuto klíči důvěřuje.

2. SSH používá Diffie Hellman k vytvoření sdílené tajné hodnoty.

3. Sdílené tajemství spolu se spoustou údajů o výměně klíčů je hašováno společně a podepsáno pomocí soukromého klíče serveru.

4. Klient si může tento podpis ověřit pomocí dříve použitých serverů důvěryhodný veřejný klíč.

5. Obě strany mají nyní všechny informace potřebné ke generování klíčů relace.

V sekci 7.2 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. 

Jakmile je vytvořen šifrovaný kanál, začne protokol SSH na základě autentizace klienta podle parametrů, které jste zadali. To vše se provádí bezpečně prostřednictvím šifrovaného kanálu.

Dovolte mi poskytnout obrázek na vysoké úrovni. Je zřejmé, že chápete potřebu zabezpečené komunikace, ať už jde o SSH nebo HTTPS. Zabezpečená komunikace znamená, že kanál je šifrován.

Obecně lze říci, že všechny šifrovací algoritmy spadají do jedné ze dvou kategorií:

• Symetrické šifrování. Jeden klíč. Stejný klíč se používá k šifrování a dešifrování. Rychle. Např. AES.
• Asymetrické šifrování. Dva klíče. K šifrování lze použít buď, ale dešifrovat lze pouze ten druhý. Mnohem pomalejší než symetrické algoritmy. Např. RSA.

Symetrické šifrování je rychlé, a proto se hodí pro komunikaci zahrnující velké množství dat mezi dvěma stranami. Pro šifrování a dešifrování používá stejný klíč – tento klíč je analogický vaší koncepci velmi dlouhého hesla. Problém: Jak vlastně sdílíte svůj klíč / heslo? Ukázalo se, že nemůžete použít zabezpečený kanál, který je postaven pouze na symetrickém šifrovacím algoritmu, aniž byste vymysleli způsob, jak nejprve sdílet svůj klíč / heslo.

Zde přicházejí asymetrické algoritmy, ale jsou podstatně pomalejší než symetrické algoritmy. Nepraktické pro přenos velkého množství dat, ale v pořádku, pokud přenášíte nebo vyměňujete něco malého, jako je symetrický šifrovací klíč / heslo. Jakmile budete hotovi, můžete nyní pro komunikaci používat symetrické šifrování.

Jeden ze dvou klíčů pro asymetrické šifrování je označen jako veřejný klíč a druhý jako soukromý klíč. Veřejný klíč může být distribuován všem, ale soukromý klíč musí být udržován v tajnosti.

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

pub = veřejný klíč, prv = soukromý klíč

V každém případě je toto vysvětlení zjednodušení toho, co vlastně SSH dělá. Je třeba zdůraznit dvě další věci:

• Diffie Hellman je typický asymetrický algoritmus výměny klíčů. S Diffie Hellman vlastně nemusíte vytvářet symetrický klíč . Obě strany vytvoří během výměny klíčů symetrický klíč společně, což je pěkný bezpečnostní prvek. Viz " Diffie-Hellman Key Exchange " v jednoduché angličtině .

• Ve svém vysvětlení jsem předpokládal, že jste našli veřejný klíč serveru a že mu důvěřujete, že je správný. Ale opravdu byste měli být opatrní, které veřejné klíče máte důvěra. Chcete-li důvěřovat veřejnému klíči, měl by být digitálně podepsán. Podepsaný veřejný klíč je také známý jako certifikát.

Doufejme, že to vyjasní otázky týkající se dlouhého hesla a veřejné klíče a má dostatek informací, abyste mohli hlouběji kopat smysluplnějším způsobem.