我正在尝试编写一个shell脚本,该脚本在远程服务器上创建一些目录,然后使用scp将文件从我的本地机器复制到远程服务器上。
ssh -t user@server<<EOT
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
exit
EOT
scp ./dir1 user@server:$REL_DIR
scp ./dir2 user@server:$REL_DIR
每当我运行它时,我都会收到以下消息:
Pseudo-terminal will not be allocated because stdin is not a terminal.
剧本就这样永远挂着。
我的公钥在服务器上是可信的,我可以运行脚本之外的所有命令。有什么想法吗?
9条答案
按热度按时间7kjnsjlb1#
尝试
ssh -t -t
(或简称为ssh -tt
)强制伪tty分配,即使stdin不是终端。另请参阅:Terminating SSH session executed by bash script
从ssh联机帮助页:
2o7dmzc52#
也可使用手册中的选件
-T
禁用伪tty分配
cnjp1d6j3#
Per zanco's answer , you're not providing a remote command to
ssh
, given how the shell parses the command line. To solve this problem, change the syntax of yourssh
command invocation so that the remote command is comprised of a syntactically correct, multi-line string.There are a variety of syntaxes that can be used. For example, since commands can be piped into
bash
andsh
, and probably other shells too, the simplest solution is to just combinessh
shell invocation with heredocs:Note that executing the above without
/bin/bash
will result in the warningPseudo-terminal will not be allocated because stdin is not a terminal
. Also note thatEOT
is surrounded by single-quotes, so thatbash
recognizes the heredoc as a nowdoc, turning off local variable interpolation so that the command text will be passed as-is tossh
.If you are a fan of pipes, you can rewrite the above as follows:
The same caveat about
/bin/bash
applies to the above.Another valid approach is to pass the multi-line remote command as a single string, using multiple layers of
bash
variable interpolation as follows:The solution above fixes this problem in the following manner:
ssh user@server
is parsed by bash, and is interpreted to be thessh
command, followed by an argumentuser@server
to be passed to thessh
command"
begins an interpolated string, which when completed, will comprise an argument to be passed to thessh
command, which in this case will be interpreted byssh
to be the remote command to execute asuser@server
$(
begins a command to be executed, with the output being captured by the surrounding interpolated stringcat
is a command to output the contents of whatever file follows. The output ofcat
will be passed back into the capturing interpolated string<<
begins a bash heredoc'EOT'
specifies that the name of the heredoc is EOT. The single quotes'
surrounding EOT specifies that the heredoc should be parsed as a nowdoc, which is a special form of heredoc in which the contents do not get interpolated by bash, but rather passed on in literal format<<'EOT'
and<newline>EOT<newline>
will be appended to the nowdoc outputEOT
terminates the nowdoc, resulting in a nowdoc temporary file being created and passed back to the callingcat
command.cat
outputs the nowdoc and passes the output back to the capturing interpolated string)
concludes the command to be executed"
concludes the capturing interpolated string. The contents of the interpolated string will be passed back tossh
as a single command line argument, whichssh
will interpret as the remote command to execute asuser@server
If you need to avoid using external tools like
cat
, and don't mind having two statements instead of one, use theread
built-in with a heredoc to generate the SSH command:kwvwclae4#
我之所以添加此答案,是因为它解决了我遇到的一个相关问题,该问题也出现了相同的错误消息。
Pseudo-terminal will not be allocated because stdin is not a terminal
xxe27gdn5#
All relevant information is in the existing answers, but let me attempt a pragmatic summary:
tl;dr:
ssh jdoe@server '...'
'...'
strings can span multiple lines, so you can keep your code readable even without the use of a here-document:ssh jdoe@server ' ... '
ssh jdoe@server <<'EOF' # Do NOT do this ... EOF
Passing the commands as an argument works as-is, and:
exit
statement at the end of your commands, because the session will automatically exit after the commands have been processed.In short: passing commands via stdin is a mechanism that is at odds with
ssh
's design and causes problems that must then be worked around.Read on, if you want to know more.
Optional background information:
ssh
's mechanism for accepting commands to execute on the target server is a command-line argument: the final operand (non-option argument) accepts a string containing one or more shell commands.-T
is implied), and the session automatically ends when the last command finishes processing.-t
option; e.g.:ssh -t jdoe@server 'read -p "Enter something: "; echo "Entered: [$REPLY]"'
read
prompt only works correctly with a pty, so the-t
option is needed.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
In the absence of this argument,
ssh
creates an interactive shell - including when you send commands via stdin, which is where the trouble begins:ssh
normally allocates a pty (pseudo-terminal) by default, except if its stdin is not connected to a (real) terminal.ssh
's stdin is no longer connected to a terminal, so no pty is created, andssh
warns you accordingly:Pseudo-terminal will not be allocated because stdin is not a terminal.
-t
option, whose express purpose is to request creation of a pty, is not enough in this case: you'll get the same warning.-t
option to force creation of a pty:ssh -t -t ...
orssh -tt ...
shows that you really, really mean it.-tt
, does not work properly; the session gets stuck after responding to theread
prompt:ssh -tt jdoe@server <<<'read -p "Enter something: "; echo "Entered: [$REPLY]"'
In the unlikely event that the commands you want to pass as an argument make the command line too long for your system (if its length approaches
getconf ARG_MAX
- see this article ), consider copying the code to the remote system in the form of a script first (using, e.g.,scp
), and then send a command to execute that script.In a pinch, use
-T
, and provide the commands via stdin, with a trailingexit
command, but note that if you also need interactive features, using-tt
in lieu of-T
may not work.tv6aics16#
The warning message
Pseudo-terminal will not be allocated because stdin is not a terminal.
is due to the fact that no command is specified forssh
while stdin is redirected from a here document. Due to the lack of a specified command as an argumentssh
first expects an interactive login session (which would require the allocation of a pty on the remote host) but then has to realize that its local stdin is no tty/pty. Redirectingssh
's stdin from a here document normally requires a command (such as/bin/sh
) to be specified as an argument tossh
- and in such a case no pty will be allocated on the remote host by default.Since there are no commands to be executed via
ssh
that require the presence of a tty/pty (such asvim
ortop
) the-t
switch tossh
is superfluous. Just usessh -T user@server <<EOT ...
orssh user@server /bin/bash <<EOT ...
and the warning will go away.If
<<EOF
is not escaped or single-quoted (i. e.<<\EOT
or<<'EOT'
) variables inside the here document will be expanded by the local shell before it is executingssh ...
. The effect is that the variables inside the here document will remain empty because they are defined only in the remote shell.So, if
$REL_DIR
should be both accessible by the local shell and defined in the remote shell,$REL_DIR
has to be defined outside the here document before thessh
command (version 1 below); or, if<<\EOT
or<<'EOT'
is used, the output of thessh
command can be assigned toREL_DIR
if the only output of thessh
command to stdout is genererated byecho "$REL_DIR"
inside the escaped/single-quoted here document (version 2 below).A third option would be to store the here document in a variable and then pass this variable as a command argument to
ssh -t user@server "$heredoc"
(version 3 below).And, last but not least, it would be no bad idea to check if the directories on the remote host were created successfully (see: check if file exists on remote host with ssh ).
polhcujo7#
我不知道挂起的原因是什么,但是将命令重定向(或管道)到交互式ssh中通常会导致问题。使用command-to-run-as-a-last-argument风格并在ssh命令行上传递脚本会更健壮:
(All在一个巨大的
'
分隔的多行命令行参数中)。伪终端消息是因为您的
-t
要求ssh尝试使它在远程机器上运行的环境看起来像是在那里运行的程序的实际终端。您的ssh客户端拒绝这样做,因为它 * 自己 * 的标准输入不是终端,所以它没有办法将特殊的终端API从远程机器传递到本地端的实际终端。你到底想用
-t
达到什么目的?t98cgbkg8#
在阅读了大量的答案后,我想我会分享我的结果解决方案。所有我添加的是
/bin/bash
之前的heredoc,它不会给予错误了。使用此选项:
而不是这样(给出错误):
或者使用以下命令:
而不是这样(给出错误):
额外:
如果您仍然需要远程交互式提示,例如,如果您正在远程运行的脚本提示您输入密码或其他信息,因为以前的解决方案不允许您在提示中键入。
如果您还想将整个会话记录在文件
logfile.log
中:2izufjch9#
我在Windows下使用emacs 24.5.1通过/ssh:user@host连接到一些公司服务器时遇到了同样的错误。解决我问题的方法是将"tramp-default-method"变量设置为"plink",每当我连接到服务器时,我都会忽略ssh协议。您需要安装PuTTY的plink.exe才能使其工作。
1.在文本字段中输入plink,然后应用并保存缓冲区
1.每当我尝试访问远程服务器时,我现在使用C-x-f/user@host:然后输入密码。现在在Windows上的Emacs下正确地建立了到我的远程服务器的连接。