Hur fungerar SSH-nycklar? [duplicera]

Vad gör det egentligen bättre än ett riktigt långt lösenord?

De överförs inte till servern (eftersom till och med det mycket långa lösenordet måste överföras). Det är inte osäkert i fallet ssh (kanalen är krypterad såvida du inte använder trasiga kodningar), men i teorin kan den fångas upp av Man i mitten eller skadlig (super) användare på fjärrservern.

Och hur spelar den offentliga nyckeln in i saker?

Detta är poängen med asymmetrisk kryptografi. Privat nyckel skapar signatur och offentlig kan verifiera att signaturen gjordes av respektive offentlig nyckel. Du skickar den offentliga nyckeln och signaturen för data som erbjuds av servern och det räcker för att servern ska ge dig åtkomst (om den offentliga nyckeln matchar den i authorized_keys).

Kommentarer

• Så den skickar den offentliga nyckeln, om den matchar krypteras data som går tillbaka med den offentliga nyckeln, som den privata nyckeln sedan kan dekryptera ? Och tvärtom med privat kryptering och offentlig dekryptering?
• krypterad med den offentliga nyckeln, som den privata nyckeln sedan kan dekryptera – signerad med privat nyckel, vilken offentlig nyckel kan verifiera.
• Vad betyder " signerad "? Vad förhindrar att något dekrypterar något även om signaturen inte checkar ut?
• @amflare: en.wikipedia.org/wiki/Digital_signature Om något, skulle den framtida dekrypteraren ' sin egen kod.
• Det förstår jag. Därav mitt (tydligen felaktiga) antagande att nycklarna aktiverade kryptering och dekryptering. Men det verkar som om jag var en skadlig part kunde jag fånga upp data och ignorera signaturens äkthet och försöka dekryptera den ändå. Jag hade intrycket av att nycklarna fungerade som ett sätt att också hindra tredje part från att göra det.

Jag är inte säker på vad du jämför SSH med det ”mycket långa lösenordet”. SSH ger ett säkert sätt att skicka din användarinloggning och lösenord till en fjärrserver. Eller så kan du använda en klients offentliga nyckel. Asymmetriska nycklar är vanligtvis svårare att bryta eftersom de inte är föremål för att användare skapar dåliga lösenord. Offentlig nyckelbaserad autentisering är att föredra av den anledningen. Du kan vitlista specifika offentliga nycklar för din användare (och IP) så att inte bara vem som helst kan logga in med ditt användarnamn och från vilken dator som helst. Den här vita listan finns i /home/<user>/.ssh/authorized_keys.

Grunderna i SSH:

1. Servern presenterar sin offentliga RSA-nyckel till Klienten. Klienten verifierar manuellt att den litar på den här nyckeln innan den fortsätter.

2. SSH använder Diffie Hellman för att skapa ett delat hemligt värde.

3. Den delade hemligheten tillsammans med massor av nyckelutbytesdata hashades tillsammans och signerades med hjälp av serverns privata nyckel.

4. Klienten kan verifiera denna signatur med hjälp av serverns tidigare betrodd offentlig nyckel.

5. Båda sidor har nu all information som behövs för att generera sessionsnycklar.

Från avsnitt 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 krypterade kanalen har upprättats börjar SSH-protokollet klientautentiseringsbaserat efter parametrar har du gett det. Allt detta sker säkert genom den krypterade kanalen.

Låt mig ge en bild på hög nivå. Det är uppenbart att du förstår behovet av säker kommunikation, vare sig det är SSH eller HTTPS. Säker kommunikation innebär att kanalen är krypterad.

I allmänhet faller alla krypteringsalgoritmer i en av två kategorier:

• Symmetrisk kryptering. En nyckel. Samma nyckel används för att kryptera och dekryptera. Snabb. T.ex. AES.
• Asymmetrisk kryptering. Två nycklar. Endera kan användas för att kryptera, men bara den andra kan dekryptera. Mycket långsammare än symmetriska algoritmer. T.ex. RSA.

Symmetrisk kryptering är snabb och därför lämplig för kommunikation som involverar mycket data mellan två parter. Den använder samma nyckel för kryptering och dekryptering – den här nyckeln är analog med ditt koncept om ett mycket långt lösenord. Problem: hur delar du din nyckel / lösenord i första hand? Visar sig att du inte kan använda en säker kanal som enbart bygger på en symmetrisk krypteringsalgoritm utan att räkna ut ett sätt att först dela din nyckel / lösenord.

Det är här asymmetriska algoritmer kommer in, men är betydligt långsammare än symmetriska algoritmer. Opraktiskt att överföra stora mängder data, men bra om du överför eller byter ut något litet som en symmetrisk krypteringsnyckel / lösenord. När det väl är gjort kan du nu använda symmetrisk kryptering för kommunikation.

En av de två nycklarna för asymmetrisk kryptering betecknas den offentliga nyckeln och den andra den privata nyckeln. Den offentliga nyckeln kan distribueras till alla, men privat nyckel måste hållas hemlig.

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

pub = offentlig nyckel, prv = privat nyckel

Hur som helst är denna förklaring en Förenkling av vad SSH faktiskt gör. Två andra saker som är värda att belysa:

• Diffie Hellman är den typiska nyckelutbytesasymmetriska algoritmen. Med Diffie Hellman behöver du inte skapa en symmetrisk nyckel . Båda parter skapar den symmetriska nyckeln tillsammans under nyckelutbytet, vilket är en trevlig säkerhetsfunktion. Se " Diffie-Hellman Key Exchange " på vanlig engelska .

• I min förklaring antog jag att du hittade serverns offentliga nyckel, och att du litar på att den är rätt. Men du borde verkligen vara försiktig med vilka offentliga nycklar du För att lita på en offentlig nyckel bör den signeras digitalt. En signerad allmän nyckel kallas också ett certifikat.

Förhoppningsvis rensas det upp frågorna om långt lösenord och offentliga nycklar och har tillräckligt med information för att du ska kunna gräva djupare på ett mer meningsfullt sätt.