J'essaye de compiler quelques sources en utilisant un makefile. Dans le makefile, il y a un tas de commandes qui doivent être exécutées en tant que sudo.

Lorsque je compile les sources à partir d'un terminal, tout se passe bien et la création est interrompue la première fois qu'une sudocommande est exécutée en attendant le mot de passe. Une fois que j'ai tapé le mot de passe, faites des CV et terminez.

Mais j'aimerais pouvoir compiler les sources dans NetBeans. J'ai donc commencé un projet et montré à netbeans où trouver les sources, mais quand je compile le projet, il donne l'erreur:

sudo: no tty present and no askpass program specified

La première fois qu'il frappe une sudocommande.

J'ai recherché le problème sur Internet et toutes les solutions que j'ai trouvées pointent vers une chose: désactiver le mot de passe pour cet utilisateur. Puisque l'utilisateur en question ici est root. Je ne veux pas faire ça.

N 'y a-t-il pas une autre solution?

Accorder à l'utilisateur d'utiliser cette commande sans demander de mot de passe devrait résoudre le problème. Ouvrez d'abord une console shell et tapez:

sudo visudo

Modifiez ensuite ce fichier pour l'ajouter à la fin:

username ALL = NOPASSWD: /fullpath/to/command, /fullpath/to/othercommand

par exemple

john ALL = NOPASSWD: /sbin/poweroff, /sbin/start, /sbin/stop

permettra à l'utilisateur johnde sudo poweroff, startet stopsans être invité pour le mot de passe.

Regardez en bas de l'écran pour les touches que vous devez utiliser dans visudo - ce n'est pas vi d'ailleurs - et quittez sans enregistrer au premier signe de problème. Avertissement de santé: la corruption de ce fichier aura de graves conséquences, modifiez-le avec soin!

Essayer:

1. Utilisez la NOPASSWDligne pour toutes les commandes, je veux dire:

   jenkins ALL=(ALL) NOPASSWD: ALL
   

2. Mettez la ligne après toutes les autres lignes du sudoersfichier.

Cela a fonctionné pour moi (Ubuntu 14.04).

Essayer:

ssh -t remotehost "sudo <cmd>"

Cela supprimera les erreurs ci-dessus.

Après toutes les alternatives, j'ai trouvé:

sudo -S <cmd>

L'option -S (stdin) oblige sudo à lire le mot de passe à partir de l'entrée standard au lieu du terminal.

La source

La commande ci-dessus nécessite toujours la saisie du mot de passe. Pour supprimer la saisie du mot de passe manuellement, dans des cas comme jenkins, cette commande fonctionne:

echo <password> | sudo -S <cmd> 

sudopar défaut lira le mot de passe depuis le terminal connecté. Votre problème est qu'aucun terminal n'est connecté lorsqu'il est exécuté à partir de la console Netbeans. Vous devez donc utiliser une autre manière d'entrer le mot de passe: c'est le programme askpass .

Le programme askpass n'est pas un programme particulier, mais tout programme pouvant demander un mot de passe. Par exemple, dans mon système x11-ssh-askpassfonctionne bien.

Pour ce faire, vous devez spécifier le programme à utiliser, soit avec la variable d'environnement, SUDO_ASKPASSsoit dans le sudo.conffichier (voir man sudopour plus de détails).

Vous pouvez forcer sudoà utiliser le programme askpass en utilisant l'option -A. Par défaut, il ne l'utilisera que s'il n'y a pas de terminal connecté.

Pour les utilisateurs d'Ubuntu 16.04

Il y a un fichier avec lequel vous devez lire:

cat /etc/sudoers.d/README

Placer un fichier avec le mode 0440 dans /etc/sudoers.d/myuser avec le contenu suivant:

myuser  ALL=(ALL) NOPASSWD: ALL

Devrait résoudre le problème.

N'oublie pas de:

chmod 0440 /etc/sudoers.d/myuser

Essaye celui-là:

echo '' | sudo -S my_command

Si par hasard vous êtes venu ici parce que vous ne pouvez pas sudo à l'intérieur d'Ubuntu fourni avec Windows10

1. Modifiez le fichier / etc / hosts à partir de Windows (avec le Bloc-notes), il sera situé dans %localappdata\lxss\rootfs\etc:, ajoutez 127.0.0.1 WINDOWS8, cela supprimera la première erreur selon laquelle il ne peut pas trouver l'hôte.

2. Pour vous débarrasser de l' no tty presenterreur, faites toujourssudo -S <command>

Connectez-vous à votre Linux. Déclenchez les commandes suivantes. Soyez prudent, car l'édition sudoer est une proposition risquée.

$ sudo visudo

Une fois l'éditeur vi ouvert, apportez les modifications suivantes:

1. Commenter Defaults requiretty

   # Defaults    requiretty
   

2. Allez à la fin du fichier et ajoutez

   jenkins ALL=(ALL) NOPASSWD: ALL
   

À Jenkins :

echo '<your-password>' | sudo -S command

Par exemple : -

echo '******' | sudo -S service nginx restart

Vous pouvez utiliser le plugin Mask Password pour masquer votre mot de passe

Cela a fonctionné pour moi:

echo "myuser ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

où votre utilisateur est "myuser"

pour une image Docker, ce serait juste:

RUN echo "myuser ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

Assurez-vous que la commande que vous utilisez sudofait partie de votre PATH.

Si vous avez une seule sudoersentrée de commande (ou plusieurs, mais pas TOUS) , vous obtiendrez le sudo: no tty present and no askpass program specifiedlorsque la commande ne fait pas partie de votre chemin (et que le chemin complet n'est pas spécifié).

Vous pouvez le corriger en ajoutant la commande à votre PATHou en l'invoquant avec un chemin absolu, c'est-à-dire

sudo /usr/sbin/ipset

Au lieu de

sudo ipset

La commande sudoéchoue car elle essaie de demander le mot de passe root et aucune pseudo-tty n'est allouée (car elle fait partie du script).

Vous devez vous connecter en tant que root pour exécuter cette commande ou configurer les règles suivantes dans votre /etc/sudoers (ou:) sudo visudo:

# Members of the admin group may gain root privileges.
%admin  ALL=(ALL) NOPASSWD:ALL

Assurez-vous ensuite que votre utilisateur appartient au admingroupe (ou wheel).

Idéalement (plus sûr), il faudrait limiter les privilèges root uniquement à des commandes spécifiques qui peuvent être spécifiées comme %admin ALL=(ALL) NOPASSWD:/path/to/program

Je pense que je peux aider quelqu'un avec mon cas.

Tout d'abord, j'ai changé le paramètre utilisateur en me /etc/sudoersréférant à la réponse ci-dessus. Mais cela n'a toujours pas fonctionné.

myuser   ALL=(ALL) NOPASSWD: ALL
%mygroup  ALL=(ALL:ALL) ALL

Dans mon cas, myuserétait dans le mygroup.

Et je n'avais pas besoin de groupes. Donc, supprimé cette ligne.

(Ne devrait pas supprimer cette ligne comme moi, juste marquer le commentaire.)

myuser   ALL=(ALL) NOPASSWD: ALL

Ça marche!

L'exécution de scripts shell contenant des commandes sudo à partir de jenkins peut ne pas s'exécuter comme prévu. Pour résoudre ce problème, suivez

Étapes simples:

1. Sur les systèmes basés sur Ubuntu, exécutez "$ sudo visudo"

2. cela ouvrira le fichier / etc / sudoers.

3. Si votre utilisateur jenkins est déjà dans ce fichier, modifiez-le pour qu'il ressemble à ceci:

jenkins ALL = (ALL) NOPASSWD: TOUS

4. enregistrez le fichier

5. Relancez votre travail jenkins

6. vous ne devriez plus voir ce message d'erreur :)

J'ai pu le faire, mais assurez-vous de suivre les étapes correctement. C'est pour toute personne qui obtient des erreurs d'importation.

Étape 1 : Vérifiez si les fichiers et les dossiers ont un problème de permission d'exécution. Utilisation utilisateur Linux:

chmod 777 filename

Étape 2 : vérifiez quel utilisateur est autorisé à l'exécuter.

Étape 3 : ouvrez le terminal, tapez cette commande.

sudo visudo

ajoutez ces lignes au code ci-dessous

www-data ALL=(ALL) NOPASSWD:ALL
nobody ALL=(ALL) NOPASSWD:/ALL

il s'agit d'accorder la permission d'exécuter le script et de lui permettre d'utiliser toutes les bibliothèques. L'utilisateur est généralement «personne» ou «www-data».

éditez maintenant votre code comme

echo shell_exec('sudo -u the_user_of_the_file python your_file_name.py 2>&1');

allez au terminal pour vérifier si le processus est en cours, tapez ceci ici ...

ps aux | grep python

cela affichera tout le processus en cours d'exécution en python.

Modules complémentaires : utilisez le code ci-dessous pour vérifier les utilisateurs de votre système

cut -d: -f1 /etc/passwd

Merci!

Cette erreur peut également survenir lorsque vous essayez d'exécuter une commande de terminal (qui nécessite un mot de passe root) à partir d'un script non shell, par exemple sudo ls(dans les raccourcis) à partir d'un programme Ruby. Dans ce cas, vous pouvez utiliser l' utilitaire Expect ( http://en.wikipedia.org/wiki/Expect ) ou ses alternatives.
Par exemple, dans Ruby pour exécuter sudo lssans obtenir sudo: no tty present and no askpass program specified, vous pouvez exécuter ceci:

require 'ruby_expect'

exp = RubyExpect::Expect.spawn('sudo ls', :debug => true)
exp.procedure do
    each do
        expect "[sudo] password for _your_username_:" do
            send _your_password_
        end
    end
end

[ceci utilise l'une des alternatives à l' extension Expect TCL: ruby_expect gem].

Pour référence, au cas où quelqu'un d'autre rencontrerait le même problème, j'étais coincé pendant une bonne heure avec cette erreur qui ne devrait pas se produire puisque j'utilisais le paramètre NOPASSWD.

Ce que je ne savais PAS, c'est que sudo peut générer exactement le même message d'erreur lorsqu'il n'y a pas de tty et que la commande que l'utilisateur essaie de lancer ne fait pas partie de la commande autorisée dans le fichier / etc / sudoers.

Voici un exemple simplifié du contenu de mon fichier avec mon problème:

bguser ALL = NOPASSWD: \
    command_a arg_a, \
    command_b arg_b \
    command_c arg_c

Lorsque bguser tentera de lancer "sudo command_b arg_b" sans aucun tty (bguser étant utilisé pour certains démons), il rencontrera l'erreur "no tty present and no askpass program specified".

Pourquoi?

Parce qu'il manque une virgule à la fin de la ligne dans le fichier / etc / sudoers ...

(Je me demande même s'il s'agit d'un comportement attendu et non d'un bogue dans sudo car le message d'erreur correct pour un tel cas devrait être "Désolé, l'utilisateur bguser n'est pas autorisé à s'exécuter, etc.")

J'obtenais cette erreur parce que j'avais limité mon utilisateur à un seul «systemctl» exécutable et j'avais mal configuré le fichier visudo.

Voici ce que j'avais:

jenkins ALL=NOPASSWD: systemctl

Cependant, vous devez inclure le chemin d'accès complet à l'exécutable, même s'il se trouve sur votre chemin par défaut, par exemple:

jenkins ALL=NOPASSWD: /bin/systemctl

Cela permet à mon utilisateur jenkins de redémarrer les services mais ne pas avoir un accès root complet

Personne n'a dit ce qui pouvait provoquer cette erreur, en cas de migration d'un hôte à un autre, n'oubliez pas de vérifier le nom d'hôte dans le fichier sudoers:

Voici donc ma configuration / etc / sudoers

User_Alias      POWERUSER = user_name
Cmnd_Alias SKILL = /root/bin/sudo_auth_wrapper.sh
POWERUSER hostname=(root:root) NOPASSWD: SKILL

s'il ne correspond pas

uname -a
Linux other_hostname 3.10.17 #1 SMP Wed Oct 23 16:28:33 CDT 2013 x86_64 Intel(R) Core(TM) i3-4130T CPU @ 2.90GHz GenuineIntel GNU/Linux

il affichera cette erreur:

aucun tty présent et aucun programme askpass spécifié

Autres options, non basées sur NOPASSWD:

• Démarrez Netbeans avec le privilège root ((sudo netbeans) ou similaire) qui va vraisemblablement bifurquer le processus de construction avec root et donc sudo réussira automatiquement.
• Faites les opérations dont vous avez besoin pour faire suexec - faites-les appartenir à root et définissez le mode sur 4755. (Cela permettra bien sûr à n'importe quel utilisateur de la machine de les exécuter.) De cette façon, ils n'ont pas du tout besoin de sudo.
• La création de fichiers de disque dur virtuel avec des secteurs de démarrage ne devrait pas du tout avoir besoin de sudo. Les fichiers ne sont que des fichiers et les secteurs de démarrage ne sont que des données. Même la machine virtuelle ne devrait pas nécessairement avoir besoin de root, à moins que vous ne fassiez un transfert de périphérique avancé.

Peut-être que la question n'est pas claire: pourquoi aucune réponse ne la correspondait, mais j'ai eu le même message d'erreur lorsque j'essayais de monter sshfs, ce qui nécessitait sudo: la commande est quelque chose comme ceci:

sshfs -o sftp_server="/usr/bin/sudo /usr/lib/openssh/sftp-server" user@my.server.tld:/var/www /mnt/sshfs/www

en ajoutant l'option -o debug

sshfs -o debug -o sftp_server="/usr/bin/sudo /usr/lib/openssh/sftp-server" user@my.server.tld:/var/www /mnt/sshfs/www

J'ai eu le même message de cette question:

sudo: no tty present and no askpass program specified

Donc, en lisant les autres réponses, je suis devenu un fichier /etc/sudoer.d/usersur my.server.tld avec:

user ALL=NOPASSWD: /usr/lib/openssh/sftp-server

et maintenant je peux monter le disque sans donner trop de droits supplémentaires à mon utilisateur.

Bien que cette question soit ancienne, elle est toujours d'actualité pour mon système plus ou moins à jour. Après avoir activé le mode de débogage de sudo ( Debug sudo /var/log/sudo_debug all@infoin /etc/sudo.conf), j'ai été pointé sur / dev: " /dev is world writable". Vous devrez donc peut-être vérifier les autorisations du fichier tty , en particulier celles du répertoire dans lequel réside le nœud tty / pts.

1 ouvrez / etc / sudoers

type sudo vi /etc/sudoers. Cela ouvrira votre fichier en mode édition.

2 Ajouter / modifier un utilisateur Linux

Recherchez l'entrée pour l'utilisateur Linux. Modifiez comme ci-dessous si trouvé ou ajoutez une nouvelle ligne.

<USERNAME> ALL=(ALL) NOPASSWD: ALL

3 Enregistrer et quitter le mode édition

Si vous ajoutez cette ligne à votre /etc/sudoers(via visudo) cela résoudra ce problème sans avoir à désactiver la saisie de votre mot de passe et quand un alias pour sudo -Sne fonctionnera pas (appels de scripts sudo):

Defaults visiblepw

Bien sûr, lisez le manuel vous-même pour le comprendre, mais je pense que pour mon cas d'utilisation de l'exécution dans un conteneur LXD via lxc exec instance -- /bin/bashson assez sûr car il n'imprime pas le mot de passe sur un réseau.

Utilisation du pipeline:

echo your_pswd | sudo -S your_cmd

En utilisant ici-document:

sudo -S cmd <<eof
pwd
eof
#remember to put the above two lines without "any" indentations.

Ouvrez un terminal pour demander le mot de passe (celui qui fonctionne):

gnome-terminal -e "sudo cmd"

xterm -e "sudo cmd"