Pourquoi Firefox est-il si lent sur SSH?


39

J'essaie de lancer Firefox sur SSH en utilisant

ssh -X user@hostname

et alors

firefox -no-remote

mais c'est très très lent.

Comment puis-je réparer cela? Est-ce un problème de connexion?


3
À moins que vous n'ayez un niveau de cryptage extrêmement élevé ou que le serveur sur lequel vous êtes ssh ait une charge de travail élevée, ce n'est probablement pas la partie ssh de l'équation. C'est généralement un problème de bande passante et / ou de latence.
Bratchley

1
Jetez un oeil à ceci: stackoverflow.com/q/12977879/252489
Gowtham

@Gowtham pour que je puisse utiliser: ssh -X -C user @ hostname?
DevOps85

Réponses:


25

Les paramètres ssh par défaut permettent une connexion assez lente. Essayez plutôt ce qui suit:

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

Les options utilisées sont:

-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.

Le point principal ici est d’utiliser un autre chiffrement, dans ce cas-ci, plus rapide que la valeur par défaut, et de compresser les données transférées.


NOTE: Je suis très, très loin d’être un expert en la matière. La commande ci-dessus correspond à ce que j'utilise après l'avoir trouvée quelque part sur un blog et j'ai constaté une nette amélioration de la vitesse. Je suis sûr que les différents intervenants ci-dessous savent de quoi ils parlent et que ces cryptages ne sont peut-être pas les meilleurs. Il est très probable que le seul élément de cette réponse qui soit vraiment pertinent consiste à utiliser le -Ccommutateur pour compresser les données transférées.


11
En fait, en modifiant les paramètres de cryptage, vous pouvez améliorer le débit de la connexion, mais cela n’aura pratiquement aucune influence sur la latence, ce qui ralentit la connexion X-over-ssh ... un fichier plus rapidement, mais le temps nécessaire pour commencer le transfert ne changera pas (presque). C'est le problème du protocole X, il implique beaucoup de messages et d'accusés de réception entre le client et le serveur. Ainsi, sur Internet, le temps de latence de quelques millisecondes est multiplié plusieurs fois jusqu'à ce qu'un bouton change d'état par exemple.
Ariel

8
Est -4(IPv4) vraiment pertinent ici?
Cornstalks

6
Le chiffre "arcfour" est déconseillé, en fait.
Rétablir Monica - M. Schröder

5
La compression aide, mais ne fait pas de miracles. Firefox est très exigeant. Changer le chiffre ne fera probablement pas de différence sauf si l’un des côtés est très limité en temps de calcul: avec les appareils haut de gamme tels que les smartphones et les PC, le temps de cryptage / décryptage est négligeable par rapport à la latence du réseau et à la bande passante.
Gilles 'SO- arrête d'être méchant'

6
Les chiffres suggérés sont la mauvaise façon de faire. Comme le dit Gilles, la majorité des appareils actuels n’auront aucun problème avec le AES-CTR par défaut: c’est très rapide, surtout si le matériel utilisé a le jeu d’instructions AES. Le RC4 est faible et son élimination graduelle sur le réseau, et Blowfish-CBC n’est pas forcément plus rapide que l’AES-CTR.
Reid

32

L'un des plus gros problèmes lors du lancement d'un client X à distance est le protocole X, pas tellement la surcharge ssh! Le protocole X nécessite beaucoup de ping-pong'ing entre le client et le serveur, ce qui tue absolument les performances dans le cas d'applications distantes.

Essayez quelque chose comme "x2go" (qui passe également sur ssh avec les configurations par défaut), vous remarquerez que firefox "vole" en comparaison!

Plusieurs distributions fournissent les packages x2go prêts à l'emploi, par exemple les tests Debian ou Stable-Backports. Mais sinon, voir http://wiki.x2go.org/doku.php/download:start , ils fournissent des packages / référentiels binaires prédéfinis pour de nombreuses distributions. Vous devez installer x2goclient (sur l'ordinateur sur lequel vous voulez "utiliser" firefox) et x2goserver (sur l'ordinateur sur lequel firefox doit être exécuté), vous pouvez ensuite configurer vos sessions pour des applications X uniques ou pour des vues de bureau complètes, etc. La connexion elle-même arrive sur ssh. C'est un outil vraiment merveilleux :)

Pour l'utiliser, vous exécutez "x2goclient", il démarre une interface graphique dans laquelle vous pouvez créer une nouvelle session: vous indiquez le nom DNS du serveur, le port, les données ssh, etc., puis vous sélectionnez le "type de session", c'est-à-dire, si vous voulez un bureau KDE ou GNOME à distance complet, par exemple, ou juste une "application unique" et vous entrez "firefox".


1
comment je peux essayer x2go? la commande
DevOps85

3
Il semble n'y avoir aucun x2goserverpaquet sur Debian (ou Ubuntu). De plus, cela peut-il être configuré pour autoriser le tunneling? Par exemple, j'utilise machineX mais je ne peux y accéder que via machineY. X2go pourrait-il régler ce problème?
terdon

@terdon tu as raison, j'ai vérifié seulement le client. Mais vous pouvez simplement ajouter le référentiel x2go (voir le lien wiki.x2go.org/doku.php/download:start ) et le serveur est là. Je ne sais pas pourquoi seul le client est dans Debian. Tunnelling: bien sûr, c'est possible, mais je ne l'ai jamais essayé. Je pense que cela devrait suffire à configurer ssh ~/.ssh/configet à utiliser le bon nom d’hôte (tunnelé) dans votre session x2go.
Ariel

@terdon: il existe une option "Utiliser un serveur proxy pour la connexion SSH" (ssh / http) dans la configuration de la session x2go. Donc, cela devrait faire l'affaire aussi!
Ariel

Cela semble intéressant, je vais en jouer un peu plus. Jusqu'à présent, je peux confirmer que la configuration du tunnel .ssh/confign'est pas suffisante. Je l'ai configuré pour qu'il ssh machineBpasse réellement par un tunnel machineAmais x2go ne semble pas le voir.
terdon

17

J'ai beaucoup plus d'expérience dans l'utilisation d'un sshtunnel pour acheminer le trafic via une autre machine. C'est très facile à installer puisque vous avez de toute façon un accès SSH. Dans un terminal de votre ordinateur, tapez

ssh -vv -ND 8080 user@yourserver

Laissez cette fenêtre ouverte et regardez-la diffuser des messages détaillés sur les données circulant dans le tunnel.

Dans firefox, allez dans Préférences -> Avancées -> Réseau -> Connexion: Paramètres.

Sélectionnez Configuration manuelle du proxy et ajoutez un SOCKS v5proxy:

 SOCKS Host:   localhost    Port 8080

Vérifiez votre nouvelle adresse IP en accédant par exemple à l' adresse http://whatismyipaddress.com/ .

Vous pouvez utiliser un add-on firefox, tel que le proxy foxy, pour changer de proxy de manière dynamique.


Plus voté, c'est une alternative très valable à l'utilisation de la compression basée sur NX (x2go, etc.), bien plus utile que de bidouiller les paramètres de cryptage ssh :)
Ariel

J'ai toujours utilisé ssh -L 8080: localhost: 8080, mais j'ai bien aimé l'option -ND mais je ne sais pas pourquoi vous avez plutôt utilisé Dinamic ou Remote ou Listen. En passant, utiliser un proxy est bien meilleur que d’utiliser -X, mais je pense que le meilleur moyen est d’utiliser VNC si vous avez besoin de plus de programmes X et pas seulement de Firefox.
m3nda

facile à installer et fonctionne efficacement!
david.perez

2

Firefox est si lent que SSH parce que les nouvelles versions de Firefox autorisent plusieurs instances. Si vous avez des problèmes de bande passante, utilisez un navigateur léger comme dillo et vous ne remarquerez même pas la vitesse de connexion.


Cette réponse provient d' un message posté sur le forum ArchLinux .
Andrew T.

1
cela n'a rien à voir avec le problème - le problème n'est pas le navigateur, mais le protocole distant X11
João Antunes

0

Une autre chose qui améliorera votre navigation sur ssh consiste à activer le traitement en pipeline dans Firefox. Ouvrez about:configet changez network.http.pipeliningen vrai.


Cette option devrait accélérer le chargement des pages Web, mais n'a absolument aucun lien avec le fait que le navigateur fonctionne sur un tunnel SSH ou non. Quoi qu'il en soit, méfiez-vous des "mais" lorsque vous touchez les options avancées ... voir kb.mozillazine.org/Network.http.pipelining
Ariel

D'après mon expérience, la navigation sur ssh devient lente et les requêtes en pipeline sont d'une grande aide, car sinon, une requête donnée doit attendre les requêtes précédentes qui peuvent ou non se terminer à temps, voire pas du tout. Je combine également cela avec le multiplexage SSH. Cela fait une différence notable. Désactiver le traitement en pipeline redevient insupportablement lent dans mon cas.
Tanath

0

Vous devez expérimenter pour voir ce qui vous aide avec vos goulots d'étranglement spécifiques.

Pour moi, permettre à compression ( -C) d’améliorer la réactivité d’un retard inutilisable à juste perceptible.

Le choix du chiffrement peut aussi avoir un impact, contrairement à ce que certaines personnes ont dit. Vous pouvez trouver des personnes partageant des points de repère en ligne, mais ne présumez pas que vos résultats seront les mêmes. Le meilleur chiffre pour vous dépend du matériel. Pour moi, mon chiffre par défaut (chacha20-poly1305@openssh.com) était déjà à égalité pour le plus rapide.

J'ai écrit un script rapide pour comparer les chiffres pertinents dans des conditions assez réalistes. Explications dans les commentaires:

#!/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]

Vous pouvez choisir de tester avec une connexion SSH lorsque le client et l'hôte sont la même machine, ou dans un scénario plus réaliste, où l'hôte est la machine à partir de laquelle vous effectuez le transfert X11, ce qui devrait être plus utile. car les performances dépendent non seulement du déchiffrement des performances du client, mais également de celui de l'hôte.

Tester avec une machine distante peut présenter l'inconvénient d'introduire du bruit si le débit de votre connexion Internet change au cours du test. Dans ce cas, vous voudrez peut-être augmenter le nombre de fois que chaque chiffrement est testé.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.