Client e server SSH che utilizzano l'autenticazione della chiave pubblica / privata, utilizzando lo scambio di chiavi Diffie-Hellman.
Invece di inviare SSH le chiavi pubbliche di autenticazione attraverso il filo, vorrebbe distribuire le chiavi pubbliche e saltare l'invio sulla linea - quindi, il resto del protocollo stesso.
Esiste un'impostazione predefinita in SSH per questo o richiede una modifica più dettagliata?
In SSH:
authorized_keys dell'utente sul server known_hosts dell'utente o accettate manualmente dall'utente alla prima connessione Chiarimenti dai commenti:
Looking for a way that a MITM cannot get a hold of the client public keys and spoof the server as a legitimate client. [] the MITM could still try to send data to the server, as the server thinks he is the real client.
Poteva "provare", ma non avrebbe avuto successo. La chiave pubblica non è un token che si presenta alla parte di autenticazione da abbinare. La chiave pubblica viene utilizzata dal lato di autenticazione per decrittografare il messaggio inviato e crittografato (firmato) dalla parte che viene autenticata, assicurando così che sia crittografato con la chiave privata corrispondente.
La conoscenza di una chiave pubblica non consente di impersonare il titolare della chiave privata corrispondente.
If someone "listening" acquires that clients public RSA key, won't they be able to use it to connect to the server? How would the server know if it is the actual clients RSA public key vs. someone else just using his public key?
Esempio: il server ha tre chiavi pubbliche configurate per l'accesso pubA , pubB , pubC .
B invia un messaggio crittografato con privB . Il server riceve un messaggio crittografato e tenta di decodificarlo utilizzando la chiave pubblica pubA - diventa senza senso. Quindi prova a decodificare il messaggio utilizzando pubB e questa volta ottiene un messaggio valido. Significa che il messaggio è stato crittografato utilizzando privB . L'unica entità che possiede privB è B, quindi il server ha confermato che B è il mittente e concede il permesso di accesso.
Qualcuno crittografa il messaggio iniziale con pubB e lo invia al server. Il server non è in grado di decodificarlo utilizzando pubB (perché ha bisogno di privB , ma solo B possiede privB , non il server).
Qualcuno manda pubB al server, il server non ha idea di cosa sia. Non prevede l'invio di alcuna chiave.
La spiegazione sopra è concettuale, il vero algoritmo di scambio delle chiavi è più complesso in quanto anche il contenuto del messaggio iniziale deve essere stabilito