Pseudo-terminal will not be allocated because stdin is not a terminal

Question

I am trying to write a shell script that creates some directories on a remote server and then uses scp to copy files from my local machine onto the remote  Here s what I have so far   ssh -t user server lt  lt 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   Whenever I run it I get this message   Pseudo-terminal will not be allocated because stdin is not a terminal    And the script just hangs forever   My public key is trusted on the server and I can run all the commands outside of the script just fine  Any ideas

User · Answer

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 for ssh while stdin is redirected from a here document   Due to the lack of a specified command as an argument ssh 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  Redirecting ssh s stdin from a here document normally requires a command  such as  bin sh  to be specified as an argument to ssh - 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 as vim or top  the -t switch to ssh is superfluous  Just use ssh -T user server  lt  lt EOT     or ssh user server  bin bash  lt  lt EOT     and the warning will go away   If  lt  lt EOF is not escaped or single-quoted  i  e   lt  lt  EOT or  lt  lt  EOT   variables inside the here document will be expanded by the local shell before it is executing ssh      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 the ssh command  version 1 below   or  if  lt  lt  EOT or  lt  lt  EOT  is used  the output of the ssh command can be assigned to REL DIR if the only output of the ssh command to stdout is genererated by echo   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      version 1  unset DEP ROOT REL DIR DEP ROOT   tmp  datestamp   date   Y m d H M S  REL DIR    DEP ROOT    datestamp    ssh localhost  bin bash  lt  lt EOF if     -d   DEP ROOT     amp  amp      -e   DEP ROOT     then    echo  creating the root directory  1 gt  amp 2    mkdir   DEP ROOT  fi mkdir   REL DIR   echo   REL DIR  exit EOF  scp -r   dir1 user server   REL DIR  scp -r   dir2 user server   REL DIR      version 2  REL DIR     ssh localhost  bin bash  lt  lt  EOF DEP ROOT   tmp  datestamp   date   Y m d H M S  REL DIR    DEP ROOT    datestamp   if     -d   DEP ROOT     amp  amp      -e   DEP ROOT     then    echo  creating the root directory  1 gt  amp 2    mkdir   DEP ROOT  fi mkdir   REL DIR  echo   REL DIR  exit EOF     scp -r   dir1 user server   REL DIR  scp -r   dir2 user server   REL DIR      version 3  heredoc    cat  lt  lt  EOF    -onlcr  prevent the terminal from converting bare line feeds to carriage return line feed pairs stty -echo -onlcr DEP ROOT   tmp  datestamp    date   Y m d H M S   REL DIR    DEP ROOT    datestamp   if     -d   DEP ROOT     amp  amp      -e   DEP ROOT     then    echo  creating the root directory  1 gt  amp 2    mkdir   DEP ROOT  fi mkdir   REL DIR  echo   REL DIR  stty echo onlcr exit EOF     REL DIR    ssh -t localhost   heredoc     scp -r   dir1 user server   REL DIR  scp -r   dir2 user server   REL DIR

User · Answer

I don t know where the hang comes from  but redirecting  or piping  commands into an interactive ssh is in general a recipe for problems  It is more robust to use the command-to-run-as-a-last-argument style and pass the script on the ssh command line   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     All in one giant  -delimited multiline command-line argument    The pseudo-terminal message is because of your -t which asks ssh to try to make the environment it runs on the remote machine look like an actual terminal to the programs that run there  Your ssh client is refusing to do that because its own standard input is not a terminal  so it has no way to pass the special terminal APIs onwards from the remote machine to your actual terminal at the local end   What were you trying to achieve with -t anyway

User · Answer

All relevant information is in the existing answers  but let me attempt a pragmatic summary  tl dr   DO pass the commands to run using a command-line argument  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           Do NOT pass the commands via stdin  as is the case when you use a here-document  ssh jdoe server  lt  lt  EOF    Do NOT do this     EOF   Passing the commands as an argument works as-is  and   the problem with the pseudo-terminal will not even arise  you won t need an 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   By default  these commands run unattended  in an 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  quot Enter something   quot   echo  quot Entered    REPLY  quot    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  gt  amp 2         OK - stdout and stderr separate  ssh -t jdoe server  echo out  echo err  gt  amp 2         stdout   stderr - gt  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   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  lt  lt  lt  read -p  quot Enter something   quot   echo  quot Entered    REPLY  quot          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 trailing exit command  but note that if you also need interactive features  using -tt in lieu of -T may not work

User · Answer

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 your ssh 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 and sh  and probably other shells too  the simplest solution is to just combine ssh shell invocation with heredocs   ssh user server  bin bash  lt  lt  EOT  echo  These commands will be run on     uname -a    echo  They are executed by     whoami    EOT   Note that executing the above without  bin bash will result in the warning Pseudo-terminal will not be allocated because stdin is not a terminal   Also note that EOT is surrounded by single-quotes  so that bash recognizes the heredoc as a nowdoc  turning off local variable interpolation so that the command text will be passed as-is to ssh   If you are a fan of pipes  you can rewrite the above as follows   cat  lt  lt  EOT    ssh user server  bin bash echo  These commands will be run on     uname -a    echo  They are executed by     whoami    EOT   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   ssh user server     cat  lt  lt  EOT  echo  These commands will be run on     uname -a    echo  They are executed by     whoami    EOT      The solution above fixes this problem in the following manner    ssh user server is parsed by bash  and is interpreted to be the ssh command  followed by an argument user server to be passed to the ssh command   begins an interpolated string  which when completed  will comprise an argument to be passed to the ssh command  which in this case will be interpreted by ssh to be the remote command to execute as user server    begins a command to be executed  with the output being captured by the surrounding interpolated string cat is a command to output the contents of whatever file follows   The output of cat will be passed back into the capturing interpolated string  lt  lt  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 Any content that is encountered between  lt  lt  EOT  and  lt newline gt EOT lt newline gt  will be appended to the nowdoc output EOT terminates the nowdoc  resulting in a nowdoc temporary file being created and passed back to the calling cat 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 to ssh as a single command line argument  which ssh will interpret as the remote command to execute as user server   If you need to avoid using external tools like cat  and don t mind having two statements instead of one  use the read built-in with a heredoc to generate the SSH command   IFS    read -r -d    SSH COMMAND  lt  lt  EOT  echo  These commands will be run on     uname -a    echo  They are executed by     whoami    EOT  ssh user server    SSH COMMAND

User · Answer

I m adding this answer because it solved a related problem that I was having with the same error message   Problem  I had installed cygwin under Windows and was getting this error  Pseudo-terminal will not be allocated because stdin is not a terminal  Resolution  It turns out that I had not installed the openssh client program and utilities   Because of that cygwin was using the Windows implementation of ssh  not the cygwin version   The solution was to install the openssh cygwin package

User · Answer

After reading a lot of these answers I thought I would share my resulting solution  All I added is  bin bash before the heredoc and it doesn t give the error anymore    Use this    ssh user machine  bin bash  lt  lt  ENDSSH     hostname ENDSSH   Instead of this  gives error    ssh user machine  lt  lt  ENDSSH     hostname ENDSSH   Or use this    ssh user machine  bin bash  lt  run-command sh   Instead of this  gives error    ssh user machine  lt  run-command sh   EXTRA   If you still want a remote interactive prompt e g  if the script you re running remotely prompts you for a password or other information  because the previous solutions won t allow you to type into the prompts    ssh -t user machine     lt run-command sh     And if you also want to log the entire session in a file logfile log   ssh -t user machine     lt run-command sh     tee -a logfile log

User · Answer

Try ssh -t -t or ssh -tt for short  to force pseudo-tty allocation even if stdin isn t a terminal   See also  Terminating SSH session executed by bash script  From 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

User · Answer

I was having the same error under Windows using emacs 24 5 1 to connect to some company servers through  ssh user host  What solved my problem was setting the  tramp-default-method  variable to  plink  and whenever I connect to a server I ommit the ssh protocol  You need to have PuTTY s plink exe installed for this to work   Solution   M-x customize-variable  and then hit Enter  tramp-default-method  and then hit Enter again  On the text field put plink and then Apply and Save the buffer Whenever I try to access a remote server I now use C-x-f  user host  and then input the password  The connection is now correctly made under Emacs on Windows to my remote server

User · Answer

Also with option -T from manual     Disable pseudo-tty allocation

User · Answer

ssh -t foobar localhost yourscript pl

[linux] Pseudo-terminal will not be allocated because stdin is not a terminal

Examples related to linux

Examples related to bash

Examples related to shell

Examples related to ssh