Bonjour,
je cherche à désactiver le chiffrement de ma partition système (sans perdre les données...). Car j'y ai mis forcément une passphrase.. et du coup quand je reboote la machine à distance... je suis obligé de me déplacer!!
ou bien est-ce que je peux supprimer la passphrase sur une partition? c'est possible?
j'ai utilisé :
cryptsetup addKey /dev/hda2
cryptsetup luksDelKey /dev/hda2 0
pour mettre une passphrase vide... mais lors du montage de cette partition au démarrage... je suis obligé de valider par "entrée" à la saisie de la passphrase
merci de l'info! bonne soirée
# Pas vraiment
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
Il y a peut être moyen par contre de modifier ce qui fait la demande au démarrage pour qu'il ne te demande plus, mais ca ca dépend de la distribution et tu ne l'as pas indiquée.
[^] # Re: Pas vraiment
Posté par JGO . Évalué à 2.
[^] # Re: Pas vraiment
Posté par zeycron . Évalué à 1.
la distribution c'est une debian lenny!
# Patch mécanique
Posté par maxix . Évalué à 5.
[^] # Re: Patch mécanique
Posté par GG (site web personnel) . Évalué à 6.
Une commande comme $eject cdrom0
ferait l'affaire.
Puis $eject -t cdrom0 pour arrêter d'appuyer sur la touche entrée.
Sinon, il reste le kvm.
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Patch mécanique
Posté par zeycron . Évalué à 0.
[^] # Re: Patch mécanique
Posté par auve . Évalué à 4.
http://thedailywtf.com/Articles/ITAPPMONROBOT.aspx
# clé usb (ou pas)
Posté par zerkman (site web personnel) . Évalué à 3.
En fait, je suppute que ce que tu veux crypter sont des données utilisateur, pas le système en lui-même. Tu peux donc très bien crypter uniquement la partition home, et mettre dessus tout ce qui est sensible (y compris une partie de /var qui contient les fichiers de bases de données, les sites web, etc). Comme ça tu peux rebooter. Il faudra juste monter le home à la main, mais c'est faisable à distance.
Enfin, cette dernière méthode a quand même un point faible si tu utilises une zone de swap sur disque. Le swap doit être aussi crypté, car il peut contenir une partie de tes données sensibles. C'est faisable en plaçant le swap et le home dans un LVM, protégé donc par un unique mot de passe. Dans ce cas, pour simplifier les choses, mieux vaut se faire un script pour tout monter d'un coup. Ou alors, une autre solution est de ne pas utiliser de swap du tout. Pour un serveur, le swap n'a de toutes façons pas vraiment d'intérêt.
[^] # Re: clé usb (ou pas)
Posté par totof2000 . Évalué à 2.
Pour ma part lorsque j'installe une machine, je me garde bien de mettre ce genre de truc direct sur /var : je crée un FS pour l'occasion, que je monte sur /var/quelque_chose.
[^] # Re: clé usb (ou pas)
Posté par totof2000 . Évalué à 3.
Qu'est-ce qu'il ne faut pas entendre (ou lire).
[^] # Re: clé usb (ou pas)
Posté par zerkman (site web personnel) . Évalué à 2.
[^] # Re: clé usb (ou pas)
Posté par totof2000 . Évalué à 2.
[^] # Re: clé usb (ou pas)
Posté par Obsidian . Évalué à 2.
Quelles sont ces applis et qu'est-ce qui justifie de garantir autant d'espace anonyme au point de se mettre en grève si ce n'est pas possible ?
[^] # Re: clé usb (ou pas)
Posté par totof2000 . Évalué à 2.
Une explication : man mmap
MAP_NORESERVE
Do not reserve swap space for this mapping. When swap space is reserved, one has the guarantee that it is possible to modify the
mapping. When swap space is not reserved one might get SIGSEGV upon a write if no physical memory is available. See also the
discussion of the file /proc/sys/vm/overcommit_memory in proc(5). In kernels before 2.6, this flag only had effect for private
writable mappings.
Je n'ai pas été confronté à ce problème sous Linux, mais j'ai déjà vu ça sur d'autres Unix proprios (serveur BDD Oracle + applicatif avec plus de 10 instances Oracle et grosse volumétrie derriere). L'espace swap est réservé mais pas utilisé.
[^] # Re: clé usb (ou pas)
Posté par zerkman (site web personnel) . Évalué à 2.
pour ce qui est deu mmap, le swap n'est nécessaire que si la RAM est saturée, car le principe de mmap, c'est exactement le même que le swap : un partie de la mémoire virtuelle est mappée dans un fichier. Si peu de ram est disponible, le noyau risque de faire plus souvent des accès disques pour synchroniser les pages en mémoire par rapport au fichier mappé, et c'est tout. après, si des systèmes font n'importe quoi avec le mmap, pour du serveur Linux perso on n'a pas à se soucier de cela.
# Key file
Posté par Thomas Bourdon (site web personnel) . Évalué à 4.
Sous slackware j'ai créé une key file que j'ai mis dans /boot (seule partition non chiffrée), puis j'ai ajouté cette clé à ma partition luks, ensuite pour créer mon initrd (genre de initramfs), j'ai précisé qu'il fallait déchiffré la partition avec cette key file et voilà :
1.
dd if=/dev/urandom of=/boot/keyfile bs=512 count=8
2.
cryptsetup luksAddkey /dev/sdxx /boot/keyfile
et pour déchiffrer :
cryptsetup -d /boot/keyfile luksOpen /dev/sdxx lukssdxx
En espérant que ça puisse t'aider.
[^] # Re: Key file
Posté par zeycron . Évalué à 1.
[^] # Re: Key file
Posté par Thomas Bourdon (site web personnel) . Évalué à 1.
# sys ?
Posté par bubar🦥 (Mastodon) . Évalué à 1.
pourquoi avoir chiffrer le système si la machine est fixe ? l'intérêt de chiffrer le système est surtout lorsque celui ci est mobile, sinon c'est remplacé par le contrôle d'accès. (contrôle d'accès à la salle, à la machine, voir ports usb, cd, etc...).
à distance :
création nouvelle partition
copie du système, modifs
création d'un initrd
have fun :)
# expect
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 1.
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: expect
Posté par ze_lionix (site web personnel) . Évalué à 2.
Il est ou expect ?
Sur la partition système qui est justement chiffrée et demande un mot de passe non ?
Fuse : j'en Use et Abuse !
# HOWTO: Unlock A LUKS Encrypted Root Partition Via SSH On Ubuntu
Posté par raboliot . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.