Linux SSH 命令执行挂起，但交互式 shell 功能正常
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5929552/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
SSH Command Execution Hangs, although interactive shell functions fine
提问by Robert Muil
When I attempt to execute a command on a remote server with ssh, the ssh command hangs after the exec request accepteddebug message, and eventually times out.
当我尝试使用 ssh 在远程服务器上执行命令时，ssh 命令在exec request accepted调试消息后挂起，并最终超时。
The failing command: ssh -v -v <username>@<server> uptime(also tried echo helloetc.)
失败的命令：（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
And there it hangs, indefinitely.
它无限期地挂在那里。
When I ssh without a command into my remote server, however, I get an interactive shell and all is good.
但是，当我在没有命令的情况下 ssh 进入我的远程服务器时，我得到了一个交互式 shell，一切都很好。
Successful Command: ssh -v -v <username>@<server>
成功命令： ssh -v -v <username>@<server>
Output:
输出：
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>%
...
Has anyone an idea why an interactive session would be successful but a command execution not?
有谁知道为什么交互式会话会成功但命令执行不会？
Has been haunting me for months now because I cannot use unison to sync my files any more (it used to work). Any help much appreciated.
几个月来一直困扰着我，因为我不能再使用 unison 来同步我的文件（它曾经可以工作）。非常感谢任何帮助。
采纳答案by Robert Muil
The problem was indeed my login script, although not to do with requiring a terminal (I'd suspected that and tested with the -tand -Toptions). The problem was that my .bashrcwas running an exec(in this case to zsh- because our system doesn't allow chshto zsh).
问题确实是我的登录脚本，尽管与需要终端无关（我怀疑并使用-t和-T选项进行了测试）。问题是，我.bashrc是运行的exec（在这种情况下zsh-因为我们的系统不允许chsh到zsh）。
The offending line:
违规行：
test -f /usr/bin/zsh && exec /usr/bin/zsh
Solved by first checking for interactive shell and exiting if so:
通过首先检查交互式 shell 并退出来解决：
[ -z "$PS1" ] && return
test -f /usr/bin/zsh && exec /usr/bin/zsh
So, essentially, because the shell was execing into zsh, sshwas waiting for this to finish - which never happened.
所以，本质上，因为 shell 正在 execing into zsh，ssh正在等待这完成 - 这从未发生过。
I am a little confused why my .bashrcwas being called at all - I thought this was only for interactive shells, but the exact purpose and order of the various init scripts is something I don't think I'll ever learn.
我有点困惑为什么我.bashrc被调用了 - 我认为这仅适用于交互式 shell，但各种 init 脚本的确切目的和顺序是我认为我永远不会学习的东西。
I hope this can be useful to others who have some kind of execin their startup scripts.
我希望这对exec在启动脚本中有某种类型的其他人有用。
BTW - the other two answers were on the right track so I was completely unsure if I should 'answer' or just comment their answers. If answering my own question is morally wrong on stackoverflow, let me know and I'll do penitence. Thank you to the other answerers.
顺便说一句 - 其他两个答案在正确的轨道上，所以我完全不确定我是否应该“回答”或只是评论他们的答案。如果在 stackoverflow 上回答我自己的问题在道德上是错误的，请告诉我，我会忏悔。感谢其他回答者。
回答by geekosaur
Check for commands in your shell startup files (I would assume ~/.cshrcfrom your prompt; in a non-interactive session, ~/.loginshouldn't matter) that require a terminal for some reason.
检查您的 shell 启动文件中的命令（我会~/.cshrc从您的提示中假设；在非交互式会话中，~/.login应该无关紧要）由于某种原因需要终端。
回答by Mel
Your problem most likely lies in your shell startup or shell logout scripts. Without knowing what's in there, it's hard to guess the actual problem.
您的问题很可能出在您的 shell 启动或 shell 注销脚本中。如果不知道里面有什么，就很难猜测实际问题。
回答by MJD
I recently encountered a problem with the same symptoms, but determined that the issue was nota problem in my login scripts. Rather, my local .ssh/configfile was configured with RequestTTY forcefor the host that I was trying to copy to.
我最近遇到了一个具有相同症状的问题，但确定该问题不是我的登录脚本中的问题。相反，我的本地.ssh/config文件是RequestTTY force为我试图复制到的主机配置的。
回答by Tanguy
I had this problem on fedora server 22, after the resolution of other new problems.
在解决其他新问题后，我在 Fedora 服务器 22 上遇到了这个问题。
ssh -tziimp /bin/true was ok but not ssh ziimp /bin/true and all my git+ssh and scp were locked.
ssh -tziimp /bin/true 可以，但 ssh ziimp /bin/true 不行，我所有的 git+ssh 和 scp 都被锁定了。
The solution i found was in the authorized_keysfile. I had to remove the command="/usr/bin/bash" prefix from my trusted keys...
我找到的解决方案是在authorized_keys文件中。我不得不从我信任的密钥中删除 command="/usr/bin/bash" 前缀......
回答by A.Badger
We fixed this by adding adding -n (to redirect std in from /dev/null) and -t (force pseudo-tty allocation)
我们通过添加 -n（从 /dev/null 重定向 std 中）和 -t（强制伪 tty 分配）来解决这个问题
Example:
例子：
ssh -t -n user@host command
回答by The Veritable Bugeater
I eventually found the "$-" var which works for me:
我最终找到了对我有用的“$-”var：
if [[ $- =~ i ]] ; then
[ -x /bin/tcsh ] && exec /bin/tcsh
# Bash startup stuff goes here...
fi
Got this from: https://www.gnu.org/software/bash/manual/html_node/Is-this-Shell-Interactive_003f.html
来自：https: //www.gnu.org/software/bash/manual/html_node/Is-this-Shell-Interactive_003f.html
