SSHトンネルが中断されます。

SSHトンネルが中断されます。

一部の記事にアクセスできるように、自宅で大学のコンピュータを介してSSHトンネルを使用しようとしています。

どちらのマシンもUbuntu 11.04を実行しています。大学の機械が動いていたopenssh-server

自宅では、次のガイドラインに従ってください。

  1. SSHセッションを開きます。

    ssh -D 9999 -C user@my_addr.com 
    
  2. 9999次に、ポートでSOCKS5接続を使用するようにFirefoxを設定しましたlocalhost

これはしばらくの間動作します。その後、突然接続が切断され、端末が停止します。

私がここで何を見逃しているのでしょうか?

答え1

設定を試すことができますクライアントアクティビティ間隔そして生きているクライアントの最大数sshd設定ファイルの変数を自分に合った値に変更してください。

マニュアルから:

ClientAliveInterval 

Sets a timeout interval in seconds after which if no data has been received
from the client, secshd will send a message through the encrypted channel 
to request a response from the client.
The default is 0, indicating that these messages will not be sent to the 
client. This option applies to protocol version 2 only.

答え2

努力するautossh。中断した接続を検出して自動的に再接続します。私は過去に同様の状況でこれを使ったことがあり、私にはうまくいきました。

編集する

  1. 私はそれから実行しましたがscreen、ここには2つの利点があります。つまり、バックグラウンドで実行され(一種の)、後でセッションに戻って状態を確認し、必要に応じてデバッグできます。次のようになります。

    screen -d -m -S my-autossh-tunnel autossh your_autossh_args
    

    これで壁紙が起動します。プロセスを確認するには、次のコマンドを使用してこのセッションに再接続autosshできます。screenscreen -R my-autossh-tunnel

  2. 便宜上、空のパスワードを使用しましたが、セキュリティを強化するためにリモート側のauthorized_keysで次のオプションを使用しました。

    command="/bin/false",no-agent-forwarding,no-X11-forwarding,no-pty`
    

    これにより、キーを使用してトンネルを設定でき、シェルを他の目的に誤用することはできません。

答え3

また、whileスクリプトでautosshを使用することをお勧めします。たとえば、次のようになります。

私はcrontabにこれを持っています:

@reboot while true; do sleep 10; autossh -i /some/location_not_default.pem -D 9999 -L 1028:localhost:3128; done

一方、常に接続を試み、接続を確立し、ソックスポートを作成し、イカポートを転送しようとします。これは私にとって非常に安定していることが証明されています。

答え4

SSHトンネルを介してVNCを使用しても同じ問題が発生しました。 putty(windows), openssh(linux) の場合、フリーズが頻繁に発生します。

Puttyを使用して接続プロファイルをコピーし、いくつかのオプションを変更して何が起こっているのかを確認し、停止しなくなりました! Puttyの変更点は次のとおりです。

接続:「Nagleアルゴリズムを無効にする」の選択を解除します。 (「TCPキープアライブを有効にする」を選択し、「キープアライブ間の秒数」を30に設定しました。)「インターネットプロトコルバージョン」IPv4を選択します(「自動」ではなく)。

接続 - SSH:「圧縮を有効にする」を選択します。

どのようなオプションでこの問題が解決されるかはわかりませんが、今は幸せなキャンプを楽しんでいます。凍結することはできませんでしたが、確認のために以前のプロファイルに戻ったときに数秒で凍結しました。

停止は、主にローリングウィンドウなどのVNCを介して大規模な更新を送信するときに発生します。これは、無効なNagleアルゴリズムが原因でサーバーが小さすぎるパケットでいっぱいになる可能性があり、リモートVNCサーバーではipv6が無効になっているが、他のホストでは無効になっている可能性があります。これを把握するには、さまざまなオプションの追加テストが必要です。

関連情報