bash : automatiser une commande qui demande un mot de passe (2 fois)
7 réponses
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 ?
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.
Francois Lafont , dans le message
<4f7749b5$0$21942$426a34cc@news.free.fr>, a écrit :
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.
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.
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 :
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
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 :
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).
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 :
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
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
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.
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
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.
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.
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.
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.
Merci pour la confirmation. Je ne vais pas insister du coup.
-- François 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.
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.
Merci pour la confirmation. Je ne vais pas insister du coup.
-- François Lafont
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.
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.
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.
Ç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.
Ç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.
Ç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.
