En SSH, para todas las clases de algoritmos (cifrado, MAC, intercambio de claves y autenticación de clave pública), el cliente y el servidor se envían mutuamente sus listas de algoritmos compatibles; las listas de clientes están ordenadas por preferencia, y esa preferencia se respeta: el protocolo está definido de tal manera que los algoritmos elegidos serán los primeros en cada lista de clientes que también aparezcan en la lista de servidores correspondiente.
Recuerdo ese punto porque resalta lo que realmente significa esta opción de "advertir aquí abajo". Significa que hay algunos algoritmos que el usuario humano realmente preferiría no usar, pero, por alguna razón, los incluyó en su lista de algoritmos compatibles. Entonces, ¿qué hará realmente el usuario humano si recibe la advertencia? ¿Hará clic en "OK, lo tengo" y continuará con la conexión? ¿O se va a rescatar? En el primer caso, los algoritmos son así funcionalmente compatibles, mientras que en el segundo no lo son. ¿Realmente tiene sentido tener una ventana emergente de advertencia en estas condiciones? Si el usuario no hace nada más acerca de la advertencia que decidir si seguir conectándose o abortar, entonces la advertencia carece de sentido; Sería más simple y seguro omitir de la lista todos los algoritmos que el usuario no está listo para usar.
La advertencia es útil cuando el usuario (en el lado del cliente) puede, en algún momento, alterar la configuración del servidor. Luego puede servir como un indicador para un servidor mal configurado, que el usuario puede arreglarse en un momento posterior.
Dicho todo esto, hay razones por las que algunos algoritmos son preferibles a otros. En ningún orden en particular:
-
La versión del protocolo debe ser solo SSH2. SSH1 tiene fallas, y si el servidor con el que está tratando de hablar solo es compatible con SSH1, entonces es un software muy antiguo el que probablemente está plagado de vulnerabilidades no fijadas pero conocidas, por lo que realmente no desea conectarse a ese servidor en absoluto.
-
El DES utiliza una clave de 56 bits (oficialmente 64 bits, pero 8 bits se ignoran en el proceso, por lo que efectivamente 56 bits). Esto está dentro del rango de búsqueda exhaustiva por parte de atacantes con un poco de presupuesto (en miles de dólares, no en millones), por lo que realmente desea evitar eso.
-
RC4 tiene sesgos conocidos. SSH puede admitir algunas variantes que descartan los primeros 1536 bytes de la salida RC4, lo que elimina los sesgos más grandes, pero no todos. Si bien aún no se ha publicado ninguna explotación práctica de los sesgos de RC4 en el contexto de SSH, esto sigue siendo una preocupación y se recomienda no usar RC4.
-
Blowfish y 3DES son cifrados de bloque de 64 bits. En SSH, se usan en el modo CBC, lo que significa que comienzan a tener problemas después de cifrar unos 2 32 bloques (de 8 bytes cada uno), es decir, unos 32 gigabytes. Si transfiere ocasionalmente gigabytes de datos a través de una sola conexión, entonces querrá evitar los cifrados de bloque de 64 bits y concentrarse en los cifrados de bloque de 128 bits como AES.
-
3DES es lento en software. Esto puede ser importante si tiene una red rápida (Gigabit Ethernet) o un hardware muy lento (no una PC).
-
Si tiene la opción, prefiera los modos de encriptación "modernos" como GCM o CTR en lugar de CBC. El modo describe cómo se usará el cifrado de bloque.
-
Para el intercambio de claves, es posible que desee evitar el "grupo 1" que utiliza un módulo de 1024 bits. Nunca se ha hecho romper el módulo Diffie-Hellman a 1024-prime en una demostración pública (el registro actual es un módulo de 596 bits ) pero está dentro del alcance tecnológico de la humanidad (el presupuesto proyectado estaría en decenas o cientos de millones de dólares) . El "grupo 14" es un módulo de 2048 bits, que está bien.
-
"El intercambio de grupo Diffie-Hellman" es DH en los parámetros elegidos por el servidor, y los servidores normales se ocuparán de seleccionar los parámetros que al menos coincidan con la fuerza de su clave pública de autenticación. Así que esto es seguro siempre y cuando el servidor (o su administrador) no haga nada estúpido.
-
El intercambio de claves RSA es bastante raro, porque implica generar un par de claves RSA efímeras en el lado del servidor, que es relativamente caro. Los servidores habituales no hacen eso.
Así que mi consejo sería: eliminar todos los cifrados simétricos que no sean AES; mantener solo el grupo 14 de DH y el "intercambio de grupo de DH"; no te molestes con el límite de "adviérteme"; en su lugar, use la falla para conectarse como una advertencia. Si no puede conectarse a un servidor determinado con parámetros sanos, entonces algo anda mal y debe hacer una pausa y pensar: es más probable que una cancelación forzada le haga pensar que una simple ventana emergente de advertencia. Tal vez la falta de soporte de AES para un servidor dado sea normal, pero esto requiere una decisión explícita, no una ventana emergente que sea fácil de ignorar.