¿Por qué Firefox es tan lento sobre SSH?


39

Intento iniciar Firefox sobre SSH, usando

ssh -X user@hostname

y entonces

firefox -no-remote

pero es muy muy lento

¿Cómo puedo arreglar esto? ¿Es un problema de conexión?


3
A menos que tenga un nivel increíblemente alto de encriptación o que el servidor en el que está trabajando tenga una carga alta, probablemente no sea la parte ssh de la ecuación. Por lo general, es un problema de ancho de banda y / o latencia.
Bratchley

1
Eche un vistazo a esto: stackoverflow.com/q/12977879/252489
Gowtham

@Gowtham para poder usar: ssh -X -C user @ hostname?
DevOps85

Respuestas:


25

La configuración predeterminada de ssh permite una conexión bastante lenta. Pruebe lo siguiente en su lugar:

ssh -YC4c arcfour,blowfish-cbc user@hostname firefox -no-remote

Las opciones utilizadas son:

-Y      Enables trusted X11 forwarding.  Trusted X11 forwardings are not
         subjected to the X11 SECURITY extension controls.
 -C      Requests compression of all data (including stdin, stdout,
         stderr, and data for forwarded X11 and TCP connections).  The
         compression algorithm is the same used by gzip(1), and the
         “level” can be controlled by the CompressionLevel option for pro‐
         tocol version 1.  Compression is desirable on modem lines and
         other slow connections, but will only slow down things on fast
         networks.  The default value can be set on a host-by-host basis
         in the configuration files; see the Compression option.
 -4      Forces ssh to use IPv4 addresses only.
 -c cipher_spec
         Selects the cipher specification for encrypting the session.

         For protocol version 2, cipher_spec is a comma-separated list of
         ciphers listed in order of preference.  See the Ciphers keyword
         in ssh_config(5) for more information.

El punto principal aquí es usar un cifrado de cifrado diferente, en este caso un arco que es más rápido que el predeterminado, y comprimir los datos que se transfieren.


NOTA: Estoy muy, muy lejos de ser un experto en esto. El comando anterior es el que uso después de encontrarlo en una publicación de blog en algún lugar y he notado una gran mejora en la velocidad. Estoy seguro de que los diferentes comentaristas a continuación saben de lo que están hablando y que estos cifrados pueden no ser los mejores. Es muy probable que la única parte de esta respuesta que sea verdaderamente relevante sea usar el -Cinterruptor para comprimir los datos que se transfieren.


11
En realidad, al cambiar la configuración de cifrado puede mejorar el rendimiento de la conexión, pero eso casi no tendrá influencia en la latencia, que es lo que hace que la conexión X-over-ssh sea tan lenta ... O dicho de otro modo: puede lograr transferir un archivo más rápido, pero el tiempo que lleva comenzar a transferir no cambiará (casi). Ese es el problema del protocolo X, implica una gran cantidad de mensajes y reconocimientos entre el cliente y el servidor, por lo que a través de Internet, la latencia de pocos milisegundos se multiplica muchas veces hasta que pueda ver un botón cambiar su estado, por ejemplo.
Ariel

8
¿Es -4(IPv4) realmente relevante aquí?
Cornstalks

66
El cifrado 'arcfour "está en desuso, por cierto.
Restablecer Mónica - M. Schröder

55
La compresión ayuda, pero no hace milagros. Firefox es muy exigente. Es poco probable que cambiar el cifrado marque la diferencia a menos que uno de los lados tenga un tiempo de CPU muy limitado: con dispositivos de alta gama como teléfonos inteligentes y PC, el tiempo de cifrado / descifrado es insignificante en comparación con la latencia de red y el ancho de banda.
Gilles 'SO- deja de ser malvado'

66
Las cifras sugeridas son el camino equivocado . Como dice Gilles, la mayoría de los dispositivos en estos días no tendrán ningún problema con el AES-CTR predeterminado: es muy rápido, especialmente si el hardware utilizado tiene el conjunto de instrucciones AES. RC4 es débil y se está eliminando gradualmente a través de la red, y Blowfish-CBC puede no ser necesariamente más rápido que AES-CTR de todos modos.
Reid

32

Uno de los mayores problemas cuando se inicia un cliente X de forma remota es el protocolo X, ¡no tanto la sobrecarga ssh! El protocolo X requiere mucho ping-pong entre el cliente y el servidor, lo que mata absolutamente el rendimiento en el caso de aplicaciones remotas.

Pruebe algo como "x2go" (que también pasa por ssh con las configuraciones predeterminadas) y notará que firefox "vuela" en comparación.

Varias distribuciones proporcionan los paquetes x2go listos para usar, por ejemplo, pruebas de Debian o en Stable-Backports. Pero si no, consulte http://wiki.x2go.org/doku.php/download:start , que proporcionan paquetes / repositorios binarios preconstruidos para muchas distribuciones. Debe instalar x2goclient (en la computadora donde desea 'usar' firefox) y x2goserver (en la computadora donde debería estar funcionando firefox), luego puede configurar sus sesiones para aplicaciones X individuales para vistas de escritorio completas, etc. La conexión en sí sucede sobre ssh. Es una herramienta realmente maravillosa :)

Para usarlo, ejecuta "x2goclient", inicia una GUI donde puede crear una nueva sesión: proporciona el nombre DNS del servidor, puerto, datos ssh, etc. y luego selecciona el "tipo de sesión", es decir, si desea un escritorio KDE o GNOME remoto completo, por ejemplo, o simplemente una "aplicación única" y allí ingresa "firefox".


1
¿Cómo puedo probar x2go? el comando
DevOps85

3
Parece que no hay x2goserverpaquete en Debian (o Ubuntu). Además, ¿se puede configurar para permitir la tunelización? Por ejemplo, uso machineX pero solo puedo enviarlo a través de machineY. ¿Podría x2go lidiar con eso?
terdon

@terdon tienes razón, revisé solo al cliente. Pero solo puede agregar el repositorio x2go (vea el enlace wiki.x2go.org/doku.php/download:start ) y el servidor está allí. No sé por qué solo el cliente está en Debian. Túnel: seguro que es posible, pero nunca lo probé. Espero que sea suficiente con configurar ssh ~/.ssh/configy usar el nombre de host correcto (tunelizado) en su sesión de x2go.
Ariel

@terdon: hay una opción "Usar servidor proxy para la conexión SSH" (ssh / http) en la configuración de la sesión x2go. ¡Entonces eso debería hacer el truco también!
Ariel

Esto parece interesante, jugaré con él un poco más. Hasta ahora puedo confirmar que configurar el túnel .ssh/configno es suficiente. Lo tengo configurado para que ssh machineBrealmente se ejecute a través de un túnel, machineApero x2go no parece verlo.
terdon

17

Tengo mucha mejor experiencia en el uso de un sshtúnel para enrutar el tráfico a través de otra máquina. Es muy fácil de configurar ya que tiene acceso ssh de todos modos. En una terminal de su computadora, escriba

ssh -vv -ND 8080 user@yourserver

Mantenga esta ventana abierta y mírela entregando algunos mensajes detallados sobre los datos que fluyen a través del túnel.

En firefox, vaya a Preferencias -> Avanzado -> Red -> Conexión: Configuración.

Seleccione Configuración manual del proxy y agregue un SOCKS v5proxy:

 SOCKS Host:   localhost    Port 8080

Verifique su nueva IP navegando a, por ejemplo, http://whatismyipaddress.com/ .

Puede usar un complemento de Firefox como proxy proxy para cambiar dinámicamente los servidores proxy.


Votado, esta es una alternativa muy válida para usar la compresión basada en NX (x2go, etc.), mucho más útil que jugar con la configuración de cifrado ssh :)
Ariel

Siempre usé ssh -L 8080: localhost: 8080, pero me gustó la opción -ND pero no estoy seguro de por qué usaste Dinamic en su lugar o Remote o Listen. Por cierto, usar proxy es mucho mejor que usar -X, pero creo que la mejor manera es usar VNC si necesita más programas X y no solo Firefox.
m3nda

fácil de configurar y funciona de manera eficiente!
david.perez

2

Firefox es tan lento sobre SSH porque las nuevas versiones de firefox permiten múltiples instancias. Si tiene problemas de ancho de banda, use un navegador ligero como dillo y ni siquiera notará la velocidad de conexión.



1
esto no tiene nada que ver con el problema: el problema no es el navegador sino el protocolo remoto X11
João Antunes

0

Otra cosa que mejorará su navegación a través de ssh es habilitar la canalización en Firefox. Abrir about:configy cambiar network.http.pipelininga verdadero.


Esa opción debería acelerar la carga de las páginas web, pero no tiene ninguna relación con el hecho de que el navegador se ejecuta en un túnel SSH o no. De todos modos, tenga cuidado con los "pero" cuando toque las opciones avanzadas ... vea kb.mozillazine.org/Network.http.pipelining
Ariel

En mi experiencia, la navegación por ssh se vuelve lenta y las solicitudes de canalización son de gran ayuda, ya que de lo contrario cualquier solicitud tiene que esperar las solicitudes anteriores que pueden completarse o no de manera oportuna. También combino esto con multiplexación ssh. Hace una notable diferencia. Desactivar la canalización vuelve a ser insoportablemente lento en mi caso.
Tanath

0

Tienes que experimentar para ver qué ayuda con tus cuellos de botella específicos.

Para mí, habilitar la compresión ( -C) mejoró la capacidad de respuesta de un retraso inutilizable a solo notable.

La elección del cifrado también puede tener un impacto, contrario a lo que dicen algunas personas. Puedes encontrar personas que comparten puntos de referencia en línea, pero no presumas que tus resultados serán los mismos. Cuál es el mejor cifrado para usted depende del hardware. Para mí, mi cifrado predeterminado (chacha20-poly1305@openssh.com) ya estaba vinculado al más rápido.

Escribí un guión rápido para comparar las cifras relevantes en condiciones algo realistas. Explicaciones en los comentarios:

#!/usr/bin/bash

# Ciphers available to you depends on the intersection of ciphers compiled 
# into your client and the ciphers compiled into your host.
# Should be manually copied from "Ciphers:" section in your `man ssh_config`
# The script will try all ciphers specified here and will gracefully skip
# ciphers unavailable in the host.
#ciphers=""
# Example:
ciphers="3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com chacha20-poly1305@openssh.com"

tmp_file=tmp.bin

# Recommend to use an identity file without a passphrase.
# That way you won't have to retype the password at each iteration.
ssh_identity_file=~/.ssh/tmp_id_no_passphrase

ssh_host="user@host"

# Size of test file, before encryption.
test_file_size_megabytes=8

# Only create test file if it doesn't yet exists.
# Doesn't check if relevant variables changed, so you'll have to delete
# the $tmp_file to regenerate it.
if test ! -f $tmp_file; then
  echo "Creating random data file" \
    "(size $test_file_size_megabytes MB): $tmp_file"

  # Not the same format as the ssh ciphers.
  # Can be left as is, unless this cipher is not supported by your openssl.
  tmp_file_cipher=aes-128-cbc

  # The purpose of encrypting the $tmp_file is to make it uncompressable.
  # I do not know if that is a concern in this scenario,
  # but better safe than sorry.

  dd if=/dev/zero bs=1M count=$test_file_size_megabytes \
    | openssl enc -$tmp_file_cipher -pass pass:123 \
    > $tmp_file
fi

for cipher in $ciphers ; do
  # Benchmark each $cipher multiple times
  for i in 1 2 3 ; do
    echo
    echo "Cipher: $cipher (try $i)"
    # Time piping the $tmp_file via SSH to $ssh_host using $cipher.
    # At destination received data is discarded.
    cat $tmp_file \
      | /usr/bin/time -p \
      ssh -i $ssh_identity_file -c "$cipher" $ssh_host 'cat > /dev/null'
  done
done

# Sample output:

# Creating random data file (size 8 MB): tmp.bin
# *** WARNING : deprecated key derivation used.                                   Using -iter or -pbkdf2 would be better.                                         8+0 records in
# 8+0 records out
# 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0567188 s, 148 MB/s

## [redacted]

# Cipher: aes256-cbc (try 3)
# Unable to negotiate with 192.168.99.99 port 22: no matching cipher found. Their offer: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
# real 0.12
# user 0.03
# sys 0.03

# Cipher: aes128-ctr (try 1)
# real 9.68
# user 0.28
# sys 0.51

# Cipher: aes128-ctr (try 2)
# real 10.85
# user 0.26
# sys 0.29

## [redacted]

Puede elegir probar con una conexión SSH donde el cliente y el host son la misma máquina, o puede probar en un escenario más realista, donde el host es la máquina desde la que realiza el reenvío X11, lo que debería ser más útil, porque el rendimiento no solo depende del descifrado del rendimiento del cliente, sino también del host.

Las pruebas con una máquina remota pueden tener la desventaja de introducir ruido si el rendimiento de su conexión a Internet cambia en el transcurso del punto de referencia. En ese caso, es posible que desee aumentar la cantidad de veces que se prueba cada cifrado.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.