Come funzionano le chiavi SSH? [duplicare]

Basically, what makes it better then a really long password?

Non vengono trasferiti sul server (poiché anche la password molto lunga deve essere trasferita). Non è insicuro nel caso ssh (il canale è crittografato a meno che non si utilizzino cifrature spezzate), ma in teoria può essere intercettato da Man Nel mezzo o malintenzionato (super) utente sul server remoto.

And how does the public key play into things?

Questo è il punto della crittografia asimmetrica. La chiave privata crea la firma e il pubblico può verificare che la firma sia stata effettuata dalla rispettiva chiave pubblica. Si invia la chiave pubblica e la firma dei dati offerti dal server e questo è sufficiente per consentire al server l'accesso (se la chiave pubblica corrisponde a quella in authorized_keys ).

Non sono sicuro di cosa stai confrontando SSH con la "password molto lunga". SSH fornisce un mezzo sicuro per inviare login e password dell'utente a un server remoto. Oppure puoi usare la chiave pubblica di un cliente. Le chiavi asimmetriche sono generalmente più difficili da rompere perché non sono soggette agli utenti che creano password errate. L'autenticazione basata su chiave pubblica è preferita per questo motivo. Puoi white-list specifiche chiavi pubbliche per il tuo utente (e IP) in modo che non tutti possano accedere con il tuo nome utente e da qualsiasi computer. Questa lista bianca è contenuta in /home/<user>/.ssh/authorized_keys .

Nozioni di base su SSH:

1. Il server presenta la sua chiave pubblica RSA al client. Il cliente verifica manualmente che si tratti di questa chiave prima di continuare.

2. SSH utilizza Diffie Hellman per stabilire un valore segreto condiviso.

3. Il segreto condiviso insieme a molti dati di scambio chiave viene sottoposto a hash insieme e firmato utilizzando la chiave privata del server.

4. Il client può verificare questa firma utilizzando il server in precedenza chiave pubblica attendibile.

5. Entrambe le parti ora hanno tutte le informazioni necessarie per generare una sessione chiavi.

Dalla sezione 7.2 di 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.

Una volta stabilito il canale crittografato, il protocollo SSH inizia l'autenticazione del client in base ai parametri che gli hai fornito. Tutto questo viene eseguito in modo sicuro attraverso il canale crittografato.

Consentitemi di fornire un'immagine di alto livello. Chiaramente, comprendi la necessità di comunicazioni sicure, che si tratti di SSH o HTTPS. Comunicazioni sicure significa che il canale è crittografato.

In generale, tutti gli algoritmi di crittografia rientrano in una delle due categorie:

• Crittografia simmetrica. Una chiave. La stessa chiave viene utilizzata per crittografare e decrittografare. Veloce. Per esempio. AES.
• Crittografia asimmetrica. Due chiavi O può essere usato per crittografare, ma solo l'altro può decifrare. Molto più lento degli algoritmi simmetrici. Per esempio. RSA.

La crittografia simmetrica è veloce e quindi adatta per le comunicazioni che coinvolgono molti dati tra due parti. Utilizza la stessa chiave per la crittografia e la decrittografia: questa chiave è analoga al tuo concetto di password molto lunga. Problema: come condividi la tua chiave / password in primo luogo? Si scopre che non è possibile utilizzare un canale sicuro che è costruito esclusivamente su un algoritmo di crittografia simmetrica senza trovare un modo per condividere prima la chiave / password.

È qui che entrano gli algoritmi asimmetrici, ma sono considerevolmente più lenti degli algoritmi simmetrici. Non è pratico trasmettere grandi quantità di dati, ma va bene se si trasmette o si scambia qualcosa di piccolo come una chiave / password di crittografia simmetrica. Fatto ciò, ora puoi utilizzare la crittografia simmetrica per le comunicazioni.

Una delle due chiavi per la crittografia asimmetrica è designata come chiave pubblica e l'altra come chiave privata. La chiave pubblica può essere distribuita a tutti, ma la chiave privata deve essere tenuta segreta.

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

pub = chiave pubblica, prv = chiave privata

In ogni caso questa spiegazione è una semplificazione di ciò che fa effettivamente SSH. Altre due cose da evidenziare:

• Diffie Hellman è il tipico algoritmo asimmetrico di scambio di chiavi. Con Diffie Hellman non hai realmente bisogno di creare una chiave simmetrica. Entrambe le parti creano insieme la chiave simmetrica durante lo scambio di chiavi, che è una buona caratteristica di sicurezza. Vedi "Diffie-Hellman Key Exchange" in inglese semplice .

• Nella mia spiegazione ho presupposto che hai trovato la chiave pubblica del server e che ritieni che sia quella corretta. Ma dovresti davvero stare attento a quali chiavi pubbliche ti fidi. Per fidarsi di una chiave pubblica, dovrebbe essere firmata digitalmente. Una chiave pubblica firmata è anche nota come certificato.

Si spera che questo chiarisca le domande sulla password lunga e sulle chiavi pubbliche e abbia abbastanza informazioni per poter approfondire in modo più significativo.