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

Eu não sei de onde vem o jeito, mas redirect (ou canalizar) comandos para um ssh interativo é, em geral, uma receita para problemas. É mais robusto usar o estilo comando-para-executar-como-um-ú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 argumento de linha de comando multilinha -limitado).

A mensagem do pseudo-terminal é por causa do seu -t que pede ao ssh para tentar fazer com que o ambiente que ele roda na máquina remota pareça um terminal real para os programas que rodam lá. Seu cliente ssh está se recusando a fazer isso porque sua própria input padrão não é um terminal, portanto, não tem como passar as APIs de terminais especiais da máquina remota para o terminal real no terminal local.

O que você estava tentando conseguir com isso?

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

tl; dr:

• NÃO passe os comandos para rodar usando um argumento de linha de comando :
  ssh jdoe@server '...'

  • '...' seqüências '...' caracteres 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 um argumento funciona como está e:

• o problema com o pseudo-terminal nem sequer surgirá.
• você não precisará de uma instrução de exit no final de seus comandos, porque a session será automaticamente encerrada depois que os comandos forem processados.

Resumindo: passar comandos via stdin é um mecanismo que está em desacordo com o design do ssh e causa problemas que precisam ser resolvidos.
Continue lendo, se você quiser saber mais.

Informação de fundo opcional:

O mecanismo do ssh para aceitar comandos para executar no servidor de destino é um argumento de linha de comando : o operando final (argumento não opcional) aceita uma cadeia contendo um ou mais comandos do shell.

• Por padrão, esses comandos são executados de forma autônoma, em um shell não interativo , sem o uso de um (pseudo) terminal (a opção -T está implícita), e a session termina automaticamente quando o último comando termina o processamento.

• No caso de seus comandos exigirem 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 permite interagir com a session remota, usando a opção -t ; por exemplo:

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

  • Observe que o prompt de read interativo só funciona corretamente com um arquivo, portanto, a opção -t é necessária.

  • Usar 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 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 desse argumento, o ssh cria um shell interativo - incluindo quando você envia comandos via stdin , que é onde o problema começa:

• Para um shell interativo , o ssh normalmente 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 o stdin do ssh não está mais conectado a um terminal, então nenhum pty é criado, e o ssh avisa da seguinte forma :
    Pseudo-terminal will not be allocated because stdin is not a terminal.

  • Mesmo a opção -t , cujo propósito expresso é solicitar a criação de um arquivo, não é suficiente neste caso : você receberá o mesmo aviso.

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

    • Talvez a justificativa para exigir esse passo muito deliberado é que as coisas podem não funcionar como esperado . Por exemplo, no macOS 10.12, o equivalente aparente do comando acima, fornecendo os comandos via stdin e usando -tt , não funciona corretamente; a session fica paralisada depois de responder ao prompt de read :
      ssh -tt jdoe@server <<<'read -p "Enter something: "; echo "Entered: [$REPLY]"'

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

Em um aperto, use -T e forneça os comandos via stdin , com um comando de exit à direita, mas observe que, se você também precisa de resources interativos, o uso de -tt no lugar de -T pode não funcionar.

Depois de ler muitas dessas respostas, pensei em compartilhar minha solução resultante. Tudo o que eu adicionei é /bin/bash antes do heredoc e 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 quiser um prompt interativo remoto, por exemplo, se o script que estiver executando remotamente solicitar uma senha ou outras informações, porque as soluções anteriores não permitirão que você digite nos prompts.

 ssh -t user@machine "$( 

 ssh -t user@machine "$(