Hvordan fungerer SSH-nøgler? [duplikat]

Grundlæggende, hvad gør det bedre end en rigtig lang adgangskode?

De overføres ikke til serveren (da selv den meget lange adgangskode skal overføres). Det er ikke usikkert i ssh -sagen (kanalen er krypteret, medmindre du bruger ødelagte cifre), men i teorien kan den opfanges af mand i midten eller ondsindet (super) bruger på fjernserveren.

Og hvordan spiller den offentlige nøgle ind i tingene?

Dette er punktet med asymmetrisk kryptografi. Privat nøgle opretter signatur, og offentlig kan kontrollere, at signaturen blev foretaget af den respektive offentlige nøgle. Du sender den offentlige nøgle og signatur af data, der tilbydes af serveren, og dette er nok til, at serveren giver dig adgang (hvis den offentlige nøgle matcher den i authorized_keys).

Kommentarer

• Så det sender den offentlige nøgle, hvis den matcher, krypteres de data, der går tilbage, med den offentlige nøgle, som den private nøgle derefter kan dekryptere ? Og omvendt med privat kryptering og offentlig dekryptering?
• krypteret med den offentlige nøgle, som den private nøgle derefter kan dekryptere – underskrevet med privat nøgle, hvilken offentlig nøgle kan bekræft.
• Hvad betyder " underskrevet "? Hvad forhindrer noget i at dekryptere noget, selvom signaturen ikke tjekker ud?
• @amflare: da.wikipedia.org/wiki/Digital_signature Hvis der er noget, så ville den kommende dekrypterings ' s egen kode.
• Ret, det forstår jeg. Derfor er min (tilsyneladende mangelfulde) antagelse om, at nøglerne aktiverede kryptering og dekryptering. Men det ser ud til, at hvis jeg var en ondsindet part, kunne jeg opfange dataene og ignorere ægtheden af signaturen og alligevel forsøge at dekryptere dem. Jeg havde det indtryk, at tasterne fungerede som et middel til også at forhindre tredjeparter i at gøre det.

Jeg ved ikke, hvad du sammenligner SSH med den “meget lange adgangskode”. SSH giver et sikkert middel til at sende dit brugerlogin og din adgangskode til en ekstern server. Eller du kan bruge en klients offentlige nøgle. Asymmetriske nøgler er generelt sværere at bryde, fordi de ikke er underlagt brugere, der opretter dårlige adgangskoder. Offentlig nøglebaseret godkendelse foretrækkes af den grund. Du kan hvidliste specifikke offentlige nøgler til din bruger (og IP), så ikke bare nogen kan logge ind med dit brugernavn og fra enhver computer. Denne hvide liste er indeholdt i /home/<user>/.ssh/authorized_keys.

Grundlæggende om SSH:

1. Server præsenterer sin offentlige RSA-nøgle til klienten. Klienten verificerer manuelt, at den stoler på denne nøgle, før den fortsætter.

2. SSH bruger Diffie Hellman til at etablere en delt hemmelig værdi.

3. Den delte hemmelighed sammen med masser af nøgleudvekslingsdata hashes sammen og underskrives ved hjælp af serverens private nøgle.

4. Klienten kan bekræfte denne signatur ved hjælp af serverens tidligere betroet offentlig nøgle.

5. Begge sider har nu alle de oplysninger, der er nødvendige for at generere sessionsnøgler.

Fra sektion 7.2 af 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. 

Når den krypterede kanal er oprettet, begynder SSH-protokollen klientgodkendelsesbaseret på parametre har du givet det. Alt dette udføres sikkert gennem den krypterede kanal.

Lad mig give et billede på højt niveau. Det er klart, at du forstår behovet for sikker kommunikation, det være sig SSH eller HTTPS. Sikker kommunikation betyder, at kanalen er krypteret.

Generelt falder alle krypteringsalgoritmer i en af to kategorier:

• Symmetrisk kryptering. Én nøgle. Samme nøgle bruges til at kryptere og dekryptere. Hurtig. For eksempel. AES.
• Asymmetrisk kryptering. To nøgler. Enten kan bruges til at kryptere, men kun den anden kan dekryptere. Meget langsommere end symmetriske algoritmer. For eksempel. RSA.

Symmetrisk kryptering er hurtig og derfor velegnet til kommunikation, der involverer en masse data mellem to parter. Den bruger den samme nøgle til kryptering og dekryptering – denne nøgle er analog med dit koncept om en meget lang adgangskode. Problem: hvordan deler du i første omgang din nøgle / adgangskode? Det viser sig, at du ikke kan bruge en sikker kanal, der udelukkende er bygget på en symmetrisk krypteringsalgoritme uden at finde ud af, hvordan du først deler din nøgle / adgangskode.

Det er her, asymmetriske algoritmer kommer ind, men er betydeligt langsommere end symmetriske algoritmer. Praktisk at sende store mængder data, men fint, hvis du transmitterer eller udveksler noget lille som en symmetrisk krypteringsnøgle / adgangskode. Når dette er gjort, kan du nu bruge symmetrisk kryptering til kommunikation.

En af de to nøgler til asymmetrisk kryptering betegnes den offentlige nøgle og den anden den private nøgle. Den offentlige nøgle kan distribueres til alle, men privat nøgle skal holdes hemmelig.

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

pub = offentlig nøgle, prv = privat nøgle

Under alle omstændigheder er denne forklaring en forenkling af, hvad SSH faktisk gør. To andre ting, der er værd at fremhæve:

• Diffie Hellman er den typiske asymmetriske nøgleudvekslingsalgoritme. Med Diffie Hellman behøver du faktisk ikke oprette en symmetrisk nøgle . Begge parter opretter den symmetriske nøgle sammen under nøgleudvekslingen, hvilket er en god sikkerhedsfunktion. Se " Diffie-Hellman Key Exchange " på almindeligt engelsk .

• I min forklaring antog jeg, at du fandt serverens offentlige nøgle, og at du stoler på, at den er den rigtige. Men du skal virkelig være forsigtig med, hvilke offentlige nøgler du tillid. For at have tillid til en offentlig nøgle skal den være signeret digitalt. En underskrevet offentlig nøgle kaldes også et certifikat.

Forhåbentlig rydder dette spørgsmålene om lang adgangskode og offentlige nøgler og har tilstrækkelig information til, at du kan grave dybere på en mere meningsfuld måde.