variable d'environnement SSH ASKPASS ou askpass dans sudoers, resp
j'essaie de me connecter à un serveur ssh et d'exécuter quelque chose comme:
ssh user@domain.com 'sudo echo "foobar"'
malheureusement je reçois une erreur:
sudo: no tty present and no askpass program specified
Google m'a dit de définir la variable d'environnement SSH_ASKPASS set askpass dans le sudoers fichier. Ma machine distante tourne sur Debian 6 et j'ai installé les paquets ssh-askpass et ssh-askpass-gnome et mon sudoers le fichier ressemble à ceci:
Defaults env_reset
Defaults askpass=/usr/bin/ssh-askpass
# User privilege specification
root ALL=(ALL) ALL
user ALL=(ALL) ALL
quelqu'un Peut dire à ce que je fais mal et comment le faire mieux.
5 réponses
Il y a deux façons de se débarrasser de ce message d'erreur. La manière la plus simple est de fournir un pseudo terminal pour le processus sudo à distance. Vous pouvez le faire avec l'option -t:
ssh -t user@domain.com 'sudo echo "foobar"'
plutôt que d'attribuer un TTY, ou de définir un mot de passe qui peut être vu dans la ligne de commande, Faire quelque chose comme ça.
Créer un fichier shell qui se font l'écho de votre mot de passe de la forme:
#!/bin/bash
echo "mypassword"
alors copiez cela au noeud que vous voulez en utilisant scp comme ceci:
scp SudoPass.sh somesystem:~/bin
Puis, quand vous ssh procédez de la manière suivante:
ssh somesystem "export SUDO_ASKPASS=~/bin/SudoPass.sh;sudo -A command -parameter"
une Autre façon est de faire fonctionner sudo -S pour "écrire l'invite à l'erreur standard et lire le mot de passe à partir de l'entrée standard au lieu d'utiliser le terminal" (selon man) avec cat:
cat | ssh user@domain.com 'sudo -S echo "foobar"'
il suffit d'entrer le mot de passe lorsqu'on vous le demande.
un avantage est que vous pouvez rediriger la sortie de la commande à distance vers un fichier sans "[sudo] mot de passe pour ... " en elle:
cat | ssh user@domain.com 'sudo -S tar c --one-file-system /' > backup.tar
modifier décembre 2013: Voici une réponse plus courte: prenez un jour ou deux pour vous familiariser avec la bibliothèque Python "Tissu". Fabric résout une tonne de problèmes en ce qui concerne l'envoi de tâches à distance à un ou plusieurs serveurs.
vous voudrez probablement toujours configurer un nom d'utilisateur sur le système cible qui peut exécuter des commandes sans mot de passe (et vous pouvez utiliser Fabric pour le faire aussi!).
il suffit de se méfier que certains aspects du tissu ne sont pas parfaitement pythonique. Aussi, Tissu a été conçu d'abord avec les administrateurs de systèmes à l'esprit, les gens qui veulent des commandes par lots contre les serveurs. Si vous essayez de faire autre chose (comme automatiser certains serveurs ou scénarios très spécifiques), vous voudrez pleinement comprendre comment "with settings" et/ou le décorateur @roles fonctionne. Je n'ai pas regardé en arrière...
(Et oui, j'ai eu à distance SSH commandes de travail sur "remote". Le serveur A demande à B de serveur pour se connecter au serveur C, et le retour de la commande est vu sur le serveur d'Un même bien que A ne parle pas directement au serveur C. rend la configuration du laboratoire plus facile!).
réponse Originale: Il y a BEAUCOUP de solutions à ce problème. Les chevaux pour les courses; certains sont meilleurs que d'autres dans des situations différentes.
la question Est de savoir comment résoudre l'erreur" pas D'ATS". Cela semble être le point de mire, donc je suppose que la discussion au sujet de sudoers est juste une tentative de contournement pour éviter le problème D'ATS.
Option 1) la réponse D'Askhat fonctionne très bien... la plupart du temps. En fait, toujours spécifier "-tt" qui fonctionne sur plusieurs systèmes cibles.
Remarque: vous vont encore frapper le problème si vous utilisez SSH bibliothèque comme Paramiko, qui ne dispose pas d'un moyen intuitif de le faire "-t".
Option 2) Ma réponse est de spécifier un ASKPASS qui est de l'entrée standard. Donc cet exemple satisfait à la fois l'exigence sudo mot de passe et L'ATS: $ shell> ssh user@domain.com 'echo "mot de passe"|sudo -S echo "toto"'
Option 3) Oui, vous pouvez désactiver sudo vérification du mot de passe de tous ou de certains utilisateurs, mais ce n'est pas cool sur un serveur de production.
Option 4) Vous pouvez à distance "requiretty" (ou "!requiretty" pour tout ou partie des utilisateurs dans sudoers. Encore une fois, pas cool sur une boîte de production.
il est préférable d'éviter d'effectuer des changements de serveur. Un jour, ce serveur sera remplacé, les paramètres retournant par défaut, et votre script cessera de fonctionner.
Notez qu'une fois que vous comprenez toutes vos options, il ouvre les portes à beaucoup plus d'automatisation (par exemple un script sur votre ordinateur portable qui peut se connecter à une liste de noms de serveurs, et effectuer des tâches sudo sur ces serveurs sans que vous ayez besoin de copier lesdits scripts sur ces serveurs).
Que Diriez-vous d'ajouter ceci dans le fichier sudoers:
user ALL=(ALL) NOPASSWD: ALL