Hvordan fungerer SSH-nøkler? [duplikat]

Hva gjør det egentlig bedre enn et veldig langt passord?

De overføres ikke til serveren (ettersom selv det veldig lange passordet må overføres). Det er ikke usikkert i tilfellet ssh (kanalen er kryptert med mindre du bruker ødelagte krypter), men i teorien kan den oppfanges av Man In the middle eller ondsinnet (super) bruker på den eksterne serveren.

Og hvordan spiller den offentlige nøkkelen inn i ting?

Dette er poenget med asymmetrisk kryptografi. Privat nøkkel oppretter signatur og offentlig kan bekrefte at signaturen ble laget av den respektive offentlige nøkkelen. Du sender den offentlige nøkkelen og signaturen til data som tilbys av serveren, og dette er nok til at serveren gir deg tilgang (hvis den offentlige nøkkelen samsvarer med den i authorized_keys).

Kommentarer

• Så den sender den offentlige nøkkelen, hvis den stemmer overens, blir dataene som går tilbake kryptert med den offentlige nøkkelen, som den private nøkkelen deretter kan dekryptere ? Og omvendt med privat kryptering og offentlig dekryptering?
• kryptert med den offentlige nøkkelen, som den private nøkkelen deretter kan dekryptere – signert med privat nøkkel, hvilken offentlig nøkkel kan bekrefte.
• Hva betyr " signert "? Hva forhindrer at noe dekrypterer noe selv om signaturen ikke sjekker ut?
• @amflare: en.wikipedia.org/wiki/Digital_signature Hvis noe, så vil dekrypteren ' sin egen kode.
• Rett, det skjønner jeg. Derav min (tilsynelatende feil) antagelse om at nøklene aktiverte kryptering og dekryptering. Men det virker som om jeg var en ondsinnet part, kunne jeg fange opp dataene og ignorere ektheten til signaturen og prøve å dekryptere den uansett. Jeg var under inntrykk av at nøklene fungerte som et middel til også å hindre tredjeparter i å gjøre det.

Jeg er ikke sikker på hva du sammenligner SSH med det «veldig lange passordet». SSH gir et sikkert middel for å sende brukerinnlogging og passord til en ekstern server. Eller du kan bruke en klients offentlige nøkkel. Asymmetriske nøkler er generelt vanskeligere å bryte fordi de ikke er underlagt at brukere oppretter dårlige passord. Offentlig nøkkelbasert autentisering foretrekkes av den grunn. Du kan hvitliste spesifikke offentlige nøkler for brukeren din (og IP), slik at ikke hvem som helst kan logge inn med brukernavnet ditt og fra hvilken som helst datamaskin. Denne hvite listen finnes i /home/<user>/.ssh/authorized_keys.

Grunnleggende om SSH:

1. Server presenterer sin offentlige RSA-nøkkel til klienten. Klienten bekrefter manuelt at den stoler på denne nøkkelen før han fortsetter.

2. SSH bruker Diffie Hellman til å etablere en delt hemmelig verdi.

3. Den delte hemmeligheten sammen med mange nøkkelutvekslingsdata hashes sammen og signeres ved hjelp av serverens private nøkkel.

4. Klienten kan bekrefte denne signaturen ved hjelp av serverens tidligere klarert offentlig nøkkel.

5. Begge sider har nå all informasjonen som trengs for å generere øktnøkler.

Fra seksjon 7.2 av 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 krypterte kanalen er etablert, starter SSH-protokollen klientautentiseringsbasert på parametere har du gitt den. Alt dette utføres sikkert gjennom den krypterte kanalen.

La meg gi et bilde på høyt nivå. Det er klart at du forstår behovet for sikker kommunikasjon, det være seg SSH eller HTTPS. Sikker kommunikasjon betyr at kanalen er kryptert.

Generelt faller alle krypteringsalgoritmer i en av to kategorier:

• Symmetrisk kryptering. En nøkkel. Samme nøkkel brukes til å kryptere og dekryptere. Fort. F.eks. AES.
• Asymmetrisk kryptering. To nøkler. Enten kan brukes til å kryptere, men bare den andre kan dekryptere. Mye tregere enn symmetriske algoritmer. F.eks. RSA.

Symmetrisk kryptering er rask og egner seg derfor for kommunikasjon som involverer mye data mellom to parter. Den bruker samme nøkkel for kryptering og dekryptering – denne nøkkelen er analog med begrepet ditt om et veldig langt passord. Problem: hvordan deler du nøkkelen / passordet ditt i utgangspunktet? Det viser seg at du ikke kan bruke en sikker kanal som bare er bygget på en symmetrisk krypteringsalgoritme uten å finne ut en måte å først dele nøkkelen / passordet ditt på.

Det er her asymmetriske algoritmer kommer inn, men er betydelig tregere enn symmetriske algoritmer. Praktisk å overføre store mengder data, men greit hvis du overfører eller bytter ut noe lite som en symmetrisk krypteringsnøkkel / passord. Når det er gjort, kan du nå bruke symmetrisk kryptering for kommunikasjon.

En av de to nøklene for asymmetrisk kryptering betegnes som den offentlige nøkkelen og den andre den private nøkkelen. Den offentlige nøkkelen kan distribueres til alle, men privat nøkkel må 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økkel, prv = privat nøkkel

Uansett er denne forklaringen en forenkling av hva SSH faktisk gjør. To andre ting som er verdt å fremheve:

• Diffie Hellman er den typiske nøkkelutvekslingen asymmetrisk algoritme. Med Diffie Hellman trenger du faktisk ikke å lage en symmetrisk nøkkel . Begge parter lager den symmetriske nøkkelen sammen under nøkkelutvekslingen, noe som er en fin sikkerhetsfunksjon. Se " Diffie-Hellman Key Exchange " på vanlig engelsk .

• I min forklaring antok jeg at du fant serverens offentlige nøkkel, og at du stoler på at den er riktig. Men du bør være forsiktig med hvilke offentlige nøkler du tillit. For å stole på en offentlig nøkkel, bør den signeres digitalt. En signert offentlig nøkkel er også kjent som et sertifikat.

Forhåpentligvis rydder dette opp spørsmålene om langt passord og offentlige nøkler, og har nok informasjon til at du kan grave dypere på en mer meningsfull måte.