¿Cómo puedo desactivar el cifrado en openssh?

Tengo problemas de rendimiento con la combinación de openssh (servidor) y masilla (cliente) para usar un proxy web remoto. Me gustaría deshabilitar el cifrado y probar los resultados para ver si marca la diferencia. ¿Cómo puedo hacer eso? ¿Hay algo que pueda modificar en el sshd_config. Soy muy nuevo en openssh.

Cualquier otra idea sería apreciada.

Básicamente configuré mi IE para usar 127.0.0.1 calcetines como proxy. Conecto mi masilla a mi servidor openssh en casa y listo, puedo navegar por Internet a través de eso. Sin embargo, es increíblemente lento a pesar de que sé que tengo una conexión rápida a mi hogar (ftp, por ejemplo, funciona a más de 50Kbytes / seg.

Sin recompilar nada, no se puede hacer hasta donde yo sé. Sin embargo, puede cambiar a ARC4 o Blowfish, que son ridículamente rápidos en hardware moderno.

El MEJOR rendimiento (en lo que respecta a los ciclos de reloj) que puede obtener es agregar

compression no

Puedes hacer esto cambiando

ciphers         aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
                aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
                aes256-cbc,arcfour

a

ciphers         arcfour,blowfish-cbc

Si desea exprimir un poco de rendimiento adicional a riesgo de incompatibilidad, puede cambiar

macs  hmac-md5,hmac-sha1,umac-64@openssh.com,
      hmac-ripemd160,hmac-sha1-96,hmac-md5-96

a

macs  hmac-md5-96

Si aún piensa que esto es demasiado, puede volver a la versión 1 o simplemente hacer una VPN estándar.

A menos que el cliente o el servidor estén drásticamente poco poderosos, dudaría mucho de que sea el cifrado el que esté causando sus problemas de rendimiento. Utilizo regularmente un proxy de calcetines ssh "-D 8080" y nunca he notado nada más que una desaceleración muy leve.

Una cosa que debe verificar es ver cuál es la latencia entre su cliente y el servidor. Si se trata de una conexión muy latente, seguramente vería un bajo rendimiento en el túnel al usar HTTP, sin ver problemas de rendimiento con FTP. Una vez que una transferencia FTP está en progreso, la latencia realmente no importa, pero con HTTP, se trata de páginas web que pueden tener 50 o más apretones de manos HTTP individuales que deben ocurrir. Las conexiones de alta latencia realmente retrasarán este proceso y harán que la navegación sea insoportable.

De todos modos, las recomendaciones que hizo Zephyr Pellerin son sólidas. Si realmente piensa que es el cifrado lo que les está causando el problema por todos los medios, cambie a un cifrado diferente. Sin embargo, sugeriría investigar primero la latencia, ya que parece ser un candidato mucho más probable.

Este hilo me hizo hacer mis propios puntos de referencia y descubrí que el rendimiento varía no solo según el cifrado / MAC diferente, sino que también hace una diferencia en los datos que está enviando, qué CPU están involucrados y cómo se configura la red.

Entonces, en mi opinión, lo correcto es ejecutar sus propias pruebas y encontrar la mejor configuración para su situación.

Si alguien está interesado, aquí están los resultados de mis pruebas que comparan un servidor impulsado por Intel E5506 con una Raspberry Pi:

--
-- Intel Xeon E5506(4 x 2.13 GHz), 50MB Random binary Data over localhost
--

cipher                      mac                        speed
---------------------------------------------------------------
aes192-cbc                  hmac-sha1                    50MB/s
arcfour256                  hmac-sha2-512              49.9MB/s
arcfour                     hmac-ripemd160             49.8MB/s
aes256-cbc                  hmac-sha1-96               49.7MB/s
aes128-cbc                  hmac-sha1-96               49.7MB/s
aes192-cbc                  hmac-sha1                  48.9MB/s
arcfour                     hmac-ripemd160@openssh.com 48.8MB/s
aes256-cbc                  hmac-sha1-96               48.8MB/s
arcfour                     hmac-ripemd160@openssh.com 48.7MB/s
aes128-cbc                  hmac-sha1                  48.4MB/s


--
-- Raspberry PI B+, 10MB Random binary over localhost
--

cipher                      mac                        speed
---------------------------------------------------------------
arcfour256                  umac-64@openssh.com        2.75MB/s
arcfour128                  umac-64@openssh.com        2.74MB/s
arcfour                     umac-64@openssh.com        2.63MB/s
arcfour                     umac-64@openssh.com        2.54MB/s
arcfour                     hmac-md5-96                2.36MB/s
arcfour128                  hmac-md5                   2.34MB/s
arcfour256                  hmac-md5                   2.34MB/s
arcfour256                  umac-64@openssh.com        2.33MB/s
arcfour256                  hmac-md5-96                2.28MB/s
arcfour256                  hmac-md5-96                2.22MB/s

Pero solo en el 'top 10', los resultados completos se pueden encontrar aquí .

Pude compilar sshd / ssh con el cifrado 'none' con la ayuda de esta publicación: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=24559#58

Es una publicación muy antigua, pero debe realizar 3 ligeras modificaciones en el archivo de código fuente cipher.c. Luego, vuelva a compilar el código sshd / ssh.

@@ -175,7 +175,7 @@
    for ((p = strsep(&cp, CIPHER_SEP)); p && *p != '\0';
        (p = strsep(&cp, CIPHER_SEP))) {
        c = cipher_by_name(p);
-       if (c == NULL || c->number != SSH_CIPHER_SSH2) {
+       if (c == NULL || (c->number != SSH_CIPHER_SSH2 && c->number != SSH_CIPHER_NONE)) {
            debug("bad cipher %s [%s]", p, names);
            xfree(ciphers);
            return 0;
@@ -343,6 +343,7 @@
    int evplen;

    switch (c->number) {
+   case SSH_CIPHER_NONE:
    case SSH_CIPHER_SSH2:
    case SSH_CIPHER_DES:
    case SSH_CIPHER_BLOWFISH:
@@ -377,6 +378,7 @@
    int evplen = 0;

    switch (c->number) {
+   case SSH_CIPHER_NONE:
    case SSH_CIPHER_SSH2:
    case SSH_CIPHER_DES:
    case SSH_CIPHER_BLOWFISH:

Además, el nonecifrado deberá agregarse a su/etc/ssh/sshd_config

Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,none

Los enlaces a continuación lo ayudarán a obtener la fuente ssh para los sistemas Debian y Ubuntu:

• /ubuntu//a/345198/54228
• https://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html

Gracias a Dean Gaudet por ser increíble.

De acuerdo con esta muy buena publicación de blog

http://blog.famzah.net/2010/06/11/openssh-ciphers-performance-benchmark/

Recomiendo configurar los siguientes cifrados. También asegúrese de que la compresión esté desactivada si desea el mejor rendimiento en LAN. Tenga en cuenta que este es un posible riesgo de seguridad, use solo en una LAN segura (por ejemplo, en el hogar, etc.)

# cat ~/.ssh/config
Host 192.168.1.*
    Compression no
    Ciphers arcfour256,arcfour128,arcfour,blowfish-cbc,aes128-cbc,aes192-cbc,cast128-cbc,aes256-cbc

Modifique la primera línea para enumerar sus propias IP en su LAN. También puede proporcionar nombres de host (separados por espacio). Esto le brinda el mejor rendimiento scp en LAN.

SI desea probar un túnel sin cifrar y sin comprimir, puede intentar usar algo como rinetdreenviar los datos en lugar de SSH. Esto ilimitaría los extras SSH mientras que todavía ofrece un túnel binario seguro para conexiones TCP.

Cuando dice que tiene una conexión rápida en casa, ¿está seguro de que es rápida en ambas direcciones? Muchas conexiones domésticas son muy asimétricas (por ejemplo, mi ADSL hogareño es ~ 11Mit aguas abajo y ~ 1.5Mbit aguas arriba y muchas son peores que eso, algunas puedo citar las conexiones de amigos / familiares: 7M / 0.4M, 19M / 1.3M, 20M / 0,75 M, ...). Recuerde que si está utilizando su hogar como proxy, los datos deben pasar por su enlace en ambos sentidos, por lo que se moverán en el mejor de los casosa la velocidad más baja de su flujo descendente y ascendente, y también tiene una gran cantidad de latencia adicional. Además, su ISP podría restringir deliberadamente la comunicación ascendente (ya sea de forma general o selectiva para que no se vean afectadas cosas como el correo electrónico y los sitios web populares seleccionados) como una forma de desalentar a las personas que ejecutan servidores / servidores proxy desde sus enlaces de inicio, aunque esto es relativamente raro.

Acabo de hacer pruebas exhaustivas sobre esto, y el conjunto de cifrado que produjo el mayor rendimiento fue aes-128-ctr con umac64 MAC. En una máquina de 4 núcleos a 3,4 GHz, vi casi 900 MB / s a ​​través de localhost (para eliminar los cuellos de botella de la red en aras de la evaluación comparativa)

Si realmente necesita tanto rendimiento, quiere el SSH más nuevo y posiblemente los parches HPN-SSH .

Esta es una opción SSH del lado del cliente que utilicé para la conexión SSH a dispositivos de gama baja:

ssh -c none -m hmac-md5-96 -oKexAlgorithms=curve25519-sha256@libssh.org ....

Ninguna cifra se admite de forma nativa en las versiones recientes de OpenSSH. Sin embargo, desde 7.6, OpenSSH eliminó el soporte SSHv1 y etiquetó el cifrado "none" para uso interno.

#define CFLAG_NONE      (1<<3)
#define CFLAG_INTERNAL      CFLAG_NONE /* Don't use "none" for packets */

Entonces necesita parches y recompilaciones tanto para el servidor como para el cliente.

#define CFLAG_INTERNAL      0