La selezione di cifratura e mac secondo questo sono in una sorta di ordine in un file di configurazione. Come fanno il client e il server a sapere che stanno utilizzando gli stessi? Queste informazioni sono scambiate all'inizio? Un'altra domanda: SSH v1 vulnerabile agli attacchi MiM? Da quello che ho letto non c'è nessuna autorità di certificazione coinvolta.
Nei primi messaggi tra client e server, entrambi inviano il loro elenco di algoritmi supportati, in ordine di preferenza. Quindi l'algoritmo che verrà utilizzato è il primo nell'elenco dei client che appare anche da qualche parte nell'elenco dei server. Questo è specificato in RFC 4253, sezione 7.1 :
encryption_algorithms
A name-list of acceptable symmetric encryption algorithms (also
known as ciphers) in order of preference. The chosen
encryption algorithm to each direction MUST be the first
algorithm on the client's name-list that is also on the
server's name-list. If there is no such algorithm, both sides
MUST disconnect.
(...)
mac_algorithms
A name-list of acceptable MAC algorithms in order of
preference. The chosen MAC algorithm MUST be the first
algorithm on the client's name-list that is also on the
server's name-list. If there is no such algorithm, both sides
MUST disconnect.
In altre parole, il protocollo è tale che le preferenze del client hanno la precedenza sulle preferenze del server.
Il modello SSH normale (sia per SSH v1 che v2) è che il client ricorda la chiave pubblica del server. Quando il client si connette per la prima volta a un determinato server, il client visualizza l'hash della chiave pubblica del server apparente all'utente; l'utente deve quindi controllare l'hash in relazione ad un valore di riferimento fornito da un amministratore di sistema attendibile (ad esempio, l'utente potrebbe telefonare al sysadmin del server per ottenere il valore hash previsto e confrontare). Il software client quindi ricorderà quella chiave pubblica (ad esempio nel file .ssh/known_hosts ), e ulteriori connessioni controlleranno la chiave del server semplicemente confrontandola con il valore memorizzato.
Questo modello è vulnerabile a MitM solo se l'attaccante agisce durante la primissima connessione, e se l'utente umano è pigro e non controlla il valore hash come dovrebbe (in pratica, il 99% degli utenti umani è pigro).
Questo modello non è cambiato tra SSH v1 e v2. Tuttavia, le moderne implementazioni di SSH v2 anche facoltativamente (ma non comunemente) si dilettano in certificates , consentendo l'uso di un modello basato su CA invece del modello tradizionale sopra illustrato. Non ho ancora visto quel tipo di certificati per SSH realmente usati nella pratica, però.
Leggi altre domande sui tag ssh man-in-the-middle cipher-selection