26

リモート サーバーで ssh を使用してコマンドを実行しようとすると、exec request acceptedデバッグ メッセージの後に ssh コマンドがハングし、最終的にタイムアウトになります。

失敗したコマンド：（ssh -v -v <username>@<server> uptimeまた試したecho helloなど）

debug1: Authentication succeeded (publickey).
Authenticated to <server> (<ip>:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 4 setting TCP_NODELAY
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: uptime
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0

そして、無期限にハングアップします。

ただし、コマンドなしでリモートサーバーに ssh すると、対話型シェルが表示され、すべて問題ありません。

成功したコマンド:ssh -v -v <username>@<server>

出力：

debug1: Authentication succeeded (publickey).
Authenticated to <server> (<ip>:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 4 setting TCP_NODELAY
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome!
<prompt>%
...

インタラクティブなセッションは成功するが、コマンドの実行は成功しない理由を知っている人はいますか?

unison を使用してファイルを同期することができなくなったため、何ヶ月も悩まされています (以前は機能していました)。どんな助けでも大歓迎です。

4

7 に答える 7

32

問題は確かに私のログイン スクリプトにありましたが、ターミナルが必要なこととは関係ありません (私はそれを疑い、オプション-tと-Tオプションでテストしました)。問題は、私.bashrcが を実行していたことですexec(この場合は に- システムが を許可してzshいないため)。chshzsh

問題のある行：

test -f /usr/bin/zsh && exec /usr/bin/zsh

最初に対話型シェルをチェックし、そうであれば終了することで解決しました:

[ -z "$PS1" ] && return
test -f /usr/bin/zsh && exec /usr/bin/zsh

したがって、本質的に、シェルが実行中だったため、これが完了するzshのsshを待っていましたが、これは決して起こりませんでした。

なぜ my.bashrcがまったく呼び出されたのか少し混乱しています。これは対話型シェル専用だと思っていましたが、さまざまな init スクリプトの正確な目的と順序は、私が学ぶことはないと思います。

execこれが、スタートアップ スクリプトになんらかの種類がある他のユーザーに役立つことを願っています。

ところで-他の2つの回答は正しい軌道に乗っていたので、「回答」する必要があるのか​​ 、回答にコメントするだけなのか完全にわかりませんでした。スタックオーバーフローで自分の質問に答えることが道徳的に間違っている場合は、お知らせください。悔い改めます。他の回答者様ありがとうございます。

于 2011-05-09T10:30:16.773 に答える
4

問題は、シェルの起動スクリプトまたはシェル ログアウト スクリプトにある可能性が最も高いです。そこに何があるかを知らなければ、実際の問題を推測するのは困難です。

于 2011-05-08T19:01:01.730 に答える
3

最近、同じ症状の問題が発生しましたが、ログイン スクリプトの問題ではないと判断しました。むしろ、ローカル.ssh/configファイルはRequestTTY force、コピー先のホスト用に構成されていました。

于 2014-11-14T19:15:47.483 に答える
2

何らかの理由で端末を必要とするシェル起動ファイル内のコマンドを確認します (~/.cshrcプロンプトから推測しますが、非対話型セッションでは問題にならないはずです)。~/.login

于 2011-05-08T19:00:58.677 に答える
2

他の新しい問題を解決した後、Fedora サーバー 22 でこの問題が発生しました。

ssh -t ziimp /bin/true は問題ありませんでしたが、 ssh ziimp /bin/true ではなく、すべての git+ssh と scp がロックされていました。

私が見つけた解決策は、authorized_keysファイルにありました。信頼できるキーから command="/usr/bin/bash" プレフィックスを削除する必要がありました...

于 2015-07-17T18:33:59.880 に答える