を使用して、SSH経由でFirefoxを起動しようとしました
ssh -X user@hostname
その後
firefox -no-remote
しかし、それは非常に遅いです。
どうすれば修正できますか?接続の問題ですか?
を使用して、SSH経由でFirefoxを起動しようとしました
ssh -X user@hostname
その後
firefox -no-remote
しかし、それは非常に遅いです。
どうすれば修正できますか?接続の問題ですか?
回答:
デフォルトのssh設定では、接続がかなり遅くなります。代わりに次を試してください。
ssh -YC4c arcfour,blowfish-cbc user@hostname firefox -no-remote
使用されるオプションは次のとおりです。
-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.
ここでの主なポイントは、異なる暗号化暗号(この場合はデフォルトよりも速いarcfour)を使用し、転送されるデータを圧縮することです。
注:私はこれに関する専門家とは非常にかけ離れています。上記のコマンドは、ブログの投稿で見つけた後に使用したもので、速度が大幅に改善されていることに気付きました。以下のさまざまなコメンターは、彼らが何について話しているかを知っていると確信しており、これらの暗号化暗号は最良のものではないかもしれません。この回答の中で本当に重要なのは、-C
スイッチを使用して転送されるデータを圧縮することだけである可能性が非常に高いです。
-4
、ここで実際に関連する(IPv4)の?
一部のXクライアントをリモートで起動する際の最大の問題の1つはXプロトコルであり、sshのオーバーヘッドではありません!Xプロトコルは、リモートアプリケーションの場合にパフォーマンスを完全に低下させる、クライアントとサーバー間の多くのピンポンを必要とします。
「x2go」のようなもの(これもデフォルトのセットアップでsshを経由します)を試してみてください。Firefoxが比較すると「飛ぶ」ことに気づくでしょう。
いくつかのディストリビューションでは、DebianテストやStable-Backportsなどのx2goパッケージをそのまま提供しています。ただし、そうでない場合は、http: //wiki.x2go.org/doku.php/download : startを参照してください。多くのディストリビューション用のビルド済みのバイナリパッケージ/リポジトリを提供します。x2goclient(firefoxを「使用」するコンピューターに)とx2goserver(firefoxを実行するコンピューターに)をインストールする必要があります。その後、フルデスクトップビューなどの単一Xアプリケーションのセッションを構成できます。接続自体sshで発生します。それは本当に素晴らしいツールです:)
それを使用するには、「x2goclient」を実行し、新しいセッションを作成できるGUIを起動します。サーバーのDNS名、ポート、sshデータなどを指定し、「セッションタイプ」を選択します。たとえば、完全なリモートKDEまたはGNOMEデスクトップ、または単に「単一のアプリケーション」が必要な場合は、「firefox」と入力します。
x2goserver
Debian(またはUbuntu)にはパッケージがないようです。また、これはトンネリングを許可するように構成できますか?たとえば、machineXを使用していますが、machineY経由でのみsshできます。x2goはそれを処理できますか?
~/.ssh/config
してx2goセッションで正しい(トンネル化された)ホスト名を使用するだけで十分だと思います。
.ssh/config
だけでは十分ではないことを確認できます。ssh machineB
実際にトンネル経由で実行されるようにセットアップしていますmachineA
が、x2goには表示されないようです。
私は、ssh
トンネルを使用して別のマシンを介してトラフィックをルーティングすることで、はるかに良い経験をしています。とにかくsshにアクセスできるため、セットアップは非常に簡単です。コンピューターのターミナルで、次のように入力します
ssh -vv -ND 8080 user@yourserver
このウィンドウを開いたままにして、トンネルを流れるデータに関する詳細なメッセージが表示されるのを確認します。
でfirefox
、[設定]-> [詳細設定]-> [ネットワーク]-> [接続:設定]に移動します。
手動プロキシ設定を選択し、SOCKS v5
プロキシを追加します。
SOCKS Host: localhost Port 8080
http://whatismyipaddress.com/などに移動して、新しいIPを確認します。
foxyプロキシのようなfirefoxアドオンを使用して、プロキシを動的に切り替えることができます。
Firefoxは新しいビルドのfirefoxが複数のインスタンスを許可するため、SSHで非常に遅くなります。帯域幅に問題がある場合は、dilloのような軽いブラウザを使用してください。接続速度に気付かないでしょう。
sshでのブラウジングを改善するもう1つのことは、Firefoxでパイプラインを有効にすることです。開いてtrueにabout:config変更network.http.pipeliningします。
特定のボトルネックに役立つものを確認するには、実験する必要があります。
私にとって、圧縮を有効にすると(-C
)応答性が使用不能から単なる顕著な遅延に改善されました。
一部の人々が言ったことに反して、暗号の選択も影響を与える可能性があります。オンラインでベンチマークを共有している人を見つけることができますが、結果が同じであると思い込まないでください。どの暗号が最適かはハードウェアに依存します。私にとって、デフォルトの暗号(chacha20-poly1305@openssh.com)はすでに最速のものに結び付けられていました。
少し現実的な条件下で、関連する暗号をベンチマークするための簡単なスクリプトを書きました。コメント内の説明:
#!/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]
クライアントとホストが同じマシンであるSSH接続でテストするか、ホストがX11転送を行っているマシンであるより現実的なシナリオでテストするかを選択できます。パフォーマンスは、クライアントのパフォーマンス解読だけでなく、ホストのパフォーマンスにも依存するためです。
リモートマシンでのテストには、ベンチマーク中にインターネット接続のスループットが変化した場合にノイズが発生するというデメリットがあります。その場合、各暗号がテストされる回数を増やしたいかもしれません。