I try to launch Firefox over SSH, using
ssh -X user@hostname
but it's very very slow.
How can I fix this? Is it a connection problem?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
The default ssh settings make for a pretty slow connection. Try the following instead:
ssh -YC4c arcfour,blowfish-cbc user@hostname firefox -no-remote
The options used are:
-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.
The main point here is to use a different encryption cypher, in this case arcfour which is faster than the default, and to compress the data being transferred.
NOTE: I am very, very far from an expert on this. The command above is what I use after finding it on a blog post somewhere and I have noticed a huge improvement in speed. I am sure the various commenters below know what they're talking about and that these encryption cyphers might not be the best ones. It is very likely that the only bit of this answer that is truly relevant is using the
-C switch to compress the data being transferred.
One of the biggest issues when launching some X-client remotely is the X-protocol, not so much the ssh overhead! The X-protocol requires a lot of ping-pong'ing between the client and the server which absolutely kills performance in the case of remote applications.
Try something like "x2go" (which also goes over ssh with default setups) in you will notice that firefox "flies" in comparison!
Several distributions provide the x2go packages out of the box, for instance Debian testing, or in Stable-Backports. But if not, see http://wiki.x2go.org/doku.php/download:start , they provide prebuilt binary packages/repositories for many distributions. You should install x2goclient (on the computer where you want to 'use' firefox) and x2goserver (in the computer where firefox should be running), you can then configure your sessions for single X applications of for full desktop views etc. The connection itself happens over ssh. It's a really wonderful tool :)
To use it, you run "x2goclient", it starts a GUI where you can create a new session: you provide the dns name of the server, port, ssh data, etc and then you select the "session type", ie, if you want a full remote KDE or GNOME desktop for instance, or just a "single application" and there you enter "firefox".
I have much better experience in using an
ssh tunnel to route traffic through another machine. It's very easy to set up since you have ssh access anyway. In a terminal on your computer, type
ssh -vv -ND 8080 user@yourserver
Keep this window open and watch it delivering some verbose messages about the data flowing through the tunnel.
firefox, go to Preferences -> Advanced -> Network -> Connection: Settings.
Select Manual proxy configuration and add a
SOCKS v5 proxy:
SOCKS Host: localhost Port 8080
Check your new IP by navigating to e.g. http://whatismyipaddress.com/.
You can use a firefox add-on like foxy proxy to dynamically switch proxies.
You have to experiment to see what helps with your specific bottlenecks.
For me, enabling compression (
-C) improved responsiveness from unusable to just noticable lag.
Choice of cipher can have an impact too, contrary to what some people said. You can find people sharing benchmarks online, but don't presume that your results will be the same. Which cipher is best for you is hardware dependent. For me my default cipher (email@example.com) was already tied for the fastest one.
I wrote a quick script to benchmark relevant ciphers under somewhat realistic conditions. Explanations in the comments:
#!/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 firstname.lastname@example.org email@example.com firstname.lastname@example.org" 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: email@example.com,aes128-ctr,aes192-ctr,aes256-ctr,firstname.lastname@example.org,email@example.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]
You can choose to test with an SSH connection where the client and host are the same machine, or you can test in a more realistic scenario, where the host is the machine you're doing the X11 forwarding from, which should be more useful, because the performance not only depends on the client's performance deciphering, but also the host's.
Testing with a remote machine can have the disadvantage of introducing noise if the throughput of your internet connection changes in the course of the benchmark. In that case, might want to bump up the number of times each cipher is tested.