Bonjour,

J'utilise un programme en ligne de commande qui demande un mot de passe pour chiffrer des données. Je ne peux pas passer ce mot de passe en argument puisque ce n'est pas prévu pour. Or c'est ce que j'aurais besoin de faire dans le but de scripter mon programme.

Quand je lance ma ligne de commande, le programme me renvoit "Enter encryption key:" ou un truc du genre.
J'ai naïvement essayé de le transmettre avec un " | echo password " après ma ligne de commande, mais sans succès^^
Ma question est donc : comment faire pour que je puisse donner ce mot de passe sans nécessiter une intervention utilisateur ?

J'ai trouvé ca sur le net en rapport avec mon problème : "you can pipe a password into vnconfig, if you block it from opening /dev/tty, eg. with systrace. " Mais je ne vois pas ce que ca signifie... Si vous pouviez m'éclairer un peu

foo | bar

bar reçoit dans l'entrée standard ce que foo envoi dans la sortie standard donc ce que tu as fait ne peux pas fonctionner.

Tu fais joujou avec vnc ?

« Je ne peux pas passer ce mot de passe en argument puisque ce n'est pas prévu pour. » et heureusement que ce n'est pas prévu pour sinon ton mot de passe traînerait en clair dans ton historique.

Cela dit, faire "echo password | ton_prog" (tu pipais dans le mauvais sens visiblement) c'est tout aussi problématique du point de vue de la sécurité.

Bon, le coup du pipe dans le mauvais sens, on va mettre ca sur le coup du post 31 pas encore complètement oublié^^ Je pense bien que je l'ai fait dans ce sens en plus quand je faisais mes tests enfin...

Effectivement, je ne comprenais pas en quoi ca faisait une faille de sécu, cela dit c'est évident une fois que tu as souligné le problème.
Il y a un moyen d'effacer l'historique de façon sécurisée après ? (bof, quitte a essayer de faire un truc propre, autant le faire un peu correctement^^)

Et non je ne fais pas joujou avec vnc meme si on aurait pu croire (en fait je joue avec vnconfig qui n'a rien a voir avec vnc sinon ses 3 premières lettres ;) )

« Il y a un moyen d'effacer l'historique de façon sécurisée après ? » en vrai, je ne connais pas de moyen absolument propre à part lancer 10000 fois "ls" (mais ça flingue toute l'historique).

Sinon, c'est quoi vn ?

c'est du bsd, c'est pour ... je me permets de te mettre la man page d'open, elle expliquera mieux que moi : http://www.openbsd.org/cgi-bin/man.cgi?query=vnconfig&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

Sinon je me demandais : si je fait un script en autre chose qu'en shell (disons python par exemple...) : est-ce que je m'affranchis des problèmes d'historique meme si je fais appel à os.system("vnconfig blablabla")

Script python dont le lancement apparaîtra dans l'historique et qui contiendra le mot de passe en clair… à part ajouter connement* du python, ça ne change rien.

• : je n'aime pas python, et je haïs les gens qui nous imposent d'installer python juste pour lancer un pauvre script qui aurait été tout aussi bien fait en shell.

Pour ton problème de mot de passe, il n'y a pas d'autre solution que de taper le mot de passe à la main.

"Pour ton problème de mot de passe, il n'y a pas d'autre solution que de taper le mot de passe à la main."

Il y a plein de programme qui prennent les mdp sur l'entree standard et donc une redirection fonction ou alors qui peut lire le mdp depuis un fichier ce qui peut eviter d'autre utilisateurs de lire de mdp.

"je n'aime pas python, et je haïs les gens qui nous imposent d'installer python juste pour lancer un pauvre script qui aurait été tout aussi bien fait en shell."

j'ai le probleme avec des physiciens qui ne connaissent rien d'autre que csh...

Si tu es sur du Open il vaut mieux utiliser softraid que vnconfig.

Après la plupart des programmes qui requièrent un mot de passe le lisent directement depuis /dev/tty, pas sûr qu'une redirection fonctionne (Open semble fallbacker sur stdin, néanmoins).

cf /usr/src/lib/libc/gen/readpassphrase.c :
61 /*
62 * Read and write to /dev/tty if available. If not, read from
63 * stdin and write to stderr unless a tty is required.
64 */

godrik: non, ça ne fait que décaler le problème : si ton mdp est dans un fichier, soit il est en clair dans ce fichier, soit il faut une clé de déchiffrement (aka mot de passe) pour lire le fichier.

Il existe un petit programme très simple pour ce genre de choses : expect http://expect.sourceforge.net/
Un exemple d'utilisation trouvé sur le web :

1. !/usr/local/bin/expect

spawn sftp -b cmdFile user@yourserver.com
expect "password:"
send "shhh!\n";
interact

J'ai hésité à répondre car c'est une solution dangereuse de gros goret à ne jamais utiliser. N'hésite pas à effacer ce post Chris_27 si tu estimes qu'il vaut mieux ne pas mettre en évidence ce genre de solution.

C'est bon, j'ai compris… il n'y a que moi qui tape ses mots de passe à chaque fois.

Non, il n'y a pas que toi...

À ma connaissance mettre un mdp sur la ligne de commande, ça ne pose pas trop de problème avec l'historique, parce que le fichier .bash_history à des droits du type 600 (et aussi, parce que dans mon .bashrc il y a un "unset HISTFILE" qui fait que de toutes manières rien n'est sauvegardé).

Par contre, les lignes de commandes sont lisibles par tout le monde dans /proc/pid/cmdline (chez moi ces fichiers sont 444). Donc il ne faut surtout pas passer des mot de passe sur la ligne de commande (sur une machine multi-utilisateur).

1. Chris_27 : "godrik: non, ça ne fait que décaler le problème : si ton mdp est dans un fichier, soit il est en clair dans ce fichier, soit il faut une clé de déchiffrement (aka mot de passe) pour lire le fichier."

Mais il est par contre possible de mettre en cache cette unique clef et/ou ce fichier crypté, qui contiendrait les mots de passes de tout les autres programmes qui ensuite lise leur mot de passe dans ce fichier plutôt que de le demander sur l'entrée standard. C'est relativement sûr et ça évite d'avoir à taper des mots de passe "à chaque fois" (il le faut une fois à chaque démarrage de session, à la gnome-keyring, gpg-agent ou autre).

Je pensais surtout que si le fichier de mdp n'est pas accessible par d'autre utilisateur, il ne reste que root et l'utilisateur qui y ont access. Que si root est verole tu es mort de toute facon et que si l'utilisateur est compris tu es probablement cuit de toute facon.

Il ne reste que les gens qui vont demonte mon laptop pour recuperer le disque dur. Si c'est un access a un service serieux ca peut etre problematique, mais je prefere tapper le mdp d'access aux services serieux.

Mais en effet ssh-agent fait des merveilles.

mmmmh...
Réaction par rapport au script python : je pensais demander le mot de passe dans le script python pour que justement celui ci n'apparaisse pas dans l'historique du shell.
Genre :
début pyhon
...
pass = demander mot de passe
os.system("vnconfig blabla"+pass)
fin python

Ce serait correct dans ce cas non ? et je pensais à python mais ca pourrait etre n'importe quoi d'autre qui permette de scripter sans etre enregistré dans l'historique.

Après il semble que ce ne soit pas trop possible dans le cas de mon problème. Je vais relire vos réponse demain parceque je suis pas trop sur d'avoir tout capté

Ce serait correct dans ce cas non ? non, ce n'est jamais correct d'utiliser python là où il ne sert à rien. (ceci valait pour perl ou autre bien entendu).

dnob700: tu as confiance en gnome-keyring toi ? Moi pas du tout.

mode redéterrage de topic...
le probleme avec expect, c'est également l'historique ou il y en a un autre ?

"le probleme avec expect" ?

Ha oui, le message de Sankukai que je n'avais pas effacé.
(Note pour moi-même : je savais bien que j'aurais du l'effacer…)

Le problème avec expect c'est que tu dois écrire ton mot de passe en clair dans un fichier. Alors certes, ce n'est pas l'historique de ton shell et tu peux sans doute t'arranger pour mettre des droits très restrictifs dessus, mais c'est quand même le mal à mon avis.