Mengapa Firefox sangat lambat di SSH?


39

Saya mencoba meluncurkan Firefox melalui SSH, menggunakan

ssh -X user@hostname

lalu

firefox -no-remote

tapi ini sangat lambat.

Bagaimana saya bisa memperbaikinya? Apakah ini masalah koneksi?


3
Kecuali jika Anda memiliki tingkat enkripsi yang sangat tinggi atau server yang Anda gunakan memiliki beban yang tinggi, itu mungkin bukan bagian ssh dari persamaan tersebut. Biasanya masalah bandwidth dan / atau latensi.
Bratchley


@Gowtham jadi saya bisa menggunakan: ssh -X -C user @ hostname?
DevOps85

Jawaban:


25

Pengaturan ssh default membuat koneksi menjadi sangat lambat. Coba yang berikut ini sebagai gantinya:

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

Opsi yang digunakan adalah:

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

Poin utama di sini adalah menggunakan enkripsi cypher yang berbeda, dalam hal ini arcfour yang lebih cepat dari standar, dan untuk memampatkan data yang sedang ditransfer.


CATATAN: Saya sangat, sangat jauh dari ahli dalam hal ini. Perintah di atas adalah apa yang saya gunakan setelah menemukannya di posting blog di suatu tempat dan saya perhatikan peningkatan besar dalam kecepatan. Saya yakin berbagai komentator di bawah ini tahu apa yang mereka bicarakan dan bahwa sandi enkripsi ini mungkin bukan yang terbaik. Sangat mungkin bahwa satu-satunya jawaban yang benar-benar relevan adalah menggunakan -Csakelar untuk mengompres data yang ditransfer.


11
Sebenarnya dengan mengubah pengaturan enkripsi Anda dapat meningkatkan throughput koneksi, tetapi itu hampir tidak memiliki pengaruh pada latensi yang membuat koneksi X-over-ssh begitu lambat ... Atau mengatakan sebaliknya: Anda dapat mencapai untuk mentransfer file lebih cepat, tetapi waktu yang diperlukan untuk mulai mentransfer tidak akan berubah (hampir). Itu adalah masalah protokol-X, itu melibatkan banyak pesan dan ucapan terima kasih antara klien dan server, jadi melalui internet beberapa milidetik latensi dikalikan berkali-kali hingga Anda dapat melihat tombol mengubah statusnya misalnya.
Ariel

8
Apakah -4(IPv4) benar-benar relevan di sini?
Cornstalks

6
Cipher `arcfour" sudah tidak digunakan lagi, btw.
Reinstate Monica - M. Schröder

5
Kompresi membantu, tetapi tidak berhasil mukjizat. Firefox sangat menuntut. Mengubah cipher tidak akan membuat perbedaan kecuali salah satu sisi sangat terbatas dalam waktu CPU: dengan perangkat kelas atas seperti smartphone dan PC, waktu enkripsi / dekripsi diabaikan dibandingkan dengan latensi jaringan dan bandwidth.
Gilles 'SO- berhenti bersikap jahat'

6
Kata sandi yang disarankan adalah cara yang salah . Seperti yang dikatakan Gilles, sebagian besar perangkat saat ini tidak akan memiliki masalah sama sekali dengan AES-CTR default: ini sangat cepat, terutama jika perangkat keras yang digunakan memiliki set instruksi AES. RC4 lemah dan sedang dihapus di net, dan Blowfish-CBC mungkin belum tentu lebih cepat dari AES-CTR.
Reid

32

Salah satu masalah terbesar ketika meluncurkan beberapa X-client dari jarak jauh adalah X-protokol, tidak terlalu banyak ssh overhead! Protokol X memerlukan banyak ping-pong'ing antara klien dan server yang benar-benar membunuh kinerja dalam hal aplikasi jarak jauh.

Coba sesuatu seperti "x2go" (yang juga berjalan ssh dengan pengaturan default) di Anda akan melihat bahwa firefox "terbang" sebagai perbandingan!

Beberapa distribusi menyediakan paket x2go di luar kotak, misalnya pengujian Debian, atau di Stable-Backports. Tetapi jika tidak, lihat http://wiki.x2go.org/doku.php/download:start , mereka menyediakan paket / repositori biner prebuilt untuk banyak distribusi. Anda harus menginstal x2goclient (di komputer tempat Anda ingin 'menggunakan' firefox) dan x2goserver (di komputer tempat firefox harus dijalankan), Anda kemudian dapat mengonfigurasi sesi Anda untuk aplikasi X tunggal untuk tampilan desktop penuh dll. Koneksi itu sendiri terjadi lebih dari ssh. Ini alat yang sangat luar biasa :)

Untuk menggunakannya, Anda menjalankan "x2goclient", itu memulai GUI di mana Anda dapat membuat sesi baru: Anda memberikan nama dns dari server, port, data ssh, dll dan kemudian Anda memilih "tipe sesi", yaitu, jika Anda ingin desktop KDE atau GNOME jarak jauh penuh misalnya, atau hanya "aplikasi tunggal" dan di sana Anda memasukkan "firefox".


1
bagaimana saya bisa mencoba x2go? perintah
DevOps85

3
Tampaknya tidak ada x2goserverpaket di Debian (atau Ubuntu). Juga, dapatkah ini dikonfigurasikan untuk memungkinkan tunneling? Sebagai contoh, saya menggunakan machineX tetapi saya hanya bisa ssh melalui machineY. Bisakah x2go mengatasinya?
terdon

@terdon Anda benar, saya hanya memeriksa klien. Tetapi Anda bisa menambahkan repositori x2go (lihat tautan wiki.x2go.org/doku.php/download:start ) dan server ada di sana. Saya tidak tahu mengapa hanya klien di Debian. Tunneling: pasti itu mungkin, tetapi tidak pernah mencobanya. Saya berharap itu sudah cukup untuk hanya mengkonfigurasi ssh in ~/.ssh/configdan menggunakan nama host yang tepat (tunneled) di sesi x2go Anda.
Ariel

@terdon: ada opsi "Gunakan server proxy untuk koneksi SSH" (ssh / http) dalam konfigurasi sesi x2go. Jadi itu harus melakukan triknya juga!
Ariel

Ini sepertinya menarik, saya akan bermain dengannya lagi. Sejauh ini saya dapat mengkonfirmasi bahwa mengkonfigurasi terowongan .ssh/configtidak cukup. Saya memilikinya setup sehingga ssh machineBbenar - benar berjalan melalui terowongan machineAtetapi x2go tampaknya tidak melihatnya.
terdon

17

Saya memiliki pengalaman yang jauh lebih baik dalam menggunakan sshterowongan untuk mengarahkan lalu lintas melalui mesin lain. Sangat mudah untuk mengatur karena Anda memiliki akses ssh. Di terminal di komputer Anda, ketik

ssh -vv -ND 8080 user@yourserver

Biarkan jendela ini terbuka dan tontonlah mengirimkan beberapa pesan verbal tentang data yang mengalir melalui terowongan.

Dalam firefox, buka Preferensi -> Tingkat Lanjut -> Jaringan -> Koneksi: Pengaturan.

Pilih Konfigurasi proxy manual dan tambahkan SOCKS v5proxy:

 SOCKS Host:   localhost    Port 8080

Periksa IP baru Anda dengan menavigasi ke mis . Http://whatismyipaddress.com/ .

Anda dapat menggunakan firefox add-on seperti proxy foxy untuk secara dinamis mengganti proxy.


Terpilih, ini alternatif yang sangat valid untuk menggunakan kompresi berbasis NX (x2go dll), jauh lebih berguna daripada mengutak-atik pengaturan enkripsi ssh :)
Ariel

Saya menggunakan selalu ssh -L 8080: localhost: 8080, tetapi menyukai opsi -ND tetapi tidak yakin mengapa Anda menggunakan Dinamic atau Remote atau Dengar. Ngomong-ngomong, menggunakan proxy jauh lebih baik daripada menggunakan -X, tapi, saya pikir cara yang lebih baik adalah menggunakan VNC jika Anda membutuhkan lebih banyak program X dan bukan hanya Firefox.
m3nda

mudah diatur dan bekerja secara efisien!
david.perez

2

Firefox jadi lambat di SSH karena versi firefox yang lebih baru memungkinkan banyak kejadian. Jika Anda memiliki masalah bandwidth, gunakan peramban yang ringan seperti dillo dan Anda bahkan tidak akan melihat kecepatan koneksi.



1
ini tidak ada hubungannya dengan masalah ini - masalahnya bukan browser tetapi protokol X11 jarak jauh
João Antunes

0

Hal lain yang akan meningkatkan penelusuran Anda lewat ssh adalah mengaktifkan pipelining di Firefox. Buka about:configdan ubah network.http.pipeliningke true.


Opsi itu seharusnya membuat pemuatan halaman web lebih cepat, tetapi sama sekali tidak terkait dengan fakta bahwa browser berjalan di terowongan SSH atau tidak. Bagaimanapun, waspadai "tetapi" ketika Anda menyentuh opsi lanjutan ... lihat kb.mozillazine.org/Network.http.pipelining
Ariel

Dalam pengalaman saya menjelajah ssh menjadi lambat dan permintaan pemipaan merupakan bantuan besar karena jika tidak, setiap permintaan yang diberikan harus menunggu yang sebelumnya yang mungkin atau mungkin tidak lengkap tepat waktu jika sama sekali. Saya juga menggabungkan ini dengan ssh multiplexing. Itu membuat perbedaan yang nyata. Mematikan perpipaan kembali menjadi lambat tak tertahankan dalam kasus saya.
Tanath

0

Anda harus bereksperimen untuk melihat apa yang membantu dengan hambatan spesifik Anda.

Bagi saya, mengaktifkan kompresi ( -C) meningkatkan daya tanggap dari tidak dapat digunakan menjadi kelambatan yang terlihat.

Pilihan kata sandi dapat memiliki dampak juga, bertentangan dengan apa yang dikatakan beberapa orang. Anda dapat menemukan orang yang berbagi tolok ukur secara online, tetapi jangan menganggap bahwa hasil Anda akan sama. Cipher mana yang terbaik untuk Anda bergantung pada perangkat keras Bagi saya cipher default saya (chacha20-poly1305@openssh.com) sudah terikat untuk yang tercepat.

Saya menulis skrip cepat untuk membandingkan cipher yang relevan dalam kondisi yang agak realistis. Penjelasan dalam komentar:

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

Anda dapat memilih untuk menguji dengan koneksi SSH di mana klien dan host adalah mesin yang sama, atau Anda dapat menguji dalam skenario yang lebih realistis, di mana host adalah mesin Anda melakukan penerusan X11, yang seharusnya lebih bermanfaat, karena kinerja tidak hanya tergantung pada kinerja klien menguraikan, tetapi juga tuan rumah.

Pengujian dengan mesin jarak jauh dapat memiliki kerugian memperkenalkan kebisingan jika throughput koneksi internet Anda berubah selama benchmark. Dalam hal ini, mungkin ingin menambah berapa kali setiap cipher diuji.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.