bash : automatiser une commande qui demande un mot de passe (2 fois)

7 réponses
Avatar
Francois Lafont
Bonjour à tous,

Je suis sous Debian Squeeze et par exemple j'ai une commande
grub-mkpasswd-pbkdf2 qui me permet de crypter un mot de passe, sachant
que je dois le saisir 2 fois :

$ grub-mkpasswd-pbkdf2
Enter password:
Reenter password:
Your PBKDF2 is grub.pbkdf2.sha512.10000.1FF183CB3C86623E2 etc...

Comment faire pour que, dans un script bash, on puisse lancer la
commande en lui fournissant le mot de passe (écrit en dur dans le
script) et éviter toute intervention de l'utilisateur ?

J'ai tenté ça :

{ echo 'toto'; echo 'toto'; } | grub-mkpasswd-pbkdf2

Pour injecter le mot de passe toto. Mais ça ne doit pas être tout à fait
correct, car quand je lance le script :

- des fois c'est instantané et tout semble ok.
- des fois, ça se bloque au niveau du « Reenter password: » pendant 3-4
secondes

Ce côté aléatoire n'est pas bon signe.

Merci de votre aide.



--
François Lafont

7 réponses

Avatar
Nicolas George
Francois Lafont , dans le message
<4f7749b5$0$21942$, a écrit :
J'ai tenté ça :

{ echo 'toto'; echo 'toto'; } | grub-mkpasswd-pbkdf2

Pour injecter le mot de passe toto. Mais ça ne doit pas être tout à fait
correct, car quand je lance le script :

- des fois c'est instantané et tout semble ok.
- des fois, ça se bloque au niveau du « Reenter password: » pendant 3-4
secondes



Chez moi ça marche. S'il y a un problème, c'est un bug dans grub-machin. Tu
peux essayer de voir si mettre un « sleep 0.1 » entre les deux echo améliore
les choses.
Avatar
Francois Lafont
Le 31/03/2012 22:40, Nicolas George a écrit :

Chez moi ça marche. S'il y a un problème, c'est un bug dans grub-machin. Tu
peux essayer de voir si mettre un « sleep 0.1 » entre les deux echo améliore
les choses.



Hélas, j'ai toujours cette durée d'exécution chaotique (parfois c'est
instantané parfois ça peut prendre 10 secondes ou plus). En moyenne, les
deux premières exécutions sont rapides et ensuite j'ai presque toujours
un blocage au moment de « Reenter password: ».

Par contre, j'ai remarqué un truc très bizarre. Avec ce code :

{
echo "toto"
echo "toto"
} | grub-mkpasswd-pbkdf2 -c 6 -l 6 -s 6


si je lance le script à plusieurs reprise (bash test.bash) d'abord à la
main la première fois, puis en utilisant la flèche du haut pour ne pas
ressaisir la commande les autres fois, alors j'ai ce blocage (durant de
5 à 30 secondes parfois) qui intervient au bout de la troisième
exécution environ.

En revanche, si au lieux d'utiliser la flèche du haut, je retape
systématiquement à la main la commande (bash test.bash) puis Entrée (je
m'autorise la touche Tab pour l'autocomplétion), alors là le blocage ne
se produit tout simplement jamais. J'ai fait l'expérience suffisamment
de fois pour pouvoir dire que ce n'était pas des coïncidences.

Voilà. Franchement, si vous avez une explication sur cette bizarrerie...
(Je suis sur un gnome-terminal).


--
François Lafont
Avatar
Francois Lafont
Le 31/03/2012 22:40, Nicolas George a écrit :

S'il y a un problème, c'est un bug dans grub-machin.



En même temps, si c'est un souci du côté de la commande grub-machin,
alors dans ce cas, ça ne vaut peut-être pas le coup de se casser la tête.

Je constate en effet que le même schéma :

{
echo "toto"
echo "toto"
} | bash mdp.bash

fonctionne parfaitement dans le cas où mdp.bash est

printf "Votre mot de passe : "
read -s -r mdp1
printf 'n'
printf "Votre mot de passe à nouveau : "
read -s -r mdp2
printf 'n'

if [ "$mdp1" = "$mdp2" ]; then
echo "Ok. Blabla blabla."
else
echo "Problème."
fi

Du coup, si le schéma fonctionne dans ce cas, on peut pet-être imaginer
que grub-machin n'est effectivement pas tout à fait clair.


--
François Lafont
Avatar
YBM
Le 01.04.2012 02:08, Francois Lafont a écrit :
Du coup, si le schéma fonctionne dans ce cas, on peut pet-être imaginer
que grub-machin n'est effectivement pas tout à fait clair.



Clairement, avec expect qui simule un terminal complet on constate le
même phénomène bizarre : un coup ça, un coup non... Alors qu'avec le
bon vieux grub-md5-crypt ça marche parfaitement.


expect -c 'spawn grub-mkpasswd-pbkdf2 -c 6 -l 6 -s 6;
expect "password: "; send "totor"; expect "password: ";
send "totor"; expect eof;'
Avatar
Francois Lafont
Le 01/04/2012 13:35, YBM a écrit :

Clairement, avec expect qui simule un terminal complet on constate le
même phénomène bizarre : un coup ça, un coup non... Alors qu'avec le
bon vieux grub-md5-crypt ça marche parfaitement.


expect -c 'spawn grub-mkpasswd-pbkdf2 -c 6 -l 6 -s 6;
expect "password: "; send "totor"; expect "password: ";
send "totor"; expect eof;'



Merci pour la confirmation. Je ne vais pas insister du coup.

--
François Lafont
Avatar
Arnaud Gomes-do-Vale
Francois Lafont writes:

si je lance le script à plusieurs reprise (bash test.bash) d'abord à la
main la première fois, puis en utilisant la flèche du haut pour ne pas
ressaisir la commande les autres fois, alors j'ai ce blocage (durant de
5 à 30 secondes parfois) qui intervient au bout de la troisième
exécution environ.

En revanche, si au lieux d'utiliser la flèche du haut, je retape
systématiquement à la main la commande (bash test.bash) puis Entrée (je
m'autorise la touche Tab pour l'autocomplétion), alors là le blocage ne
se produit tout simplement jamais. J'ai fait l'expérience suffisamment
de fois pour pouvoir dire que ce n'était pas des coïncidences.

Voilà. Franchement, si vous avez une explication sur cette bizarrerie...
(Je suis sur un gnome-terminal).



Ça m'évoque furieusement un /dev/random vide et un générateur aléatoire
qui attend de l'entropie. Tu en génères en tapant au clavier, ce qui
explique que tu n'aies pas de problème en retapant la commande.

--
Arnaud
http://blogs.glou.org/arnaud/
Avatar
Arnaud Gomes-do-Vale
Francois Lafont writes:

Ça m'évoque furieusement un /dev/random vide et un générateur aléatoire
qui attend de l'entropie. Tu en génères en tapant au clavier, ce qui
explique que tu n'aies pas de problème en retapant la commande.



Sincèrement l'explication me dépasse un peu. Mais au moins est-on bien
bien d'accord que le script est correct et que c'est la commande
grub-mkpasswd-pbkdf2 qui est « foireuse » ?



Oui.

Pour le détail de l'explication, quand un processus a besoin d'entropie
(genre un outil de chiffrement qui doit bien utiliser des nombres
aléatoires à un moment ou à un autre), il peut aller en demander au
noyau en lisant des données dans /dev/random ; le processus reçoit alors
des données «garanties le plus aléatoires possible». Les données en
question sont générées par l'environnement extérieur «incontrôlable»,
genre l'activité réseau ou les frappes au clavier. Quand il n'y a pas
assez d'activité pour que le noyau dispose d'assez d'entropie, la
lecture bloque le temps qu'il faut ; je suis prêt à parier que c'est ce
qui t'arrive.

On peut éviter ce problème en lisant /dev/urandom plutôt que
/dev/random ; dans ce cas, la lecture réussit tout de suite, par contre,
s'il n'y a pas assez d'entropie, le processus reçoit des données connues
à la place (de mémoire des zéros). Du coup ça va plus vite mais c'est
«moins aléatoire» ; dans le cas d'outils de chiffrement, je comprends
qu'on évite cette approche.

--
Arnaud
http://blogs.glou.org/arnaud/