Con SSH che utilizza l'autenticazione della chiave pubblica RSA, un utente malintenzionato può falsificare l'indirizzo IP del server e connettersi con il client per ottenere la password del client?
Con SSH che utilizza l'autenticazione della chiave pubblica RSA, un utente malintenzionato può falsificare l'indirizzo IP del server e connettersi con il client per ottenere la password del client?
Ci sarà sempre un problema di pollo e uova - come ti fidi della chiave ssh del server a cui ti stai connettendo se non ti sei mai collegato prima. Alcuni siti pubblicano elenchi di tutte le loro chiavi SSH, alcuni vanno oltre e firmano PGP, ma tutto alla fine torna al vecchio problema di distribuzione della fiducia.
L'ultimo e più promettente approccio è pubblicare le impronte digitali SSH per i server nei record DNS che vengono poi firmati utilizzando DNSSec. Per esempio:.
$ dig +short -t sshfp fedorapeople.org
2 1 9EB13E6BEE80F5D56B4E9A029DC53CF00EF14045
1 1 5829B0460C2E9296BDBD835416C2615DCF80D22A
Puoi quindi aggiungere quanto segue al tuo ~ / .ssh / config
VerifyHostKeyDNS yes
Devi configurare anche DNSSec sul tuo resolver per fare la differenza.
Se il client conosce l'impronta digitale del server a cui si connettono o sa che il certificato deve essere firmato da una CA attendibile, allora non sono a conoscenza di SSH o SSH2 vulnerabili a un utente nel mezzo in cui il client pensa che si stiano connettendo a un server errato dopo la connessione precedente. Ciò che è possibile su SSH1 è che un server diventi masquerade come un utente che si è connesso a loro quando accede a un altro server.
Leggi altre domande sui tag ssh man-in-the-middle ip-spoofing known-vulnerabilities