Warum ist Firefox bei SSH so langsam?


39

Ich versuche mit Firefox über SSH zu starten

ssh -X user@hostname

und dann

firefox -no-remote

aber es ist sehr sehr langsam.

Wie kann ich das beheben? Ist es ein Verbindungsproblem?


3
Es sei denn, Sie haben einen unglaublich hohen Verschlüsselungsgrad oder der Server, auf den Sie zugreifen, ist stark ausgelastet. Dies ist wahrscheinlich nicht der ssh-Teil der Gleichung. Dies ist normalerweise ein Bandbreiten- und / oder Latenzproblem.
Bratchley

1
Schauen Sie sich dies an: stackoverflow.com/q/12977879/252489
Gowtham

@ Gowtham, damit ich verwenden kann: ssh -X -C Benutzer @ Hostname?
DevOps85

Antworten:


25

Die Standard-SSH-Einstellungen sorgen für eine ziemlich langsame Verbindung. Versuchen Sie stattdessen Folgendes:

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

Folgende Optionen werden verwendet:

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

Hier geht es hauptsächlich darum, einen anderen Verschlüsselungscode zu verwenden, in diesem Fall arcfour, der schneller als der Standard ist, und die übertragenen Daten zu komprimieren.


HINWEIS: Ich bin sehr, sehr weit von einem Experten auf diesem Gebiet entfernt. Der obige Befehl wird verwendet, nachdem ich ihn in einem Blog-Post gefunden habe, und ich habe eine enorme Geschwindigkeitsverbesserung festgestellt. Ich bin sicher, dass die verschiedenen Kommentatoren unten wissen, wovon sie sprechen, und dass diese Verschlüsselungs-Chiffren möglicherweise nicht die besten sind. Es ist sehr wahrscheinlich, dass das einzig wirklich relevante Element dieser Antwort die Verwendung des -CSchalters zum Komprimieren der übertragenen Daten ist.


11
Eigentlich können Sie durch Ändern der Verschlüsselungseinstellungen den Durchsatz der Verbindung verbessern , aber das hat fast keinen Einfluss auf die Latenz, die die X-over-ssh-Verbindung so langsam macht ... Oder anders gesagt: Sie können eine Übertragung erzielen Eine Datei ist schneller, aber die Zeit, die zum Starten der Übertragung benötigt wird, ändert sich (fast) nicht. Das ist das Problem des X-Protokolls, es beinhaltet viele Nachrichten und Bestätigungen zwischen dem Client und dem Server, so dass sich über das Internet die Wartezeit von wenigen Millisekunden um ein Vielfaches vervielfacht, bis beispielsweise eine Schaltfläche ihren Status ändert.
Ariel

8
Ist -4(IPv4) hier wirklich relevant?
Cornstalks

6
Die "arcfour" -Verschlüsselung ist übrigens veraltet.
Setzen Sie Monica - M. Schröder

5
Komprimierung hilft, wirkt aber keine Wunder. Firefox ist sehr anspruchsvoll. Es ist unwahrscheinlich, dass die Änderung der Verschlüsselung einen Unterschied macht, es sei denn, eine der Seiten ist in Bezug auf die CPU-Zeit sehr stark eingeschränkt: Bei High-End-Geräten wie Smartphones und PCs ist die Ver- / Entschlüsselungszeit im Vergleich zur Netzwerklatenz und -bandbreite vernachlässigbar.
Gilles 'SO- hör auf, böse zu sein'

6
Die vorgeschlagenen Ziffern sind der falsche Weg. Wie Gilles sagt, wird die Mehrheit der Geräte heutzutage überhaupt kein Problem mit der Standard-AES-CTR haben: Sie ist sehr schnell, insbesondere wenn die verwendete Hardware über den AES-Befehlssatz verfügt. RC4 ist schwach und wird aus dem Netz gestrichen. Blowfish-CBC ist ohnehin nicht unbedingt schneller als AES-CTR.
Reid

32

Eines der größten Probleme beim Starten von X-Clients aus der Ferne ist das X-Protokoll, nicht so sehr der SSH-Aufwand! Das X-Protokoll erfordert viel Ping-Pong zwischen dem Client und dem Server, was die Leistung bei Remoteanwendungen absolut beeinträchtigt.

Versuchen Sie etwas wie "x2go" (das bei Standard-Setups auch über ssh geht), und Sie werden feststellen, dass Firefox im Vergleich "fliegt"!

Verschiedene Distributionen stellen die x2go-Pakete sofort zur Verfügung, zum Beispiel Debian-Tests oder in Stable-Backports. Andernfalls bieten sie unter http://wiki.x2go.org/doku.php/download:start vorgefertigte Binärpakete / -repositorys für viele Distributionen an. Sie sollten x2goclient (auf dem Computer, auf dem Sie Firefox verwenden möchten) und x2goserver (auf dem Firefox ausgeführt werden soll) installieren. Anschließend können Sie Ihre Sitzungen für einzelne X-Anwendungen konfigurieren, um vollständige Desktopansichten usw. zu erhalten. Die Verbindung selbst passiert über ssh. Es ist ein wirklich wundervolles Werkzeug :)

Um es zu benutzen, führen Sie "x2goclient" aus, es startet eine GUI, in der Sie eine neue Sitzung erstellen können: Sie geben den DNS-Namen des Servers, den Port, die SSH-Daten usw. an und wählen dann den "Sitzungstyp", dh wenn Sie möchten beispielsweise einen vollständigen Remote-KDE- oder GNOME-Desktop oder nur eine "einzelne Anwendung" und geben dort "firefox" ein.


1
Wie kann ich x2go ausprobieren? der Befehl
DevOps85

3
Es scheint kein x2goserverPaket auf Debian (oder Ubuntu) zu geben. Kann dies auch so konfiguriert werden, dass Tunneling möglich ist? Ich verwende zum Beispiel machineX, kann aber nur über machineY darauf zugreifen. Könnte x2go damit umgehen?
Terdon

@terdon du hast recht, ich habe nur den Client überprüft. Sie können aber einfach das x2go-Repository hinzufügen (siehe den Link wiki.x2go.org/doku.php/download:start ) und der Server ist da. Ich weiß nicht, warum nur der Client in Debian ist. Tunneln: Natürlich ist es möglich, aber noch nie ausprobiert. Ich würde erwarten, dass es ausreichen sollte, ssh in zu konfigurieren ~/.ssh/configund den richtigen (getunnelten) Hostnamen in Ihrer x2go-Sitzung zu verwenden.
Ariel

@terdon: In der x2go-Sitzungskonfiguration gibt es die Option "Proxyserver für SSH-Verbindung verwenden" (ssh / http). Das sollte also auch reichen!
Ariel

Das scheint interessant, ich werde noch ein bisschen damit spielen. Bisher kann ich bestätigen, dass die Konfiguration des Tunnels .ssh/confignicht ausreicht. Ich habe es so eingestellt, dass es ssh machineBtatsächlich über einen Tunnel durch läuft, machineAaber x2go scheint es nicht zu sehen.
terdon

17

Ich habe viel bessere Erfahrungen mit der Verwendung eines sshTunnels, um den Verkehr durch eine andere Maschine zu leiten. Es ist sehr einfach einzurichten, da Sie sowieso ssh-Zugriff haben. Geben Sie in einem Terminal Ihres Computers Folgendes ein

ssh -vv -ND 8080 user@yourserver

Lassen Sie dieses Fenster geöffnet und beobachten Sie, wie es einige ausführliche Nachrichten über die durch den Tunnel fließenden Daten liefert.

In finden firefoxSie unter Einstellungen -> Erweitert -> Netzwerk -> Verbindung: Einstellungen.

Wählen Sie Manuelle Proxy-Konfiguration und fügen Sie einen SOCKS v5Proxy hinzu:

 SOCKS Host:   localhost    Port 8080

Überprüfen Sie Ihre neue IP-Adresse, indem Sie beispielsweise zu http://whatismyipaddress.com/ navigieren .

Sie können ein Firefox-Add-On wie einen Proxy-Proxy verwenden , um den Proxy-Server dynamisch zu wechseln.


Upvoted, dies ist eine sehr gültige Alternative zur Verwendung von NX-basierter Komprimierung (x2go usw.), viel nützlicher als mit SSH-Verschlüsselungseinstellungen
Ariel

Ich habe immer ssh -L 8080 verwendet: localhost: 8080, aber die Option -ND hat mir gefallen, aber ich bin mir nicht sicher, warum Sie Dinamic oder Remote oder Listen verwendet haben. Übrigens ist die Verwendung von Proxy viel besser als die Verwendung von -X, aber ich denke, der bessere Weg ist die Verwendung von VNC, wenn Sie mehr X-Programme benötigen und nicht nur Firefox.
erm3nda

einfach einzurichten und arbeitet effizient!
david.perez

2

Firefox ist über SSH so langsam, weil neuere Firefox-Builds mehrere Instanzen ermöglichen. Wenn Sie Bandbreitenprobleme haben, verwenden Sie einen leichten Browser wie dillo und Sie werden die Verbindungsgeschwindigkeit nicht einmal bemerken.


Diese Antwort stammt aus einem Beitrag im ArchLinux-Forum .
Andrew T.

1
Dies hat nichts mit dem Problem zu tun - das Problem ist nicht der Browser, sondern das X11-Remote-Protokoll
João Antunes

0

Eine andere Sache, die Ihr Surfen über ssh verbessert, ist das Aktivieren von Pipelining in Firefox. Öffnen Sie about:configund ändern Sie network.http.pipeliningauf true.


Diese Option sollte das Laden von Webseiten beschleunigen, hat jedoch nichts mit der Tatsache zu tun, dass der Browser über einen SSH-Tunnel läuft oder nicht. Achten
Ariel

Meiner Erfahrung nach wird das Durchsuchen von ssh langsam und Pipelining-Anfragen sind eine große Hilfe, da ansonsten jede Anfrage auf frühere Anfragen warten muss, die möglicherweise zeitnah oder gar nicht abgeschlossen werden. Ich kombiniere dies auch mit ssh-Multiplexing. Das macht sich bemerkbar. Das Ausschalten der Pipeline ist in meinem Fall wieder unerträglich langsam.
Tanath

0

Sie müssen experimentieren, um zu sehen, was bei Ihren spezifischen Engpässen hilft.

Für mich hat die Aktivierung von compression ( -C) die Reaktionsfähigkeit von unbrauchbar auf nur merklich verzögert.

Die Wahl der Chiffre kann auch einen Einfluss haben, im Gegensatz zu dem, was einige Leute gesagt haben. Sie können Leute finden, die Benchmarks online teilen, aber nicht davon ausgehen, dass Ihre Ergebnisse gleich sind. Welche Verschlüsselung für Sie am besten geeignet ist, hängt von der Hardware ab. Für mich war meine Standard-Chiffre (chacha20-poly1305@openssh.com) bereits für die schnellste gebunden.

Ich habe ein schnelles Skript geschrieben, um relevante Chiffren unter etwas realistischen Bedingungen zu bewerten. Erläuterungen in den Kommentaren:

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

Sie können wählen, ob Sie mit einer SSH-Verbindung testen möchten, bei der sich Client und Host auf demselben Computer befinden, oder in einem realistischeren Szenario, bei dem der Host der Computer ist, von dem aus Sie die X11-Weiterleitung durchführen. Denn die Leistung hängt nicht nur von der Leistungsentschlüsselung des Clients ab, sondern auch von der Leistung des Hosts.

Das Testen mit einem Remote-Computer kann den Nachteil haben, dass Geräusche auftreten, wenn sich der Durchsatz Ihrer Internetverbindung im Verlauf des Benchmarks ändert. In diesem Fall möchten Sie möglicherweise die Häufigkeit erhöhen, mit der jede Chiffre getestet wird.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.