☰

ログインプロンプトの前にSSHが中断されます。

tag-icon • tag-icon debian ssh
ログインプロンプトの前にSSHが中断されます。

私は、debian jessieを実行しているリモートラズベリーパイで複数のリバースSSHトンネルを設定しました。 RPIは3Gドングルを使用してイントラネット接続を取得します。これが、リバースSSHを使用してリモートでログインする理由です。各 RPI は、各システムにログインするために使用するクラウドサーバーのリバース SSH トンネルを確立します。

SSHトンネルの設定は次のとおりです。

ssh -N -o ExitOnForwardFailure=yes -R 23xx:localhost:22 [email protected]

ここで、23xx はポート 22 で接続を転送するために使用されるポート、178.xxxxx はサーバーの IP アドレスです。

私の問題は、時にシステムにSSHを接続しようとすると、次のエラーなしで永久に中断されることです。

ssh pi_username@localhost -p 23xx

その後、端末は何も出力せずに永久に停止します。 -vvv を使用してデバッグしようとすると、次の結果が表示されます。

ssh pi_username@localhost -p 23xx -vvv

OpenSSH_6.7p1 Debian-5+deb8u4, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 23xx.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/master/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/master/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/master/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/master/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/master/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/master/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/master/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/master/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u4

接続が確立されているようですが、ログインプロンプトは表示されません。どんなアイデアがありますか？これをさらにデバッグする方法について提案がありますか？

ベストアンサー1

これは理論にすぎませんが、SSHセッションへのTCP接続は消えていますが、「クラウドサーバー」がそれを検出できないことが何であるか疑われます。したがって、connectに移動すると、localhost -p 23xxsshプロセスはまだ生きていて待機していますが、Piにデータを再送信しようとすると、最大TCP再送信回数に達するまで停止し、ついに接続が切断されたと判断して終了します（永遠に停止すると言われましたが、十分に長く待つと接続これがリセットされます。）
SSHトンネルがダウンした場合に再接続するようにPiを設定したと仮定すると、これが問題を解決する必要があると考えることができます。このアイデアにはいくつかの潜在的な問題があります。まず、Piも切断された接続を検出できなかった可能性があります。したがって、データ転送を試み、TCP再送信制限に達するまで、切断された接続を確認せずに再接続します。 2番目の潜在的な問題は、接続が切断されたことを検出して再接続しようとしても、古いSSHがまだそこにあり、ポートを占有しているため、クラウドサーバーでリスナーを設定できないことです。

ここで解決策は、切断された接続を検出できるようにsshを設定することです。この問題を解決する方法には、TCP KeepAliveやSSH KeepAliveなど、いくつかの方法があります。 （引用する：https://unix.stackexchange.com/a/34201/4358)

TCP KeepAlive（TCPKeepAlivessh設定で設定）は、TCPのデフォルトの接続維持機能を使用します。デフォルトでは、カーネルはX秒ごとに空のTCP ACKを送信し、相手からACKを受信できないかリセットされた場合、接続を閉じてアプリケーション（SSH）に通知します。

SSH KeepAlive（ServerAlive*＆ClientAlive*設定）は似ていますが、より高いレベルで動作します。ここで、SSHプロセスは接続を介して実際のデータを送信し、応答を見つけます。これは通常のTCP KeepAliveのように切断された接続を検出する必要がありますが、中間ホップがTCP KeepAliveパケットを認識して無視できるだけでなく、アイドル接続がタイムアウトする可能性があるため、接続をアクティブに保つ可能性が高くなります。ただし、SSH KeepAliveは、中間ホップに到着する実際のトラフィックのように見えるため、認識されません。

簡単に言うと：

Raspberry PiでSSHクライアント構成（~/.ssh/configまたは/etc/ssh/ssh_config）に次の設定を追加します。

ServerAliveInterval 15
ServerAliveCountMax 1

（文書)

サーバーのSSHデーモン構成（/etc/ssh/sshd_config）に次の設定を追加します。

ClientAliveInterval 20
ClientAliveCountMax 1

（文書)

間隔値を少し高く設定しました。その理由は、両当事者が正確に同時にKeepAliveメッセージを送信し、回線で互いに交差するのを防ぐためです。実際に害になることはなく、わずかに非効率的です。互いに違うだけではどちらがより高いかは問題ではありません。

おすすめ記事