El pseudo-terminal no se asignará porque stdin no es un terminal

Estoy tratando de escribir un script de shell que crea algunos directorios en un servidor remoto y luego usa scp para copiar archivos de mi máquina local en el control remoto. Esto es lo que tengo hasta ahora:

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

Cada vez que lo ejecuto me sale este mensaje:

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

Y el guión simplemente se cuelga para siempre.

Mi clave pública es de confianza en el servidor y puedo ejecutar todos los comandos fuera del script muy bien. ¿Algunas ideas?

Intente ssh -t -t(o ssh -ttpara abreviar) forzar la asignación de pseudo-tty incluso si stdin no es una terminal.

Vea también: Terminar sesión SSH ejecutada por script bash

Desde la página de manual de 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.

También con opción -Tde manual

Deshabilitar la asignación de pseudo-tty

Según la respuesta de zanco , no está proporcionando un comando remoto ssh, dada la forma en que el shell analiza la línea de comando. Para resolver este problema, cambie la sintaxis de la sshinvocación de su comando para que el comando remoto esté compuesto por una cadena de varias líneas sintácticamente correcta.

Hay una variedad de sintaxis que se pueden usar. Por ejemplo, dado que los comandos se pueden canalizar bashy sh, y probablemente también en otros shells, la solución más simple es combinar la sshinvocación de shell con heredocs:

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

Tenga en cuenta que ejecutar lo anterior sin /bin/bash generará la advertencia Pseudo-terminal will not be allocated because stdin is not a terminal. También tenga en cuenta que EOTestá rodeado de comillas simples, por lo que bashreconoce el heredoc como un nowdoc , desactivando la interpolación de variables locales para que el texto del comando se pase como está a ssh.

Si eres fanático de las tuberías, puedes reescribir lo anterior de la siguiente manera:

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

La misma advertencia se /bin/bashaplica a lo anterior.

Otro enfoque válido es pasar el comando remoto de varias líneas como una sola cadena, utilizando múltiples capas de bashinterpolación variable de la siguiente manera:

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

La solución anterior soluciona este problema de la siguiente manera:

1. ssh user@serverbash lo analiza y se interpreta como el sshcomando, seguido de un argumento user@serverque se debe pasar al sshcomando

2. "comienza una cadena interpolada, que cuando se complete, comprenderá un argumento que se pasará al sshcomando, que en este caso se interpretará sshcomo el comando remoto para ejecutar comouser@server

3. $( comienza un comando que se ejecutará, con la salida capturada por la cadena interpolada circundante

4. cates un comando para generar el contenido del archivo que sigue. La salida de catse devolverá a la cadena interpolada de captura

5. <<comienza un golpe heredoc

6. 'EOT'especifica que el nombre del heredoc es EOT. Las comillas simples que 'rodean a EOT especifican que el heredoc debe analizarse como un nowdoc , que es una forma especial de heredoc en la que los contenidos no se interpolan por bash, sino que se transmiten en formato literal

7. Cualquier contenido que se encuentre entre <<'EOT'y <newline>EOT<newline>se agregará a la salida de nowdoc

8. EOTtermina el nowdoc, lo que da como resultado que se cree un archivo temporal de nowdoc y se lo devuelva al catcomando de llamada . catgenera el nowdoc y devuelve el resultado a la cadena interpolada de captura

9. ) concluye el comando a ejecutar

10. "concluye la cadena de captura interpolada. El contenido de la cadena interpolada se devolverá sshcomo un argumento de línea de comando único, que sshse interpretará como el comando remoto para ejecutar comouser@server

Si necesita evitar el uso de herramientas externas como cat, y no le importa tener dos declaraciones en lugar de una, use el readincorporado con un heredoc para generar el 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}"

Estoy agregando esta respuesta porque resolvió un problema relacionado que estaba teniendo con el mismo mensaje de error.

Problema : instalé cygwin en Windows y recibí este error:Pseudo-terminal will not be allocated because stdin is not a terminal

Resolución : Resulta que me había no instalado el programa cliente OpenSSH y los servicios públicos. Debido a que Cygwin estaba usando la implementación de Windows de ssh, no la versión de Cygwin. La solución fue instalar el paquete openssh cygwin.

El mensaje de advertencia Pseudo-terminal will not be allocated because stdin is not a terminal.se debe al hecho de que no se especifica ningún comando sshmientras stdin se redirige desde un documento aquí. Debido a la falta de un comando especificado como argumento, sshprimero se espera una sesión de inicio de sesión interactiva (que requeriría la asignación de una pty en el host remoto) pero luego debe darse cuenta de que su stdin local no es tty / pty. La redirección sshde la entrada estándar de un documento aquí normalmente requiere /bin/shque se especifique un comando (como ) como argumento para ssh, y en tal caso no se asignará pty en el host remoto de forma predeterminada.

Como no hay comandos para ejecutar sshque requieran la presencia de tty / pty (como vimo top), el -tcambio a sshes superfluo. Simplemente use ssh -T user@server <<EOT ...o ssh user@server /bin/bash <<EOT ...y la advertencia desaparecerá.

Si <<EOFno se escapa o las variables entre comillas simples (es decir, <<\EOTo <<'EOT') dentro del documento aquí serán expandidas por el shell local antes de ejecutarse ssh .... El efecto es que las variables dentro del documento aquí permanecerán vacías porque se definen solo en el shell remoto.

Por lo tanto, si $REL_DIRdebe ser accesible tanto por el shell local como definido en el shell remoto, $REL_DIRdebe definirse fuera del documento aquí antes del sshcomando ( versión 1 a continuación); o, si se usa <<\EOTo <<'EOT', sshse puede asignar REL_DIRla salida del sshcomando si la única salida del comando a stdout se genera echo "$REL_DIR"dentro del documento escapado / entre comillas simples ( versión 2 a continuación).

Una tercera opción sería almacenar el documento aquí en una variable y luego pasar esta variable como argumento de comando a ssh -t user@server "$heredoc"( versión 3 a continuación).

Y, por último, pero no menos importante, no sería una mala idea verificar si los directorios en el host remoto se crearon con éxito (consulte: verifique si el archivo existe en el host remoto con 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"

Toda la información relevante está en las respuestas existentes, pero permítame intentar un resumen pragmático :

tl; dr:

• DEBE pasar los comandos para ejecutar usando un argumento de línea de comandos :
  ssh jdoe@server '...'

  • '...' las cadenas pueden abarcar varias líneas, por lo que puede mantener su código legible incluso sin el uso de un documento aquí:
    ssh jdoe@server ' ... '

• NO pase los comandos a través de stdin , como es el caso cuando utiliza un documento aquí :
  ssh jdoe@server <<'EOF' # Do NOT do this ... EOF

Pasar los comandos como argumento funciona tal cual y:

• El problema con el pseudo-terminal ni siquiera surgirá.
• no necesitará una exitdeclaración al final de sus comandos, porque la sesión se cerrará automáticamente después de que se hayan procesado los comandos.

En resumen: pasar comandos a través de stdin es un mecanismo que está en desacuerdo con sshel diseño y causa problemas que luego deben solucionarse.
Sigue leyendo, si quieres saber más.

Información de antecedentes opcional:

sshEl mecanismo para aceptar comandos para ejecutar en el servidor de destino es un argumento de línea de comandos : el operando final (argumento sin opción) acepta una cadena que contiene uno o más comandos de shell.

• De manera predeterminada, estos comandos se ejecutan desatendidos, en un shell no interactivo , sin el uso de un (pseudo) terminal (opción -Timplícita), y la sesión finaliza automáticamente cuando el último comando finaliza el procesamiento.

• En el caso de que sus comandos requieran la interacción del usuario , como responder a una solicitud interactiva, puede solicitar explícitamente la creación de un pty (pseudo-tty) , un pseudo terminal, que permita interactuar con la sesión remota, utilizando la -topción; p.ej:

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

  • Tenga en cuenta que la readsolicitud interactiva solo funciona correctamente con una pty, por lo que -tse necesita la opción.

  • El uso de una pty tiene un efecto secundario notable: stdout y stderr se combinan y ambos se informan a través de stdout ; en otras palabras: pierde la distinción entre salida regular y salida de error; p.ej:

    • 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

En ausencia de este argumento, sshcrea un shell interactivo , incluso cuando envía comandos a través de stdin , que es donde comienza el problema:

• Para un shell interactivo , sshnormalmente asigna un pty (pseudo-terminal) por defecto, excepto si su stdin no está conectado a un terminal (real).

  • Enviar comandos a través de stdin significa que sshel stdin ya no está conectado a un terminal, por lo que no se crea pty, y ssh le advierte en consecuencia :
    Pseudo-terminal will not be allocated because stdin is not a terminal.

  • Incluso la -topción, cuyo propósito expreso es solicitar la creación de una pty, no es suficiente en este caso : obtendrá la misma advertencia.

    • Curiosamente, debe duplicar la -topción para forzar la creación de una empanada: ssh -t -t ...o ssh -tt ...muestra que realmente lo dice en serio .

    • Quizás la razón para requerir este paso tan deliberado es que las cosas pueden no funcionar como se esperaba . Por ejemplo, en macOS 10.12, el equivalente aparente del comando anterior, que proporciona los comandos a través de stdin y el uso -tt, no funciona correctamente; la sesión se atasca después de responder a la readsolicitud:
      ssh -tt jdoe@server <<<'read -p "Enter something: "; echo "Entered: [$REPLY]"'

En el improbable caso de que los comandos que desea pasar como argumento hagan que la línea de comandos sea demasiado larga para su sistema (si se acerca su longitud getconf ARG_MAX, consulte este artículo ), considere copiar primero el código al sistema remoto en forma de script ( usando, por ejemplo, scp), y luego enviar un comando para ejecutar ese script.

En caso de necesidad , utilice -Ty proporcione los comandos a través de stdin , con un exitcomando final , pero tenga en cuenta que si también necesita funciones interactivas, el uso -tten lugar de -Tpuede no funcionar.

No sé de dónde viene el bloqueo, pero la redirección (o canalización) de comandos a un ssh interactivo es, en general, una receta para los problemas. Es más robusto usar el estilo de comando para ejecutar como último argumento y pasar el script en la línea 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'

(Todo en un 'argumento de línea de comandos multilínea delimitado por gigantes ).

El mensaje de pseudo-terminal se debe a -tque le pide a ssh que intente hacer que el entorno que ejecuta en la máquina remota parezca un terminal real para los programas que se ejecutan allí. Su cliente ssh se niega a hacerlo porque su propia entrada estándar no es un terminal, por lo que no tiene forma de pasar las API especiales del terminal en adelante desde la máquina remota a su terminal real en el extremo local.

¿Qué estabas tratando de lograr de -ttodos modos?

Después de leer muchas de estas respuestas, pensé en compartir mi solución resultante. Todo lo que agregué está /bin/bashantes del heredoc y ya no da el error.

Utilizar este:

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

En lugar de esto (da error):

ssh user@machine <<'ENDSSH'
   hostname
ENDSSH

O usa esto:

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

En lugar de esto (da error):

ssh user@machine < run-command.sh

EXTRA :

Si aún desea un mensaje interactivo remoto, por ejemplo, si el script que está ejecutando de forma remota le solicita una contraseña u otra información, porque las soluciones anteriores no le permitirán escribir en los mensajes.

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

Y si también desea registrar toda la sesión en un archivo logfile.log:

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

Estaba teniendo el mismo error en Windows usando emacs 24.5.1 para conectarme a algunos servidores de la compañía a través de / ssh: user @ host. Lo que resolvió mi problema fue configurar la variable "método predeterminado de vagabundo" en "plink" y cada vez que me conecto a un servidor omito el protocolo ssh. Debe tener instalado Plink.exe de PuTTY para que esto funcione.

Solución

1. Mx personalizar-variable (y luego presionar Enter)
2. método predeterminado-vagabundo (y luego presione Enter nuevamente)
3. En el campo de texto, coloque plink y luego aplique y guarde el búfer
4. Cada vez que intento acceder a un servidor remoto, ahora uso Cxf / user @ host: y luego ingreso la contraseña. La conexión ahora se realiza correctamente bajo Emacs en Windows a mi servidor remoto.

ssh -t foobar @ localhost yourscript.pl