Relazione RSA con lo scambio di chiavi SSH

Question

Relazione RSA con lo scambio di chiavi SSH

#1 da (2 voti)

2

Non capisco perfettamente SSH. Speravo che qualcuno potesse sistemare la mia confusione.

Quando generi una coppia di chiavi ssh, crei quattro file.

authorized_keys, id_rsa, id_rsa.pub and known_hosts

La mia confusione deriva dal fatto che RSA è uno strumento di crittografia, si rilascia una coppia di chiavi pubbliche (n, e) ma nel file id_rsa.pub , non c'è una coppia, è solo una stringa gigantesca, dove si divide ?

Inoltre, come SSH crea un controllo della password lato server, RSA viene utilizzato per crittografare i messaggi, come li ha con la mia chiave pubblica, combinando con la mia chiave privata creare una sorta di conferma della password, RSA viene utilizzato per crittografare i messaggi non password autenticazione?

cryptography ssh diffie-hellman rsa

posta J. Doe 09.03.2018 - 00:14

fonte

1 risposta

Leggi altre domande sui tag cryptography ssh diffie-hellman rsa

Aggiungi campo personalizzato al certificato Il codice SQL nativo può essere vulnerabile? A cosa?

score 2 · Accepted Answer

known_hosts non ha nulla a che fare con l'autenticazione della chiave pubblica. È un elenco di server a cui ti sei collegato in passato e le impronte digitali delle loro chiavi SSH per aiutarti a verificare che la connessione al server non sia man-in-the-middled.

authorized_keys è un file memorizzato sul server contenente le chiavi pubbliche SSH degli utenti autorizzati ad accedere al server.

id_rsa è la chiave privata. id_rsa.pub è la chiave pubblica. La chiave pubblica è codificata in base al formato in RFC 4253 , ma fondamentalmente si tratta di un blob codificato PEM che contiene il tipo di chiave, la lunghezza e i valori n e e .

L'autenticazione della chiave pubblica non coinvolge affatto le password. Non c'è affatto un passo di "conferma della password". Quando il client si connette, offre le chiavi che ha sul server. Se il server può utilizzare uno di quelli per la connessione, chiede al client di firmare i metadati relativi alla richiesta, inclusi i dati forniti dal client e dal server. Il client accetta i dati della richiesta, li firma con la chiave privata e li invia di nuovo al server. Il server verifica la firma del blob, che mostra che il client possiede la chiave privata corretta (corrispondente a una delle chiavi pubbliche in authorized_keys ) e concede l'accesso.