instalar - establecer la variable de entorno SSH_ASKPASS o askpass en sudoers, resp

install ssh debian 8 (6)

Estoy intentando iniciar sesión en un servidor ssh y ejecutar algo como:

ssh [email protected] ''sudo echo "foobar"''

Desafortunadamente estoy recibiendo un error:

sudo: no tty present and no askpass program specified

Google me dijo que configurara la variable de entorno SSH_ASKPASS o que configurara el askpass de askpass en el archivo sudoers . Mi máquina remota se ejecuta en Debian 6 y he instalado los paquetes ssh-askpass y ssh-askpass-gnome y el archivo de mi sudoers tiene este aspecto:

Defaults env_reset Defaults askpass=/usr/bin/ssh-askpass # User privilege specification root ALL=(ALL) ALL user ALL=(ALL) ALL

¿Puede alguien decir lo que estoy haciendo mal y cómo hacerlo mejor?

Defaults askpass=/usr/bin/ssh-askpass

ssh-askpass requiere un servidor X, así que en lugar de proporcionar un terminal (a través de -t , como lo sugiere nosid), puede reenviar la conexión X a través de -X :

ssh -X [email protected] ''sudo echo "foobar"''

Sin embargo, según la documentación actual, askpass se establece en sudo.conf como Path , no en sudoers .

¿Qué hay de agregar esto en el archivo sudoers:

user ALL=(ALL) NOPASSWD: ALL

EDITAR Diciembre de 2013: Aquí hay una respuesta más corta: tómese uno o dos días para familiarizarse con la " Fabric " de la biblioteca de Python. Fabric resuelve muchos problemas relacionados con el envío de tareas remotas a 1 o más servidores.

Probablemente aún querrá configurar un nombre de usuario en el sistema de destino que pueda ejecutar comandos sin contraseña (¡y también puede usar Fabric para hacer eso!).

Solo ten en cuenta que algunos aspectos de Fabric no son perfectamente Pythonic. Además, Fabric se diseñó primero con los administradores de sistemas en mente, las personas que desean agrupar comandos en servidores. Si está intentando hacer otra cosa (como automatizar algunos servidores o escenarios muy específicos), querrá entender completamente cómo funciona "con la configuración" y / o el decorador de @roles. No he mirado atrás ...

(Y sí, tengo comandos SSH remotos que funcionan en sistemas "remotos". Es decir, el servidor A le pide al servidor B que se conecte al servidor C, y el comando A se ve en el servidor A aunque A no habla directamente servidor C. Facilita la configuración de laboratorio!).

Respuesta original: hay MUCHAS soluciones a este problema. Caballos de carreras; Algunos son mejores que otros en diferentes situaciones.

La pregunta que se hace es cómo resolver el error "no TTY". Ese parece ser el enfoque, así que asumo que hablar sobre los sudoers es solo un intento de solución para evitar el problema de TTY.

Opción 1) La respuesta de Askhat funciona muy bien ... la mayor parte del tiempo. En realidad, siempre especifique "-tt", que funciona en más sistemas de destino.

Tenga en cuenta que seguirá teniendo problemas si está utilizando una biblioteca SSH como Paramiko, que no tiene una forma intuitiva de hacer "-t".

Opción 2) Mi respuesta es especificar un ASKPASS que es STDIN. Por lo tanto, este ejemplo satisface tanto el requisito de contraseña sudo como TTY: $ shell> ssh [email protected] ''echo "contraseña" | sudo -S echo "foobar"''

Opción 3) Sí, puede deshabilitar las comprobaciones de contraseña de sudo en todos o algunos usuarios, pero eso no es bueno en un servidor de producción.

Opción 4) Puede usar "requiretty" (o configurar "! Requiretty" para todos o algunos de los usuarios de sudoers. Nuevamente, no está bien en una caja de producción.

Es mejor evitar hacer cambios en el servidor. Algún día ese servidor será reemplazado, la configuración volverá a los valores predeterminados y la secuencia de comandos dejará de funcionar.

Tenga en cuenta que una vez que comprenda todas sus opciones, abrirá las puertas a mucha más automatización (por ejemplo, una secuencia de comandos en su computadora portátil que puede conectarse a una lista de nombres de host de servidores y realizar tareas sudo en esos servidores sin que necesite copiarlos) scripts en esos servidores).

En lugar de asignar un TTY o configurar una contraseña que se puede ver en la línea de comandos, haga algo como esto.

Crea un archivo de shell que haga eco de tu contraseña como:

#!/bin/bash echo "mypassword"

luego cópialo al nodo que quieras usando scp como este:

scp SudoPass.sh somesystem:~/bin

Entonces cuando ssh haga lo siguiente:

ssh somesystem "export SUDO_ASKPASS=~/bin/SudoPass.sh;sudo -A command -parameter"

Hay dos formas de deshacerse de este mensaje de error. La forma más fácil es proporcionar un pseudo terminal para el proceso de sudo remoto. Puedes hacer esto con la opción -t :

ssh -t [email protected] ''sudo echo "foobar"''

Otra forma es ejecutar sudo -S para "Escribir el aviso al error estándar y leer la contraseña de la entrada estándar en lugar de usar el dispositivo terminal" (según man ) junto con cat :

cat | ssh [email protected] ''sudo -S echo "foobar"''

Simplemente ingrese la contraseña cuando se le solicite.

Una ventaja es que puede redirigir la salida del comando remoto a un archivo sin "[sudo] contraseña para ..." en él:

cat | ssh [email protected] ''sudo -S tar c --one-file-system /'' > backup.tar