☰

婦人声明

tag-icon • tag-icon ssh gnu-screen session
婦人声明

不安定なWi-Fi環境では、SSH経由でサーバーに接続する必要があることがよくあります。サーバーで画面を実行しているため、接続が失われた場合は再接続し、画面セッションを再開して中断したところから続行できますが、接続損失は依然として時間がかかります。サーバーへの接続中に接続が切断されると、ターミナルウィンドウが停止する傾向があります。タブを終了し、新しいタブを開き、再度サーバーにSSHを介して接続し、スクリーンセッションを再開する必要があります。サーバーとローカル画面で画面を実行してみました。いずれにしても接続が切断されると停止します。

手動で再接続する必要がないように自動的に再接続し、セッションを実行し続ける画面または画面自体と同様の機能を持つ方法はありますか？一般的に、接続が切断された場合は短時間しか発生しないと思います。おそらく1秒もならない時間でしょう。

Ubuntu 14.04 LTS、MATEバージョンを使用しています。ありがとう

答え1

以下を使用して表示できますmosh。https://mosh.org/

信頼性の高いインターネット接続を介して「ジャンプ」サーバーを確立して接続し、管理するmosh各sshサーバーとのセッションを確立できます。ジャンプサーバーの使用を推奨する理由は、おそらくmosh管理対象サーバーにジャンプサーバーをインストールしたくないからです。

もう1つの利点moshは、TCPではなくUDPに基づいており、WiFi接続からモバイルインターネット接続などのIPアドレスが変更されてもセッションが維持されることです。

明らかに言えば、代替品でmoshはありませんscreen。何らかの理由でクライアントがシャットダウンされた場合、デフォルトではセッションに再接続する方法が提供されていないため、sshこれを使用することをお勧めします。screenmosh

答え2

SSHのServerAliveオプションを使用して、接続障害のタイミングを検出します。

ServerAliveCountMax
ssh（1）がサーバーからメッセージを再受信できない場合に送信できるサーバーアクティブメッセージの数（以下を参照）を設定します。サーバー活動メッセージの送信中にこのしきい値に達すると、sshはサーバーとの接続を切断してセッションを終了します。サーバーアクティビティメッセージの使用はTCPKeepAlive（下）とは大きく異なることに注意することが重要です。サーバーアクティビティメッセージは、偽装できないように暗号化されたチャネルを介して送信されます。 TCPKeepAliveアクティブなTCP keepaliveオプションはなりすまし可能です。サーバーの活動メカニズムは、クライアントまたはサーバーが接続を無効にするタイミングを知る必要がある場合に役立ちます。

デフォルトは 3 です。たとえば、ServerAliveInterval（以下を参照）が15に設定され、ServerAliveCountMaxがデフォルトのままである場合、サーバーが応答しない場合、約45秒後にsshの接続が切断されます。

ServerAliveInterval
サーバーからデータが受信されない場合、ssh（1）は暗号化されたチャネルを介してメッセージを送信してサーバーに応答を要求するタイムアウト間隔（秒単位）を設定します。デフォルトは 0 で、これはこれらのメッセージがサーバーに送信されないことを意味します。

ServerAliveIntervalしたがって、5に設定すると、ssh15秒間ネットワークが停止すると、接続は自動的に切断されます。

答え3

使ってきたtmux私の経験によると、数年間自動的に再接続されます。少なくとも比較的短時間だけ接続が失敗した場合です。ちなみに私が実際に使うのはbyobutmuxをバックエンドとして使用してください。この堅牢性が両方の特徴なのか、tmuxそれともbyobu両方の組み合わせなのかはわかりませんが、両方を試してみることをお勧めします。

VPNを介してローカルArchインストールからさまざまなリモートUbuntuサーバーに接続します。先ほどリモコンに接続した状態でネットワークケーブルを抜いてテストしてみました。セッションが中断されましたが、ケーブルを再接続するとスムーズに再開されます。

ところで、テストのためにルータを再起動しましたが、接続は復元されませんでした。ネットワークがどれくらい壊れているかと関係があるようですが、数秒で切断すると再接続されるようです。

関係があれば使用しますterminator私の端末エミュレータとして。

どちらもUbuntuリポジトリにあります。

sudo apt-get install tmux terminator byobu

しかし、私はsshの切断を処理することに全く自信がないか、より良いものはありませんtmux。byobu私が知っているのは、私の経験では、短い切断からしばしば回復することです。しかし、これは私の設定の他の側面によって異なります。

答え4

婦人声明

SSH接続が一時的なネットワーク中断に耐えられない場合は、次のことがあります。その他ssh続行すると、TCPは正常な操作を実行できません。

詳しくは下記をご覧ください。それでも：

最も速くて汚い依存関係のないソリューション

次のシェルスクリプトを作成します。

#!/bin/sh -

# Tune these numbers depending on how aggressively
# you want your SSH session to get reconnected.
timeout_options='-o ServerAliveInterval=4 -o ServerAliveCountMax=2'

# 255 is the status OpenSSH uses to signal SSH errors, which
# means we want to connect. All other exit statuses suggest
# an intentional exit.
status=255

# Keep opening the SSH connection and immediately dropping into
# `screen` until an intentional exit happens.
while [ "$status" = 255 ]
do
    ssh $timeout_options -t "$@" screen -dR
    status=$?
    # You can add a `sleep` command here or a counter or whatever
    # you might need as far as rate/retry limiting.
done
exit "$status"

これは単に愚かな単純なループを実行することによって継続的に接続し、ssh接続しようとしますscreen。ホストまたはssh通常は呼び出しにコマンドライン引数として渡される他のエントリを渡します。

再接続は、SSHが接続エラーを報告するかどうかにのみ基づいています。つまり、「実際にWiFIがオンになっていません」など、SSH以外のエラーやその他のエラーを検出できませんが、問題ありません。

ssh-agent再接続に追加の入力を必要としないパスワードのないSSHキーがあるとします。

いくつかの競合状態がある可能性があり、^C再接続中に人が検出できない瞬間にクラッシュが発生した場合は、クライアントにスクリプトを渡すのではなくスクリプトを終了する可能性があるため、^C接続が中断されたと思われる場合は避けてください。^Cとても頑張りました。

最も簡単な追加ソフトウェアソリューション

このプログラムを試すことができます自動SSH、Ubuntuパッケージストアで利用可能である必要があります。

ソースからビルドまたは監査する必要がある場合は、依存関係として追加のライブラリなしでコンパイルし、上記のハッキングよりもインテリジェントにリンクアクティブを確認するように見える別のCプログラムです。そしてrscreenまた、自動的に追加される便利なスクリプトコマンドも付属していますscreen。

詳細

ssh一般的に復元する方法

確認のために確認せずに言いたくないので、答える前にいくつかのテストを行いました。

Linuxデバイスを使用してWiFiに接続し、LAN上の他のデバイスにSSH接続を確立し、sshもう一方の端で動作する接続を確認して（コマンドの実行など）、クライアントからWiFiを切断する（インターフェイスの設定を解除する原因：IPアドレスがなくなりました）SSHセッションにさらに文字を入力して（もちろん応答しない）、WiFiに再接続します。実際、シグナルのバグやその他の要因のため、再接続が複数回失敗しました。そしてついに再接続しました。セッションがssh再開されるまで約5秒待ちましたが、何も起こらなかったため、別のキーを押したときにセッションがsshすぐに再びアクティブになり、接続が切断されたときに入力したすべてのキーがコマンドラインに表示されました。

sshOSが何か間違っていると言うまでTCPネットワークソケットからの書き込み/読み取りのみですが、TCPは実際には非常に長期間の接続の中断に耐えることができます。

デフォルトのカーネル設定を使用して独自のデバイスに残すと、LinuxのTCPスタックは接続が失われたと宣言し、エラーを報告する前に数分間完全にサイレントな接続を喜んで受け入れます。sshついにあきらめたら、私たちは話しています。約30分、または少なくとも1秒または1分間続く接続の中断を克服するのに十分な時間です。

しかし、その後、Linux TCPスタックはますます長い遅延を使用してメッセージを徐々に再試行します。つまり、接続が再び回復すると、sshセッションが再び「アクティブ」と表示される前に追加の遅延が発生する可能性があります。

時々なぜこれが起こるのか

しばしば、何らかの理由でしばらくすると接続が切断されることがあります。大幅短縮接続状態がクライアントに報告される前に、TCPスタックが許可できる時間よりも多くの非アクティブ時間がありますssh。

可能な候補は次のとおりです。

  1. ファイアウォールまたはNATルーターは、各リアルタイムTCP接続を記憶するためにメモリを使用する必要があります。 DOS攻撃の最適化と緩和のために時々忘れるそれからあなたのつながり静かに無視後続のパケットは、既存の接続を覚えていない場合、接続の途中にあるパケットが無効であるように見えるためです。

  2. より良いパフォーマンスのファイアウォール/ルーターは通常エラーメッセージとして表示されるTCP RSTパケットを挿入しますconnection reset by peerが、リセットパケットは確立され忘れているため、その時点でクライアント接続にまだ問題があり、リセットパケットも破棄する場合、クライアントは接続がまだ存在しますと思います。

  3. 仕える人それ自体予期しないパケットを自動的に破棄するファイアウォールポリシーがある可能性があります。サーバーは接続が閉じられたと思いますが、クライアントはそうでないときはいつでもクライアントの接続回復試行が中断されます。クライアントは引き続き接続しようとしますが、サーバーはそれを無視します。サーバーのファイアウォール状態では、これらのパケットが属するライブ接続が存在しないためです。

    Linuxを実行しているので、サーバーのiptables/ ip6tables（またはnft新しいものを使用している場合）を再確認して、何を許可または省略するのかを正確に確認してください。許可するのが一般的です新しい/確立された/関連TCP SSHポートのパケットですが、いいえ「間違っている」 - この一般的な設定は、許可されていないすべてのコンテンツを自動的に削除すると、しばらくの接続で問題が発生した後に停止を引き起こす可能性があります。

  4. TCPまたはSSHクライアント接続を維持するパケットのOpenSSHオプションのいずれかを使用して、一定期間アクティビティがない場合は、接続を閉じるようにSSHサーバー自体を構成できます。それ自体は無期限の停止は発生しませんが、上記のいずれかの状態に陥ることがあります。

  5. sshサスペンド状態に入った後、セッション自体を「サスペンド解除」するのに十分な時間を提供していない可能性があります。

関連情報