O pseudo-terminal não será alocado porque stdin não é um terminal

Estou tentando escrever um script de shell que cria alguns diretórios em um servidor remoto e, em seguida, usa o scp para copiar arquivos da minha máquina local para o controle remoto. Aqui está o que eu tenho até agora:

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

Sempre que o executo, recebo esta mensagem:

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

E o script trava para sempre.

Minha chave pública é confiável no servidor e posso executar todos os comandos fora do script. Alguma ideia?

Tente ssh -t -t(ou ssh -ttabrevie) forçar a alocação de pseudo-tty, mesmo que stdin não seja um terminal.

Consulte também: Terminando a sessão SSH executada pelo script bash

Na página de manual do ssh:

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

Também com opção -Tde manual

Desativar alocação de pseudo-tty

De acordo com a resposta do zanco , você não está fornecendo um comando remoto ssh, considerando como o shell analisa a linha de comando. Para resolver esse problema, altere a sintaxe da sua sshchamada de comando para que o comando remoto seja composto por uma cadeia de linhas multilinhas sintaticamente correta.

Há uma variedade de sintaxes que podem ser usadas. Por exemplo, como os comandos podem ser canalizados bashe sh, e provavelmente outros shells, a solução mais simples é combinar a sshchamada de shell com os heredocs:

ssh user@server /bin/bash <<'EOT'
echo "These commands will be run on: $( uname -a )"
echo "They are executed by: $( whoami )"
EOT

Observe que a execução acima sem /bin/bash resultará no aviso Pseudo-terminal will not be allocated because stdin is not a terminal. Observe também que EOTestá entre aspas simples, de modo que bashreconhece o heredoc como um nowoc , desativando a interpolação de variável local para que o texto do comando seja passado como está ssh.

Se você é um fã de pipes, pode reescrever o que foi dito acima, da seguinte maneira:

cat <<'EOT' | ssh user@server /bin/bash
echo "These commands will be run on: $( uname -a )"
echo "They are executed by: $( whoami )"
EOT

A mesma ressalva /bin/bashse aplica ao acima.

Outra abordagem válida é passar o comando remoto com várias linhas como uma única sequência, usando várias camadas de bashinterpolação de variáveis ​​da seguinte maneira:

ssh user@server "$( cat <<'EOT'
echo "These commands will be run on: $( uname -a )"
echo "They are executed by: $( whoami )"
EOT
)"

A solução acima corrige esse problema da seguinte maneira:

1. ssh user@serveré analisado pelo bash e é interpretado como o sshcomando, seguido por um argumento user@servera ser passado ao sshcomando

2. "inicia uma cadeia de caracteres interpolada que, quando concluída, compreenderá um argumento a ser passado para o sshcomando, que neste caso será interpretado sshcomo o comando remoto a ser executado comouser@server

3. $( inicia um comando a ser executado, com a saída sendo capturada pela sequência interpolada circundante

4. caté um comando para gerar o conteúdo de qualquer arquivo a seguir. A saída de catserá passada de volta para a sequência interpolada de captura

5. <<começa um heredoc da festança

6. 'EOT'especifica que o nome do heredoc é EOT. As aspas simples ao 'redor do EOT especificam que o heredoc deve ser analisado como um nowdoc , que é uma forma especial de heredoc na qual o conteúdo não é interpolado pelo bash, mas transmitido no formato literal

7. Qualquer conteúdo encontrado entre <<'EOT'e <newline>EOT<newline>será anexado à saída nowdoc

8. EOTfinaliza o nowdoc, resultando em um arquivo temporário do nowdoc sendo criado e transmitido de volta ao catcomando de chamada . catgera o nowdoc e passa a saída de volta para a sequência interpolada de captura

9. ) conclui o comando a ser executado

10. "conclui a captura da cadeia interpolada. O conteúdo da cadeia de caracteres interpolada será passado de volta para sshum único argumento de linha de comando, que sshinterpretará como o comando remoto para executar comouser@server

Se você precisar evitar o uso de ferramentas externas como cat, e não se importar de ter duas instruções em vez de uma, use o readbuilt-in com um heredoc para gerar o comando SSH:

IFS='' read -r -d '' SSH_COMMAND <<'EOT'
echo "These commands will be run on: $( uname -a )"
echo "They are executed by: $( whoami )"
EOT

ssh user@server "${SSH_COMMAND}"

Estou adicionando esta resposta porque resolveu um problema relacionado que eu estava tendo com a mesma mensagem de erro.

Problema : Instalei o cygwin no Windows e estava recebendo este erro:Pseudo-terminal will not be allocated because stdin is not a terminal

Resolução : Acontece que eu tinha não instalado o programa e os utilitários do openssh. Por esse motivo, o cygwin estava usando a implementação do ssh no Windows, não a versão do cygwin. A solução foi instalar o pacote openssh cygwin.

A mensagem de aviso Pseudo-terminal will not be allocated because stdin is not a terminal.deve-se ao fato de nenhum comando ser especificado sshenquanto o stdin é redirecionado de um documento aqui. Devido à falta de um comando especificado, o argumento sshprimeiro espera uma sessão de logon interativa (o que exigiria a alocação de um pty no host remoto), mas é necessário perceber que seu stdin local não é tty / pty. O redirecionamento de sshstdin de um documento aqui normalmente exige que um comando (como /bin/sh) seja especificado como argumento para ssh- e, nesse caso, nenhum pty será alocado no host remoto por padrão.

Como não há comandos a serem executados via sshque exijam a presença de um tty / pty (como vimou top) o -tcomutador para sshé supérfluo. Apenas usessh -T user@server <<EOT ... ou ssh user@server /bin/bash <<EOT ...e o aviso desaparecerá.

Se <<EOFnão for escapado ou as variáveis ​​de aspas simples ( <<\EOTou seja <<'EOT') dentro do documento aqui serão expandidas pelo shell local antes de serem executadas ssh .... O efeito é que as variáveis ​​contidas no documento aqui permanecerão vazias porque são definidas apenas no shell remoto.

Portanto, se $REL_DIRdeve ser acessível pelo shell local e definido no shell remoto, $REL_DIRdeve ser definido fora do documento aqui antes do sshcomando ( versão 1 abaixo); ou, se <<\EOTou <<'EOT'é usado, a saída do sshcomando pode ser atribuído a REL_DIRse a única saída do sshcomando para stdout é genererated por echo "$REL_DIR"dentro do / documento único citado aqui (escapou versão 2 abaixo).

Uma terceira opção seria armazenar o documento aqui em uma variável e depois passá-la como argumento de comando para ssh -t user@server "$heredoc"( versão 3 abaixo).

E, por último, mas não menos importante, não seria uma má idéia verificar se os diretórios no host remoto foram criados com êxito (consulte: verifique se o arquivo existe no host remoto com 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 <<EOF
if [ ! -d "$DEP_ROOT" ] && [ ! -e "$DEP_ROOT" ]; then
   echo "creating the root directory" 1>&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 <<\EOF
DEP_ROOT='/tmp'
datestamp=$(date +%Y%m%d%H%M%S)
REL_DIR="${DEP_ROOT}/${datestamp}"
if [ ! -d "$DEP_ROOT" ] && [ ! -e "$DEP_ROOT" ]; then
   echo "creating the root directory" 1>&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 <<'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" ] && [ ! -e "$DEP_ROOT" ]; then
   echo "creating the root directory" 1>&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"

Todas as informações relevantes estão nas respostas existentes, mas deixe-me tentar um resumo pragmático :

tl; dr:

• Passe os comandos para execução usando um argumento de linha de comando :
  ssh jdoe@server '...'

  • '...' strings podem abranger várias linhas, para que você possa manter seu código legível mesmo sem o uso de um documento aqui:
    ssh jdoe@server ' ... '

• NÃO passe os comandos via stdin , como é o caso quando você usa um documento aqui :
  ssh jdoe@server <<'EOF' # Do NOT do this ... EOF

Passar os comandos como argumento funciona como está e:

• o problema com o pseudo-terminal nem sequer surgirá.
• você não precisará de uma exitdeclaração no final de seus comandos, porque a sessão será encerrada automaticamente após o processamento dos comandos.

Resumindo: passar comandos via stdin é um mecanismo que está em desacordo com ssho design e causa problemas que devem ser contornados.
Continue lendo, se você quiser saber mais.

Informações complementares opcionais:

sshO mecanismo de aceitação de comandos para execução no servidor de destino é um argumento da linha de comandos : o operando final (argumento não opcional) aceita uma sequência que contém um ou mais comandos shell.

• Por padrão, esses comandos são executados sem supervisão, em um shell não interativo , sem o uso de um terminal (pseudo) (opção -Timplícita), e a sessão termina automaticamente quando o último comando termina o processamento.

• Caso seus comandos exijam interação do usuário , como responder a um prompt interativo, você pode solicitar explicitamente a criação de um pty (pseudo-tty) , um pseudo terminal, que permita interagir com a sessão remota, usando o-t opção; por exemplo:

  • ssh -t jdoe@server 'read -p "Enter something: "; echo "Entered: [$REPLY]"'

  • Observe que o interativo read prompt funciona apenas corretamente com um pty, portanto, a -topção é necessária.

  • O uso de um pty tem um efeito colateral notável: stdout e stderr são combinados e ambos relatados via stdout ; em outras palavras: você perde a distinção entre saída regular e saída de erro; por exemplo:

    • 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

Na ausência deste argumento, sshcria um shell interativo - inclusive quando você envia comandos via stdin , que é onde o problema começa:

• Para um shell interativo , sshnormalmente aloca um pty (pseudo-terminal) por padrão, exceto se seu stdin não estiver conectado a um terminal (real).

  • Enviar comandos via stdin significa que ssho stdin não está mais conectado a um terminal, portanto, nenhum pty é criado e ssh avisa você de acordo :
    Pseudo-terminal will not be allocated because stdin is not a terminal.

  • Mesmo a -topção, cujo objetivo expresso é solicitar a criação de um pty, não é suficiente neste caso : você receberá o mesmo aviso.

    • Um pouco curiosamente, você deve dobrar a -topção de forçar a criação de um pty: ssh -t -t ...ou ssh -tt ...mostra que você realmente, realmente quer dizer isso .

    • Talvez a justificativa para exigir essa etapa muito deliberada seja que as coisas podem não funcionar como o esperado . Por exemplo, no macOS 10.12, o aparente equivalente do comando acima, fornecendo os comandos via stdin e usando -tt, não funciona corretamente; a sessão fica presa após responder ao readprompt:
      ssh -tt jdoe@server <<<'read -p "Enter something: "; echo "Entered: [$REPLY]"'

No caso improvável de que os comandos que você deseja passar como argumento tornem a linha de comando muito longa para o seu sistema (se o comprimento se aproximar getconf ARG_MAX- consulte este artigo ), considere primeiro copiar o código para o sistema remoto na forma de um script ( usando, por exemplo, scp) e envie um comando para executar esse script.

Em uma pitada, use -Te forneça os comandos via stdin , com um exitcomando à direita , mas observe que se você também precisar de recursos interativos, o uso -ttno lugar de -Tpode não funcionar.

Não sei de onde vem o travamento, mas redirecionar (ou canalizar) comandos para um ssh interativo geralmente é uma receita para problemas. É mais robusto usar o estilo de comando para executar como último argumento e passar o script na linha de comando 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'

(Tudo em um gigante ' único argumento de linha de comando multilinha e delimitado).

A mensagem do pseudo-terminal é por causa da sua, -tque pede ao ssh para tentar fazer com que o ambiente em que é executado na máquina remota pareça um terminal real para os programas que são executados lá. Seu cliente ssh está se recusando a fazer isso porque sua própria entrada padrão não é um terminal, portanto, não há como passar as APIs especiais do terminal da máquina remota para o seu terminal real na extremidade local.

O que você estava tentando alcançar de -tqualquer maneira?

Depois de ler muitas dessas respostas, pensei em compartilhar minha solução resultante. Tudo o que eu adicionei é /bin/bashantes do heredoc e ele não dá mais o erro.

Usa isto:

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

Em vez disso (dá erro):

ssh user@machine <<'ENDSSH'
   hostname
ENDSSH

Ou use isto:

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

Em vez disso (dá erro):

ssh user@machine < run-command.sh

EXTRA :

Se você ainda deseja um prompt interativo remoto, por exemplo, se o script que você está executando remotamente solicitar uma senha ou outras informações, porque as soluções anteriores não permitirão que você digite os prompts.

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

E se você também deseja registrar a sessão inteira em um arquivo logfile.log:

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

Eu estava tendo o mesmo erro no Windows usando o emacs 24.5.1 para conectar-se a alguns servidores da empresa por meio de / ssh: user @ host. O que resolveu meu problema foi definir a variável "tramp-default-method" como "plink" e sempre que eu me conecto a um servidor, omito o protocolo ssh. Você precisa ter o plink.exe do PuTTY instalado para que isso funcione.

Solução

1. Mx customize-variable (e pressione Enter)
2. tramp-default-method (e depois pressione Enter novamente)
3. No campo de texto, coloque plink e, em seguida, aplique e salve o buffer
4. Sempre que tento acessar um servidor remoto, agora uso Cxf / user @ host: e insiro a senha. Agora a conexão foi feita corretamente no Emacs no Windows para o meu servidor remoto.

ssh -t foobar @ localhost seu script.pl