In SSH, per tutte le classi di algoritmo (crittografia, MAC, scambio di chiavi e autenticazione a chiave pubblica), il client e il server inviano reciprocamente i loro elenchi di algoritmi supportati; le liste dei clienti sono ordinate in base alle preferenze e tale preferenza è rispettata: il protocollo è definito in modo tale che gli algoritmi scelti saranno i primi in ogni elenco di client che appare anche nell'elenco dei server corrispondente.
Ricordo questo punto perché evidenzia ciò che significa questa opzione "avvertire qui sotto". Significa che ci sono alcuni algoritmi che l'utente umano preferirebbe davvero non usare, ma, per qualche ragione, li ha inclusi nella sua lista di algoritmi supportati. Quindi cosa farà effettivamente l'utente umano se riceve l'avviso? Farà clic su "OK, ho capito" e procedere con la connessione? O si libererà? Nel primo caso, gli algoritmi sono così supportati dal punto di vista funzionale, mentre nel secondo non lo sono. Ha davvero senso avere un popup di avvertimento in queste condizioni? Se l'utente non fa altro sull'avvertimento che decidere se continuare a connettersi o interrompere, l'avviso non ha senso; sarebbe più semplice e più sicuro semplicemente omettere dall'elenco tutti gli algoritmi che l'utente non è pronto per usare.
L'avvertimento è utile quando l'utente (sul lato client) può, a un certo punto, modificare la configurazione del server. Può quindi servire da indicatore per un server configurato in modo errato, che l'utente può quindi risolvere da solo in un secondo momento.
Tutto ciò detto, ci sono ragioni per cui alcuni algoritmi sono preferibili agli altri. In nessun ordine particolare:
-
La versione del protocollo dovrebbe essere solo SSH2. SSH1 ha dei difetti, e se il server con cui stai parlando supporta solo SSH1, allora è un software molto vecchio che è probabilmente pieno di vulnerabilità non riconosciute ma note, quindi non vuoi assolutamente connetterti a quel server.
-
DES utilizza una chiave a 56 bit (ufficialmente 64 bit, ma 8 bit vengono ignorati nel processo, quindi efficacemente a 56 bit). Questo è nel raggio di una ricerca esaustiva di aggressori con un po 'di budget (in migliaia di dollari, non in milioni), quindi si vuole davvero evitarlo.
-
RC4 ha pregiudizi noti. SSH può supportare alcune varianti che scartano i primi 1536 byte di uscita RC4, che rimuove i più grandi errori, ma non tutti. Sebbene non sia stato ancora pubblicato alcun utilizzo pratico dei bias RC4 nel contesto di SSH, questa è ancora una preoccupazione e si consiglia di non utilizzare RC4.
-
Blowfish e 3DES sono cifrari a 64 bit. In SSH, vengono utilizzati in modalità CBC, il che significa che iniziano a incontrare problemi dopo aver crittografato circa 2 32 blocchi (di 8 byte ciascuno), ovvero circa 32 gigabyte. Se occasionalmente trasferisci gigabyte di dati su una singola connessione, dovrai evitare i codici a 64 bit e concentrarti sui codici a 128 bit come AES.
-
3DES è lento nel software. Questo può essere importante se hai una rete veloce (gigabit ethernet) o hardware molto lento (non un PC).
-
Se hai la possibilità, preferisci le modalità di crittografia "moderne" come GCM o CTR anziché CBC. La modalità descrive come verrà usato il codice a blocchi.
-
Per lo scambio di chiavi, potresti voler evitare il "gruppo 1" che usa un modulo a 1024 bit. Breaking Diffie-Hellman modulo un primo di 1024 bit non è mai stato fatto in una dimostrazione pubblica (il record corrente è un modulo a 596 bit ) ma è entro la portata tecnologica dell'umanità (il budget previsto sarebbe quindi nelle decine o centinaia di milioni di dollari) . Il "gruppo 14" è un modulo a 2048 bit, che va bene.
-
"Lo scambio di gruppo Diffie-Hellman" è DH nei parametri scelti dal server, e i server normali si prenderanno cura di selezionare parametri che corrispondano almeno alla forza della loro chiave pubblica di autenticazione. Quindi questo è sicuro finché il server (o il suo amministratore) non fa nulla di stupido.
-
Lo scambio di chiavi RSA è piuttosto raro, perché implica la generazione di una coppia di chiavi RSA effimere sul lato server, che è relativamente costosa. I server abituali non lo fanno.
Quindi il mio consiglio sarebbe: rimuovere tutti i cifrari simmetrici che non sono AES; mantenere solo il gruppo DH 14 e lo "Scambio gruppo DH"; non preoccuparti del limite "warn me"; al contrario, utilizzare l'errore per connettersi come avviso. Se non riesci a connetterti a un dato server con parametri sani, allora qualcosa non va e devi metterti in pausa e pensare: un aborto forzato ti fa pensare più di un semplice popup di avvertimento. Forse la mancanza di supporto AES per un determinato server è normale, ma ciò richiede una decisione esplicita, non un popup che è facile da ignorare.