web-dev-qa-db-ja.com

SSHコマンドの実行がハングするが、対話型シェルは正常に機能する

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

失敗したコマンド：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 [email protected]
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 [email protected]
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を使用してファイルを同期することができなくなったため（これまでは機能していた）、何ヶ月も悩まされてきました。どんな助けも大歓迎です。

linuxsshremote-execution
23
Robert Muil

問題は確かに私のログインスクリプトでしたが、端末の要求とは関係ありません（私はそれを疑っていて、-tおよび-Tオプション）。問題は、私の.bashrcはexecを実行していました（この場合はzshに-このシステムではchshからzshを許可していないため）。

問題のある行：

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

最初にインタラクティブシェルをチェックし、そうであれば終了することで解決します。

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

つまり、基本的に、シェルはzshを実行しているため、sshはこれが完了するのを待っていました。

なぜ.bashrcはまったく呼び出されていました-これはインタラクティブなシェルのためだけだと思っていましたが、さまざまなinitスクリプトの正確な目的と順序は、これから学ぶことはないと思います。

スタートアップスクリプトに何らかのexecが含まれている他のユーザーにも役立つと思います。

ところで-他の2つの回答は正しい方向に進んでいたので、「回答」するべきか、彼らの回答にコメントするだけなのか、私にはまったくわかりませんでした。自分の質問への回答がstackoverflowで道徳的に間違っている場合は、私に知らせてください。私が悔い改めます。他の回答者に感謝します。

24
Robert Muil

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

4
Mel

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

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

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

2
Tanguy

シェルスタートアップファイルのコマンドを確認します（~/.cshrcプロンプトから。非インタラクティブセッションでは、~/.loginは問題ではありません）何らかの理由で端末を必要とします。

2
geekosaur

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

2
MJD

これを修正するには、-n（/ dev/nullからstdをリダイレクトするため）と-t（疑似tty割り当てを強制するため）を追加します。

例：

ssh -t -n user@Host command
2
A.Badger

私は最終的に私のために働く "$-"変数を見つけました：

if [[ $- =~ i ]] ; then
    [ -x /bin/tcsh ] && exec /bin/tcsh
    # Bash startup stuff goes here...
fi

これを入手： https://www.gnu.org/software/bash/manual/html_node/Is-this-Shell-Interactive_003f.html

0
The Veritable Bugeater