J'ai une partition chiffrée (par dmcrypt) qui est pour l'instant montée
au boot grace au /etc/crypttab.
Ca doit donc etre avec les extensions LUKS.
Je voudrais qu'elle soit désormais montée à la demande par
l'utilisateur, en utilisant cryptmount.
Makheureusement les doncs de cryptmount partent de 0 et documentent
comment créer la partition, en l'effaçant au passage. Existe-t-il un
moyen de faire la migration sans recopier totalement les fichiers en
clair pour les réécrire sur la partition désormais montée à l'aide de
cryptmount ?
Ou est-ce trop demander ?
Je connais mal cryptmount, mais de deux choses l'une:
J'ai une partition chiffrée (par dmcrypt) qui est pour l'instant montée
au boot grace au /etc/crypttab.
Ca doit donc etre avec les extensions LUKS.
Je voudrais qu'elle soit désormais montée à la demande par
l'utilisateur, en utilisant cryptmount.
Makheureusement les doncs de cryptmount partent de 0 et documentent
comment créer la partition, en l'effaçant au passage. Existe-t-il un
moyen de faire la migration sans recopier totalement les fichiers en
clair pour les réécrire sur la partition désormais montée à l'aide de
cryptmount ?
Ou est-ce trop demander ?
Je connais mal cryptmount, mais de deux choses l'une:
J'ai une partition chiffrée (par dmcrypt) qui est pour l'instant montée
au boot grace au /etc/crypttab.
Ca doit donc etre avec les extensions LUKS.
Je voudrais qu'elle soit désormais montée à la demande par
l'utilisateur, en utilisant cryptmount.
Makheureusement les doncs de cryptmount partent de 0 et documentent
comment créer la partition, en l'effaçant au passage. Existe-t-il un
moyen de faire la migration sans recopier totalement les fichiers en
clair pour les réécrire sur la partition désormais montée à l'aide de
cryptmount ?
Ou est-ce trop demander ?
Je connais mal cryptmount, mais de deux choses l'une:
On 2008-02-04, Erwan David wrote:
J'ai une partition chiffrée (par dmcrypt) qui est pour l'instant montée
au boot grace au /etc/crypttab.
Ca doit donc etre avec les extensions LUKS.Je voudrais qu'elle soit désormais montée à la demande par
l'utilisateur, en utilisant cryptmount.
Makheureusement les doncs de cryptmount partent de 0 et documentent
comment créer la partition, en l'effaçant au passage. Existe-t-il un
moyen de faire la migration sans recopier totalement les fichiers en
clair pour les réécrire sur la partition désormais montée à l'aide de
cryptmount ?
Ou est-ce trop demander ?
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
On 2008-02-04, Erwan David <erwan@rail.eu.org> wrote:
J'ai une partition chiffrée (par dmcrypt) qui est pour l'instant montée
au boot grace au /etc/crypttab.
Ca doit donc etre avec les extensions LUKS.
Je voudrais qu'elle soit désormais montée à la demande par
l'utilisateur, en utilisant cryptmount.
Makheureusement les doncs de cryptmount partent de 0 et documentent
comment créer la partition, en l'effaçant au passage. Existe-t-il un
moyen de faire la migration sans recopier totalement les fichiers en
clair pour les réécrire sur la partition désormais montée à l'aide de
cryptmount ?
Ou est-ce trop demander ?
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
On 2008-02-04, Erwan David wrote:
J'ai une partition chiffrée (par dmcrypt) qui est pour l'instant montée
au boot grace au /etc/crypttab.
Ca doit donc etre avec les extensions LUKS.Je voudrais qu'elle soit désormais montée à la demande par
l'utilisateur, en utilisant cryptmount.
Makheureusement les doncs de cryptmount partent de 0 et documentent
comment créer la partition, en l'effaçant au passage. Existe-t-il un
moyen de faire la migration sans recopier totalement les fichiers en
clair pour les réécrire sur la partition désormais montée à l'aide de
cryptmount ?
Ou est-ce trop demander ?
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)
non, le keyfile est une possibilité pas une obligation.
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)
non, le keyfile est une possibilité pas une obligation.
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)
non, le keyfile est une possibilité pas une obligation.
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)
non, le keyfile est une possibilité pas une obligation.
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)
non, le keyfile est une possibilité pas une obligation.
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)
non, le keyfile est une possibilité pas une obligation.
On 2008-02-04, Erwan David wrote:
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)
De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout
Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)
non, le keyfile est une possibilité pas une obligation.
On 2008-02-04, Erwan David <erwan@rail.eu.org> wrote:
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)
De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout
Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)
non, le keyfile est une possibilité pas une obligation.
On 2008-02-04, Erwan David wrote:
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)
De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout
Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)
non, le keyfile est une possibilité pas une obligation.
On 2008-02-04, Erwan David wrote:
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)
De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout
On 2008-02-04, Erwan David <erwan@rail.eu.org> wrote:
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)
De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout
On 2008-02-04, Erwan David wrote:
Je connais mal cryptmount, mais de deux choses l'une:
Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.
A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.
A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.
Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise
le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)
De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout
à tester donc, pour le prochain reboot...
Mais le man dit "tries=3" alors que le comportement n'est pas de
demander 3 fois le mot de passe. En fait tout se passe comme si le
script prenait n'importe quel mot de passe en le croyant correct, et que
le pla,tage se faisait plus tard lors du mount...
Ca ressemble a du cryptsetup bare-metal alors. (sans LUKS, quoi)
Comment lui faire vérifier que le mot de passe est correct doit venir
des paramètres check/checkargs, etc... Il faudrait que je joue avec,
mais la machine étant en production c'est pas facile de jouer.
Dans le cas ou tu as bien une partition chiffrée avec cryptsetup seul,
Par ailleurs le script sudo c'est crade de chez crade, et ça revient à
refaire en moins bien ce que fait cryptmount...
C'est un des arguments de cryptmount. Mais bon, je suis prêt à parier
Si ce n'est pas possible ça sera
tar cvjf|gpg du clair, démontage, refaire une partition utilisable avec
cryptmount et gpg|tar xvjf ensuite.
Long, mais marche (et backupe les données au passage).
Ce qui ne gache rien.
à tester donc, pour le prochain reboot...
Mais le man dit "tries=3" alors que le comportement n'est pas de
demander 3 fois le mot de passe. En fait tout se passe comme si le
script prenait n'importe quel mot de passe en le croyant correct, et que
le pla,tage se faisait plus tard lors du mount...
Ca ressemble a du cryptsetup bare-metal alors. (sans LUKS, quoi)
Comment lui faire vérifier que le mot de passe est correct doit venir
des paramètres check/checkargs, etc... Il faudrait que je joue avec,
mais la machine étant en production c'est pas facile de jouer.
Dans le cas ou tu as bien une partition chiffrée avec cryptsetup seul,
Par ailleurs le script sudo c'est crade de chez crade, et ça revient à
refaire en moins bien ce que fait cryptmount...
C'est un des arguments de cryptmount. Mais bon, je suis prêt à parier
Si ce n'est pas possible ça sera
tar cvjf|gpg du clair, démontage, refaire une partition utilisable avec
cryptmount et gpg|tar xvjf ensuite.
Long, mais marche (et backupe les données au passage).
Ce qui ne gache rien.
à tester donc, pour le prochain reboot...
Mais le man dit "tries=3" alors que le comportement n'est pas de
demander 3 fois le mot de passe. En fait tout se passe comme si le
script prenait n'importe quel mot de passe en le croyant correct, et que
le pla,tage se faisait plus tard lors du mount...
Ca ressemble a du cryptsetup bare-metal alors. (sans LUKS, quoi)
Comment lui faire vérifier que le mot de passe est correct doit venir
des paramètres check/checkargs, etc... Il faudrait que je joue avec,
mais la machine étant en production c'est pas facile de jouer.
Dans le cas ou tu as bien une partition chiffrée avec cryptsetup seul,
Par ailleurs le script sudo c'est crade de chez crade, et ça revient à
refaire en moins bien ce que fait cryptmount...
C'est un des arguments de cryptmount. Mais bon, je suis prêt à parier
Si ce n'est pas possible ça sera
tar cvjf|gpg du clair, démontage, refaire une partition utilisable avec
cryptmount et gpg|tar xvjf ensuite.
Long, mais marche (et backupe les données au passage).
Ce qui ne gache rien.
à tester donc, pour le prochain reboot...
Mais le man dit "tries=3" alors que le comportement n'est pas de
demander 3 fois le mot de passe. En fait tout se passe comme si le
script prenait n'importe quel mot de passe en le croyant correct, et que
le pla,tage se faisait plus tard lors du mount...
Ca ressemble a du cryptsetup bare-metal alors. (sans LUKS, quoi)Comment lui faire vérifier que le mot de passe est correct doit venir
des paramètres check/checkargs, etc... Il faudrait que je joue avec,
mais la machine étant en production c'est pas facile de jouer.
Dans le cas ou tu as bien une partition chiffrée avec cryptsetup seul,
tu peux tenter cette solution:
Tu peux reproduire le comportement sur une machine de test, ou la
machine elle meme:
dd if=/dev/zero of=/tmp/test.img bs24k count
losetup /dev/loop0 /tmp/test.img
cryptsetup create c_test /dev/loop0
(mot de passe a saisir)
mke2fs /dev/mapper/c_test
cryptsetup remove c_test
La tu dois etre dans ton cas. Une partition chiffrée avec cryptsetup
seul. Maintenant, est-ce que cryptmount sait le digérer?
Deuxieme etape: cree toi un nouveau fichier avec cryptmount, et
rigoureusement le meme mot de passe que celui créé au dessus.
Demontes tout avec cryptmount, edites le fichier pour le faire pointer
vers /tmp/test.img au lieu de ton image créée précedemment, remontes
avec cryptmount. Conclue.Par ailleurs le script sudo c'est crade de chez crade, et ça revient à
refaire en moins bien ce que fait cryptmount...
C'est un des arguments de cryptmount. Mais bon, je suis prêt à parier
qu'il est suid root, non?Si ce n'est pas possible ça sera
tar cvjf|gpg du clair, démontage, refaire une partition utilisable avec
cryptmount et gpg|tar xvjf ensuite.
Long, mais marche (et backupe les données au passage).
Ce qui ne gache rien.
à tester donc, pour le prochain reboot...
Mais le man dit "tries=3" alors que le comportement n'est pas de
demander 3 fois le mot de passe. En fait tout se passe comme si le
script prenait n'importe quel mot de passe en le croyant correct, et que
le pla,tage se faisait plus tard lors du mount...
Ca ressemble a du cryptsetup bare-metal alors. (sans LUKS, quoi)
Comment lui faire vérifier que le mot de passe est correct doit venir
des paramètres check/checkargs, etc... Il faudrait que je joue avec,
mais la machine étant en production c'est pas facile de jouer.
Dans le cas ou tu as bien une partition chiffrée avec cryptsetup seul,
tu peux tenter cette solution:
Tu peux reproduire le comportement sur une machine de test, ou la
machine elle meme:
dd if=/dev/zero of=/tmp/test.img bs24k count
losetup /dev/loop0 /tmp/test.img
cryptsetup create c_test /dev/loop0
(mot de passe a saisir)
mke2fs /dev/mapper/c_test
cryptsetup remove c_test
La tu dois etre dans ton cas. Une partition chiffrée avec cryptsetup
seul. Maintenant, est-ce que cryptmount sait le digérer?
Deuxieme etape: cree toi un nouveau fichier avec cryptmount, et
rigoureusement le meme mot de passe que celui créé au dessus.
Demontes tout avec cryptmount, edites le fichier pour le faire pointer
vers /tmp/test.img au lieu de ton image créée précedemment, remontes
avec cryptmount. Conclue.
Par ailleurs le script sudo c'est crade de chez crade, et ça revient à
refaire en moins bien ce que fait cryptmount...
C'est un des arguments de cryptmount. Mais bon, je suis prêt à parier
qu'il est suid root, non?
Si ce n'est pas possible ça sera
tar cvjf|gpg du clair, démontage, refaire une partition utilisable avec
cryptmount et gpg|tar xvjf ensuite.
Long, mais marche (et backupe les données au passage).
Ce qui ne gache rien.
à tester donc, pour le prochain reboot...
Mais le man dit "tries=3" alors que le comportement n'est pas de
demander 3 fois le mot de passe. En fait tout se passe comme si le
script prenait n'importe quel mot de passe en le croyant correct, et que
le pla,tage se faisait plus tard lors du mount...
Ca ressemble a du cryptsetup bare-metal alors. (sans LUKS, quoi)Comment lui faire vérifier que le mot de passe est correct doit venir
des paramètres check/checkargs, etc... Il faudrait que je joue avec,
mais la machine étant en production c'est pas facile de jouer.
Dans le cas ou tu as bien une partition chiffrée avec cryptsetup seul,
tu peux tenter cette solution:
Tu peux reproduire le comportement sur une machine de test, ou la
machine elle meme:
dd if=/dev/zero of=/tmp/test.img bs24k count
losetup /dev/loop0 /tmp/test.img
cryptsetup create c_test /dev/loop0
(mot de passe a saisir)
mke2fs /dev/mapper/c_test
cryptsetup remove c_test
La tu dois etre dans ton cas. Une partition chiffrée avec cryptsetup
seul. Maintenant, est-ce que cryptmount sait le digérer?
Deuxieme etape: cree toi un nouveau fichier avec cryptmount, et
rigoureusement le meme mot de passe que celui créé au dessus.
Demontes tout avec cryptmount, edites le fichier pour le faire pointer
vers /tmp/test.img au lieu de ton image créée précedemment, remontes
avec cryptmount. Conclue.Par ailleurs le script sudo c'est crade de chez crade, et ça revient à
refaire en moins bien ce que fait cryptmount...
C'est un des arguments de cryptmount. Mais bon, je suis prêt à parier
qu'il est suid root, non?Si ce n'est pas possible ça sera
tar cvjf|gpg du clair, démontage, refaire une partition utilisable avec
cryptmount et gpg|tar xvjf ensuite.
Long, mais marche (et backupe les données au passage).
Ce qui ne gache rien.