Ho problemi a capire come ssh funzioni davvero. So che usa una crittografia a chiave pubblica per crittografare i messaggi. Tuttavia, posso ssh su un server senza prima generare una coppia di chiavi pubblica / privata per me. Ho controllato la mia cartella .ssh e non ci sono file .pub, quindi presumo di non avere una chiave pubblica di cui il server è a conoscenza. Quindi, come può il server mandarmi un messaggio cifrato se non ho la chiave pubblica in primo luogo?
Queste sono in realtà due cose diverse. La coppia di chiavi pubblica / privata di cui parli riguarda l'autenticazione .
Quando ti connetti a un server ssh, il tuo client e il server negoziano le chiavi che usano per la crittografia delle loro comunicazioni. Alcuni algoritmi derivati dallo scambio di chiavi Diffie-Hellmann . Lo stesso metodo viene utilizzato quando accedi a una pagina con il tuo browser tramite il protocollo https.
Se ti interessa il funzionamento interno del protocollo ssh, puoi verificarlo qui . È aperto;)
modifica : Ma sono d'accordo con Dennis, il forum di crittografia è il posto migliore per questo.
Come descrive @klaustopher, il tunnel SSH utilizza uno scambio di chiavi Diffie-Hellman, per stabilire un segreto condiviso tra client e server; questo segreto condiviso viene utilizzato con la crittografia simmetrica per crittografare e verificare l'integrità di tutti i dati scambiati successivamente.
Come se stesso, DH + crypto simmetrico va bene, ma fa solo metà del lavoro. Quando il protocollo DH è stato eseguito, sia il client che il server sanno che ora hanno un tunnel sicuro con ... qualcuno. Ma loro non sanno chi . Sanno solo che questa sarà la stessa entità per tutta la durata della connessione. Quindi questo è vulnerabile agli aggressori attivi che impersonano il client, il server o entrambi. Il famoso attacco Man-in-the-Middle è un caso di doppia imitazione (l'attaccante agisce come server falso quando parla con il cliente e come cliente falso quando parla al server).
Per rendere sicuro un tunnel completamente sicuro per la trasmissione di dati riservati e comandi sensibili, il client e il server devono autenticarsi a vicenda. Nei primi passi del protocollo, il server firma ciò che invia (la sua metà del protocollo Diffie-Hellman); il client verifica quella firma relativamente alla chiave pubblica del server conosciuto (quella memorizzata dal client in .ssh/known_hosts ). Una volta che la firma è stata verificata, il client sa che sta facendo lo scambio di chiavi DH con il vero server, non con un aggressore che si presenta come il server previsto. Ciò significa che il cliente può inviare in modo sicuro dati riservati attraverso il tunnel. In particolare, una volta che il DH è stato fatto, i primi scambi vanno così:
Grazie all'autenticazione del server da parte del client (tramite l'algoritmo di verifica della firma), il client sa che può tranquillamente inviare la sua password nel tunnel.
Il protocollo SSH anche supporta l'autenticazione del client basata su firma. Il DH e la firma del server sono ancora fatti come in precedenza. Ma il protocollo quindi va così:
.ssh/authorized_keys contiene una chiave pubblica che corrisponde all'id che hai inviato e la tua firma sulla mia sfida si verifica correttamente riguardo a quella chiave pubblica. Benvenuto, Bob. Più o meno la stessa cosa accade con HTTPS. Esistono molte differenze locali, ad es. il client HTTPS riconosce la chiave pubblica del server convalidando un certificato invece di ricordarlo da una visita precedente; e la cosa della password può assumere la forma di pagine Web reali; ma il succo dello scambio è lo stesso: il client si assicura che parli al server giusto verificando la sua chiave pubblica, e quindi il server si assicura che parli con il client giusto (se il server è veramente interessato a sapere < em> chi è il client) eseguendo una sorta di protocollo di autenticazione all'interno del tunnel.
Leggi altre domande sui tag authentication cryptography encryption ssh