¿Cuál es el beneficio de no asignar una terminal en ssh?

Pregunta:

De vez en cuando hago algo como

ssh user@host sudo thing

y me recuerda que ssh no asigna un pseudo-tty de forma predeterminada. ¿Por qué no lo hace? ¿Qué beneficios estaría perdiendo si asignara un alias de ssh a ssh -t ?

Respuesta:

La principal diferencia es el concepto de interactividad . Es similar a ejecutar comandos localmente dentro de un script, en lugar de escribirlos usted mismo. Es diferente en el sentido de que un comando remoto debe elegir un comando predeterminado y el no interactivo es lo más seguro. (y generalmente el más honesto)

STDIN

  • Si se asigna un PTY, las aplicaciones pueden detectarlo y saber que es seguro solicitar al usuario una entrada adicional sin romper cosas. Hay muchos programas que se saltan el paso de pedirle al usuario que ingrese información si no hay un terminal presente, y eso es bueno. De lo contrario, haría que los scripts se cuelguen innecesariamente.
  • Su entrada se enviará al servidor remoto mientras dure el comando. Esto incluye secuencias de control. Mientras que una interrupción de Ctrl-c normalmente causaría que un bucle en el comando ssh se interrumpa inmediatamente, sus secuencias de control se enviarán en su lugar al servidor remoto. Esto da como resultado la necesidad de "martillar" la pulsación de tecla para asegurarse de que llegue cuando el control abandone el comando ssh, pero antes de que comience el siguiente comando ssh.

Yo advertiría contra el uso de ssh -t en scripts desatendidos, como crons. Un shell no interactivo que pide a un comando remoto que se comporte de forma interactiva para la entrada está buscando todo tipo de problemas.

También puede probar la presencia de una terminal en sus propios scripts de shell. Para probar STDIN con versiones más recientes de bash:

# fd 0 is STDIN
[ -t 0 ]; echo $?

STDOUT

  • Al asignar un alias de ssh a ssh -t , puede esperar obtener un retorno de carro adicional en los extremos de su línea. Puede que no sea visible para usted, pero está ahí; aparecerá como ^M cuando se conecte a cat -e . Luego, debe realizar el esfuerzo adicional de asegurarse de que este código de control no se asigne a sus variables, especialmente si va a insertar esa salida en una base de datos.
  • También existe el riesgo de que los programas asuman que pueden generar resultados que no sean compatibles con la redirección de archivos. Normalmente, si tuviera que redirigir STDOUT a un archivo, el programa reconocería que su STDOUT no es una terminal y omitiría cualquier código de color. Si la redirección STDOUT es de la salida del cliente ssh y hay un PTY asociado con el extremo remoto del cliente, los programas remotos no pueden hacer tal distinción y terminará con basura de terminal en su archivo de salida. Redirigir la salida a un archivo en el extremo remoto de la conexión aún debería funcionar como se esperaba.

Aquí está la misma prueba de bash que antes, pero para STDOUT:

# fd 1 is STDOUT
[ -t 1 ]; echo $?

Si bien es posible solucionar estos problemas, inevitablemente se olvidará de diseñar scripts en torno a ellos. Todos lo hacemos en algún momento. Los miembros del equipo también no se dan cuenta / recordar que este alias está en su lugar, que a su vez crear problemas para que cuando escriben scripts que hacen uso de su alias.

Poner un alias de ssh a ssh -t es un caso en el que estarás violando el principio de diseño de la mínima sorpresa ; las personas se encontrarán con problemas que no esperan y es posible que no comprendan qué los está causando.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım