¿Taxonomía de cifrados / MAC / Kex disponible en SSH?

Una respuesta alternativa a lo anterior es que si está preocupado por la seguridad, entonces centrarse en los algoritmos es en gran medida irrelevante, ya que lo que se obtendrá es a través de un error de implementación en su servidor SSH, no a través de alguien que ataque al criptográfico. En particular, si estás haciendo algo como VPN en casa desde DEFCON, entonces debes defenderte de las metasploit, no de un DES-cracker. Podría usar el algoritmo más débil que SSH normalmente admite, un solo DES, y estar perfectamente seguro, porque lo que obtendrá es un 0day en OpenSSH o, si no está ejecutando la última versión, simplemente eso. Entonces realmente estás haciendo la pregunta incorrecta, casi cualquier algoritmo te mantendrá seguro, son los errores de implementación donde te atrapan.

Es poco probable que su elección de cifrado haga una diferencia en el rendimiento de SSH. En la mayoría de los casos, su CPU puede cifrar / descifrar más rápido de lo que su red puede mantener. En la mayoría de las situaciones, el ancho de banda de la red parece ser el factor limitante.

Por lo tanto, sugiero que simplemente deje SSH en sus valores predeterminados. Están bien. Los valores predeterminados son razonablemente seguros y no es probable que la modificación de los valores predeterminados proporcione un rendimiento notablemente mejor.

Si realmente quieres jugar con los parámetros, puedes verificar el uso de compresión de SSH. De forma predeterminada, todos los datos se comprimirán antes de enviarlos a través del canal cifrado. Puede ajustar el nivel de compresión con ssh -o 'CompressionLevel 6' (reemplace 6 con cualquier número del 1 al 9, 1 es el más rápido, 9 es el más lento). Sin embargo, personalmente, no he encontrado ganancias significativas al cambiar el nivel de compresión. Además, si está transfiriendo un archivo que ya está comprimido con scp, puede desactivar la compresión con scp -o 'Compression no' ... . En algunos casos (donde tiene una red muy rápida y una CPU lenta), esto puede ser de ayuda, aunque en mi experiencia no he encontrado que haya una diferencia lo suficientemente grande como para que valga la pena preocuparse.

Edit 3/20: @Marcin menciona que Blowfish obtuvo un mejor desempeño en sus pruebas. De los sistemas de cifrado admitidos en mi cliente OpenSSH, todos los siguientes deberían proporcionar una seguridad sólida:

            aes128-ctr,aes192-ctr,aes256-ctr
            aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
            aes256-cbc

Lo más probable es que arcfour128 , arcfour256 y arcfour también brinden una seguridad sólida, aunque no son una opción tan conservadora como las otras. No debe usar des , ya que proporciona una seguridad más débil ( 3des está bien). De los algoritmos de código de autenticación de mensajes (MAC) admitidos en mi cliente OpenSSH, todos los siguientes deberían proporcionar una seguridad sólida:

               hmac-md5,hmac-sha1,[email protected],
               hmac-ripemd160,hmac-sha1-96,hmac-md5-96

De los HostKeyAlgorithms admitidos en mi cliente OpenSSH, todas las opciones compatibles ( ssh-rsa , ssh-dss ) están bien y deberían proporcionar una seguridad sólida, siempre y cuando elijas una clave de suficiente longitud. No estoy familiarizado con la opción KexAlgorithms.

En resumen, básicamente todas las opciones criptográficas proporcionadas deberían ser lo suficientemente seguras, excepto que no use des (y si es conservador, puede evitar los cifrados basados en arcfour , aunque esto probablemente sea solo paranoia) .