所有相关信息都在现有的答案中，但让我尝试一个实用的总结:

tl; diana:

使用命令行参数传递命令: SSH jdoe@server“…” “…'字符串可以跨越多行，所以即使不使用here-document，你也可以保持代码的可读性: SSH jdoe@server“…” 不要通过stdin传递命令，就像你使用here-document一样: ssh jdoe@server <<'EOF' #不这样做…EOF

将命令作为参数传递，按原样工作，并且:

伪终端的问题甚至不会出现。 您不需要在命令末尾使用退出语句，因为会话将在处理完命令后自动退出。

简而言之:通过stdin传递命令是一种与ssh的设计不一致的机制，并且会导致必须解决的问题。 如果你想了解更多，请继续阅读。

可选背景信息:

Ssh接受在目标服务器上执行的命令的机制是一个命令行参数:最后一个操作数(非选项参数)接受一个包含一个或多个shell命令的字符串。

By default, these commands run unattended, in a non-interactive shell, without the use of a (pseudo) terminal (option -T is implied), and the session automatically ends when the last command finishes processing. In the event that your commands require user interaction, such as responding to an interactive prompt, you can explicitly request the creation of a pty (pseudo-tty), a pseudo terminal, that enables interacting with the remote session, using the -t option; e.g.: ssh -t jdoe@server 'read -p "Enter something: "; echo "Entered: [$REPLY]"' Note that the interactive read prompt only works correctly with a pty, so the -t option is needed. Using a pty has a notable side effect: stdout and stderr are combined and both reported via stdout; in other words: you lose the distinction between regular and error output; e.g.: ssh jdoe@server 'echo out; echo err >&2' # OK - stdout and stderr separate ssh -t jdoe@server 'echo out; echo err >&2' # !! stdout + stderr -> stdout

如果没有这个参数，ssh会创建一个交互式shell——包括当你通过stdin发送命令时，这就是问题开始的地方:

For an interactive shell, ssh normally allocates a pty (pseudo-terminal) by default, except if its stdin is not connected to a (real) terminal. Sending commands via stdin means that ssh's stdin is no longer connected to a terminal, so no pty is created, and ssh warns you accordingly: Pseudo-terminal will not be allocated because stdin is not a terminal. Even the -t option, whose express purpose is to request creation of a pty, is not enough in this case: you'll get the same warning. Somewhat curiously, you must then double the -t option to force creation of a pty: ssh -t -t ... or ssh -tt ... shows that you really, really mean it. Perhaps the rationale for requiring this very deliberate step is that things may not work as expected. For instance, on macOS 10.12, the apparent equivalent of the above command, providing the commands via stdin and using -tt, does not work properly; the session gets stuck after responding to the read prompt: ssh -tt jdoe@server <<<'read -p "Enter something: "; echo "Entered: [$REPLY]"'

在不太可能发生的情况下，您想要作为参数传递的命令使命令行对您的系统来说太长(如果它的长度接近getconf ARG_MAX -请参阅本文)，请考虑先以脚本的形式将代码复制到远程系统(例如，使用scp)，然后发送命令来执行该脚本。

在紧急情况下，使用-T，并通过stdin提供命令，后面有一个退出命令，但请注意，如果您还需要交互功能，则使用-tt代替-T可能不起作用。

在看了很多这样的答案之后，我想分享一下我的解决方案。我只是在heredoc之前添加了/bin/bash，它不再给出错误了。

用这个:

ssh user@machine /bin/bash <<'ENDSSH'
   hostname
ENDSSH

而不是这个(给出错误):

ssh user@machine <<'ENDSSH'
   hostname
ENDSSH

或者用这个:

ssh user@machine /bin/bash < run-command.sh

而不是这个(给出错误):

ssh user@machine < run-command.sh

额外的:

如果你仍然需要一个远程交互式提示，例如，如果你正在远程运行的脚本提示你输入密码或其他信息，因为前面的解决方案不允许你输入提示。

ssh -t user@machine "$(<run-command.sh)"

如果你还想把整个会话记录在一个文件logfile.log中:

ssh -t user@machine "$(<run-command.sh)" | tee -a logfile.log

我在Windows下使用emacs 24.5.1通过/ssh连接到一些公司服务器:user@host时遇到了同样的错误。解决我的问题是将“tramp-default-method”变量设置为“plink”，每当我连接到服务器时，我都会提交ssh协议。你需要安装PuTTY的plink.exe才能工作。

解决方案

M-x自定义变量(然后按Enter) tramp-default-method(然后再次按Enter键) 在文本框中输入plink，然后应用并保存缓冲区 每当我尝试访问远程服务器时，我现在使用C-x-f /user@host:，然后输入密码。现在在Windows上的Emacs下正确地建立了到远程服务器的连接。

我不知道挂起的原因是什么，但是将命令重定向(或管道)到交互式ssh通常会出现问题。使用command-to-run-as- last-argument样式并在ssh命令行上传递脚本会更健壮:

ssh user@server 'DEP_ROOT="/home/matthewr/releases"
datestamp=$(date +%Y%m%d%H%M%S)
REL_DIR=$DEP_ROOT"/"$datestamp
if [ ! -d "$DEP_ROOT" ]; then
    echo "creating the root directory"
    mkdir $DEP_ROOT
fi
mkdir $REL_DIR'

(所有这些都包含在一个以'分隔的多行命令行参数中)。

伪终端消息是因为您的-t要求ssh尝试使它在远程机器上运行的环境看起来像在那里运行的程序的实际终端。您的ssh客户端拒绝这样做，因为它自己的标准输入不是终端，所以它没有办法将特殊的终端api从远程机器传递到您在本地端的实际终端。

你想用-t实现什么呢?

所有相关信息都在现有的答案中，但让我尝试一个实用的总结:

tl; diana:

使用命令行参数传递命令: SSH jdoe@server“…” “…'字符串可以跨越多行，所以即使不使用here-document，你也可以保持代码的可读性: SSH jdoe@server“…” 不要通过stdin传递命令，就像你使用here-document一样: ssh jdoe@server <<'EOF' #不这样做…EOF

将命令作为参数传递，按原样工作，并且:

伪终端的问题甚至不会出现。 您不需要在命令末尾使用退出语句，因为会话将在处理完命令后自动退出。

简而言之:通过stdin传递命令是一种与ssh的设计不一致的机制，并且会导致必须解决的问题。 如果你想了解更多，请继续阅读。

可选背景信息:

Ssh接受在目标服务器上执行的命令的机制是一个命令行参数:最后一个操作数(非选项参数)接受一个包含一个或多个shell命令的字符串。

By default, these commands run unattended, in a non-interactive shell, without the use of a (pseudo) terminal (option -T is implied), and the session automatically ends when the last command finishes processing. In the event that your commands require user interaction, such as responding to an interactive prompt, you can explicitly request the creation of a pty (pseudo-tty), a pseudo terminal, that enables interacting with the remote session, using the -t option; e.g.: ssh -t jdoe@server 'read -p "Enter something: "; echo "Entered: [$REPLY]"' Note that the interactive read prompt only works correctly with a pty, so the -t option is needed. Using a pty has a notable side effect: stdout and stderr are combined and both reported via stdout; in other words: you lose the distinction between regular and error output; e.g.: ssh jdoe@server 'echo out; echo err >&2' # OK - stdout and stderr separate ssh -t jdoe@server 'echo out; echo err >&2' # !! stdout + stderr -> stdout

如果没有这个参数，ssh会创建一个交互式shell——包括当你通过stdin发送命令时，这就是问题开始的地方:

For an interactive shell, ssh normally allocates a pty (pseudo-terminal) by default, except if its stdin is not connected to a (real) terminal. Sending commands via stdin means that ssh's stdin is no longer connected to a terminal, so no pty is created, and ssh warns you accordingly: Pseudo-terminal will not be allocated because stdin is not a terminal. Even the -t option, whose express purpose is to request creation of a pty, is not enough in this case: you'll get the same warning. Somewhat curiously, you must then double the -t option to force creation of a pty: ssh -t -t ... or ssh -tt ... shows that you really, really mean it. Perhaps the rationale for requiring this very deliberate step is that things may not work as expected. For instance, on macOS 10.12, the apparent equivalent of the above command, providing the commands via stdin and using -tt, does not work properly; the session gets stuck after responding to the read prompt: ssh -tt jdoe@server <<<'read -p "Enter something: "; echo "Entered: [$REPLY]"'

在不太可能发生的情况下，您想要作为参数传递的命令使命令行对您的系统来说太长(如果它的长度接近getconf ARG_MAX -请参阅本文)，请考虑先以脚本的形式将代码复制到远程系统(例如，使用scp)，然后发送命令来执行该脚本。

在紧急情况下，使用-T，并通过stdin提供命令，后面有一个退出命令，但请注意，如果您还需要交互功能，则使用-tt代替-T可能不起作用。

尝试ssh -t -t(或简称ssh -tt)强制伪tty分配，即使stdin不是终端。

请参见:终止bash脚本执行的SSH会话

从ssh manpage:

-T      Disable pseudo-tty allocation.

-t      Force pseudo-tty allocation.  This can be used to execute arbitrary 
        screen-based programs on a remote machine, which can be very useful,
        e.g. when implementing menu services.  Multiple -t options force tty
        allocation, even if ssh has no local tty.