Linux SSH命令执行挂起，尽管交互式shell功能正常

当我尝试使用ssh在远程服务器上执行命令时，ssh命令在

exec请求接受
debug消息后挂起，并最终超时

失败的命令：
ssh-v-v@uptime
（也尝试了
echo hello
等）

debug1:身份验证成功（公钥）。
已验证为（：22）。
调试1:通道0:新建[客户端会话]
调试2:通道0:发送打开
debug1:不再请求-sessions@openssh.com
debug1:进入交互式会话。
debug2：回调启动
debug2:客户端会话2\安装程序：id 0
调试2:fd 4设置TCP_节点延迟
debug1：发送环境。
debug1:发送env LANG=en_US.UTF-8
调试2:通道0:请求环境确认0
debug1:发送命令：正常运行时间
调试2:通道0:请求执行确认1
debug2：回调完成
调试2:通道0:打开确认rwindow 0 rmax 32768
调试2：通道0:rcvd调整2097152
调试2:通道输入状态确认：类型99 id 0
debug2:已在通道0上接受exec请求

它就这样无限期地挂在那里

然而，当我在没有命令的情况下ssh到远程服务器时，我得到了一个交互式shell，一切都很好

成功的命令：
ssh-v-v@

输出：

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>%
...

debug1:身份验证成功（公钥）。
已验证为（：22）。
调试1:通道0:新建[客户端会话]
调试2:通道0:发送打开
debug1:不再请求-sessions@openssh.com
debug1:进入交互式会话。
debug2：回调启动
debug2:客户端会话2\安装程序：id 0
调试2:fd 4设置TCP_节点延迟
调试2:通道0:请求pty req确认1
debug1：发送环境。
debug1:发送env LANG=en_US.UTF-8
调试2:通道0:请求环境确认0
调试2:通道0:请求外壳程序确认1
debug2：回调完成
调试2:通道0:打开确认rwindow 0 rmax 32768
调试2:通道输入状态确认：类型99 id 0
debug2:通道0上已接受PTY分配请求
调试2：通道0:rcvd调整2097152
调试2:通道输入状态确认：类型99 id 0
debug2:通道0上已接受外壳程序请求
欢迎
%
...

有人知道为什么交互式会话会成功，而命令执行却不会成功吗

几个月来一直困扰着我，因为我不能再使用unison来同步我的文件了（它曾经工作过）。非常感谢您的帮助。
检查您的shell启动文件中是否有出于某种原因需要终端的命令（我假设您的提示符中有
~/.cshrc
；在非交互式会话中，
~/.login
不重要）。
您的问题很可能在于shell启动或shell注销脚本。如果不知道里面有什么，就很难猜出实际的问题。
问题确实是我的登录脚本，尽管这与需要终端无关（我怀疑这一点，并使用
-t
和
-t
选项进行了测试）。问题是我的
.bashrc
正在运行
exec
（在本例中是to
zsh
——因为我们的系统不允许
chsh
to
zsh
）

冒犯的界线是：

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

通过首先检查交互式shell并退出（如果是）来解决：

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

因此，本质上，因为shell正在执行
zsh
，
ssh
正在等待这一过程的完成，而这一过程从未发生过

我有点困惑为什么要调用我的
.bashrc
——我以为这只是用于交互式shell，但各种init脚本的确切用途和顺序是我永远也学不到的

我希望这对那些在启动脚本中有某种
exec
的人有用

顺便说一句，其他两个答案都在正确的轨道上，所以我完全不确定我应该“回答”还是只是评论他们的答案。如果在stackoverflow上回答我自己的问题在道德上是错误的，请告诉我，我会忏悔的。感谢其他回答者。
我最近遇到了一个具有相同症状的问题，但确定该问题不是登录脚本中的问题。相反，我的本地
.ssh/config
文件为我试图复制到的主机配置了
RequestTTY force
。
在解决了其他新问题后，fedora server 22上出现了此问题

ssh-tziimp/bin/true正常，但不是ssh-ziimp/bin/true，我所有的git+ssh和scp都被锁定

我找到的解决方案在authorized_key文件中。我不得不从我的受信任密钥中删除命令=“/usr/bin/bash”前缀…
我们通过添加-n（从/dev/null重定向std）和-t（强制伪tty分配）修复了这个问题

例如：

ssh -t -n user@host command

我最终找到了适用于我的“$-”变量：

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

这是从：
我不知道你的问题的答案，但我有个主意。可能您的SSH客户端或SSH服务器中存在错误配置。在同一台服务器上尝试不同的客户端，然后在不同的服务器上尝试相同的客户端，让我们看看哪一个可以工作。stackoverflow上以前也出现过一些类似的问题：这不是SSH配置问题-它在不同的客户端上失败。服务器配置已为我锁定，但已由其他用户验证。这里发布的其他问题并不完全相同，我已经仔细研究过了..bashrc=每当调用shell并将其连接到终端时调用。bash_配置文件仅在登录时调用。区别是模糊的，但很容易通过echo'echo I am loggin'>~/.bash_profile检查，并使用ssh执行命令。通过这种方式，您可以查看通过ssh直接执行命令是否使shell成为登录shell。我使用oh my zsh时遇到了完全相同的问题，我必须在
source$zsh/oh my zsh.sh
之前插入
[-z“$PS1”]&&return
，以避免在使用另一台主机作为代理时ssh挂起
if [[ $- =~ i ]] ; then
    [ -x /bin/tcsh ] && exec /bin/tcsh
    # Bash startup stuff goes here...
fi