ambiente set SSH_ASKPASS variabile o askpass in sudoers, resp

Question

Sto cercando di accedere a un server ssh ed eseguire qualcosa di simile:

ssh user@domain.com 'sudo echo "foobar"' 

Purtroppo sto ottenendo un errore:

sudo: no tty present and no askpass program specified 

Google mi ha detto di impostare la variabile di ambiente SSH_ASKPASS o di impostare askpass nel file sudoers. La mia macchina remota è in esecuzione su Debian 6 e ho installato i pacchetti ssh-askpass e ssh-askpass-gnome e il mio file sudoers assomiglia a questo:

Defaults  env_reset 
Defaults  askpass=/usr/bin/ssh-askpass 

# User privilege specification 
root ALL=(ALL) ALL 
user ALL=(ALL) ALL 

Qualcuno può dire quello che sto fare male e come farlo meglio

Answer 1

Ci sono due modi per sbarazzarsi di questo messaggio di errore. Il modo semplice è quello di fornire uno pseudo terminale per il processo sudo remoto. È possibile farlo con l'opzione -t:

ssh -t user@domain.com 'sudo echo "foobar"' 

Answer 2

ne dite di aggiungere questo nel file sudoers:

user ALL=(ALL) NOPASSWD: ALL 

Answer 3

EDIT dicembre 2013: Ecco una risposta più breve: prendere un giorno o due per familiarizzare con la libreria Python "Fabric". Fabric risolve un sacco di problemi per quanto riguarda l'invio di attività remote a 1 o più server.

Probabilmente vorrete ancora impostare un nome utente sul sistema di destinazione che possa eseguire comandi senza password (e potete usare anche Fabric per farlo!).

Basta fare attenzione che alcuni aspetti di Fabric non sono perfettamente Pythonic. Inoltre, Fabric è stato progettato innanzitutto per gli amministratori di sistema, le persone che desiderano eseguire comandi batch sui server. Se stai provando a fare qualcos'altro (come automatizzare alcuni server o scenari molto specifici), ti consigliamo di comprendere appieno come funzionano "con le impostazioni" e/o il decoratore @roles. Non ho guardato indietro ...

(E sì, ho ricevuto comandi SSH remoti che funzionano su sistemi "remoti", ovvero il server A chiede al server B di connettersi al server C, e il ritorno del comando è visto sul server A anche se A non parla direttamente al server C. Rende la configurazione di laboratorio più facile!).

Risposta originale: Esistono MOLTE soluzioni a questo problema. Cavalli per i corsi; alcuni sono migliori di altri in diverse situazioni.

La domanda posta è come risolvere l'errore "no TTY". Questo sembra essere l'obiettivo, quindi presumo che parlare di sudoers sia solo un tentativo di soluzione per evitare il problema TTY.

Opzione 1) La risposta di Askhat funziona alla grande ... il più delle volte. In realtà, specifica sempre "-tt" che funziona su più sistemi di destinazione.

Nota si continuerà a riscontrare il problema se si utilizza una libreria SSH come Paramiko, che non ha un modo intuitivo di fare "-t".

Opzione 2) La mia risposta - è specificare un ASKPASS che è STDIN.Quindi questo esempio soddisfa sia il requisito della password sudo sia il TTY: $ shell> ssh utente@dominio.com 'echo "password" | sudo -S echo "foobar"'

Opzione 3) Sì, è possibile disabilitare sudo controlli di password su tutti o alcuni utenti, ma non è bello su un server di produzione.

opzione 4) È possibile remoto "requiretty" (o impostare "! Requiretty" per tutti o alcuni utenti in sudoers. Anche in questo caso, non raffreddare su una casella di produzione.

E 'meglio evitare di fare modifiche al server. Un giorno quel server verrà sostituito, le impostazioni torneranno ai valori predefiniti e lo script smetterà di funzionare.

Nota che una volta comprese tutte le opzioni, si aprono le porte a un maggior numero di automazione (ad esempio una sceneggiatura sul tuo laptop che può connettersi a un elenco di nomi host di server ed eseguire attività sudo su quei server senza che sia necessario copiare detti script su quei server)

Answer 4

Piuttosto che assegnare un TTY o impostare una password che può essere vista nella riga di comando, fare qualcosa di simile.

Creare un file di shell che eco di rivelare la propria password come:

#!/bin/bash 

echo "mypassword" 

quindi copiare che al nodo che si desidera utilizzare scp come questo:

scp SudoPass.sh somesystem:~/bin 

Poi, quando si ssh effettuare le seguenti operazioni:

Answer 5

Un altro modo è eseguire sudo -S al fine di "Scrivere il prompt per l'errore standard e leggere la password dallo standard input invece di utilizzare il dispositivo terminale" (secondo man) insieme cat:

cat | ssh user@domain.com 'sudo -S echo "foobar"' 

Basta inserire la password quando viene richiesto a.

Un vantaggio è che è possibile reindirizzare l'output del comando remoto di un file senza "[sudo] password per ..." in esso:

cat | ssh user@domain.com 'sudo -S tar c --one-file-system /' > backup.tar