Quand on peut, c'est plus simple de chiffrer une partition complète (voire tout le disque) et d'utiliser le volume chiffré comme PV lvm, puis d'utiliser lvm comme d'habitude (dans l'installeur debian créer le volume chiffré sur l'espace dispo puis passer à la conf lvm). Attention, ça reste plus prudent de garder /boot hors chiffrement (mais swap est plutôt mieux chiffré, dans son lv).

Avantage :

• ça permettra de redimensionner ses lv
• ne demande la passphrase qu'une seule fois pour le volume

Si y'a un autre disque avec un autre volume chiffré mais que l'on ne veut pas taper deux passphrases, on peut la passphrase dans un fichier sur le premier volume chiffré (par ex dans /root/ en 600) et l'indiquer dans /etc/crypttab avec par ex

sdb1_crypt UUID=xxx /root/sda1_keyfile luks

où xxx est l'uuid de /dev/sda1 qui est le volume luks (blkid /dev/sda1 pour l'avoir).

Un exemple où on utilise une grosse partition (ou un disque entier) pour en faire un volume luks qui sera utilisé comme pv pour lvm. Ici il ne s'agit pas d'y mettre le système (ça c'est plus simple de le faire dans l'installeur debian, utiliser une partition comme volume chiffré puis le volume chiffré comme PV lvm).

# ici on va utiliser /dev/sda4
cryptsetup luksFormat /dev/sda4 --type luks2 
# on lui crée une clé
dd if=/dev/urandom of=/root/sda4_keyfile bs=1024 count=4
# que l'on protège
chmod 0400 /root/sda4_keyfile
# et ajoute au volume (en plus de la passphrase décidée à la création)
cryptsetup luksAddKey /dev/sda4 /root/sda4_keyfile
 
# on l'ouvre
cryptsetup luksOpen /dev/sda4 sda4_crypt
# et on peut l'utiliser pour lvm
pvcreate /dev/mapper/sda4_crypt
vgcreate hd /dev/mapper/sda4_crypt
# avec par ex ce lv
lvcreate -L 800G backup

Dans /etc/crypttab on ajoute (on trouve xxx avec blkid /dev/sda4

sda4_crypt UUID=xxx /root/sda4_keyfile luks

Et dans /etc/fstab

/dev/hd/backup /backup ext4 defaults 0 2

Ci dessous l'ancien contenu de cette page, qui commence à dater… (avant 2010)

Sous linux, luks et truecrypt permettent tous les deux de chiffrer des partitions. luks a l'air plus simple à mettre en place sur une debian de base, truecrypt permet le deni plausible (cf http://fr.wikipedia.org/wiki/TrueCrypt), luks permet d'avoir différentes clés d'accès (plusieurs utilisateurs qui montent la même partition, chacun avec son pass ou sa clé).

Cf un fil de debian-fr qui en parle http://lists.debian.org/debian-user-french/2009/03/msg00536.html (thread complet).

EncFs est une autre solution qui utilise fuse. Facile à mettre en place “over ssh”, permet à un user de monter des fichiers distants sans que le root du serveur puisse les lire, mais les fichiers sont “visibles” (avec des noms codés, mais on peut voir le nb de fichiers et leur taille).

Qqs liens :

• Tableau comparatif http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
• Site officiel trueCrypt : http://www.truecrypt.org/
• article wikipedia http://fr.wikipedia.org/wiki/TrueCrypt
• Un article sur truecrypt : http://www.projet-plume.org/fr/fiche/truecrypt
• Tuto luks partie 1 et partie 2, pour ubuntu http://doc.ubuntu-fr.org/cryptsetup et http://forum.ubuntu-fr.org/viewtopic.php?pid=372038
• article wikipedia (en) EncFs http://en.wikipedia.org/wiki/EncFS
• tuto EncFs ubuntu-fr http://doc.ubuntu-fr.org/encfs

Pour du backup online, sur une machine où vous avez un accès ssh, le couple sshfs/encfs peut-être adapté :

• Avantages
  • pas besoin de prévoir un gros fichier ou une partition dédiée coté serveur, pour accueillir les données chiffrées, seul la taille réelle des données est utilisée.
  • peu de conso CPU coté serveur, juste ssh
  • rien à installer coté serveur (hors serveur ssh, mais c'est en général la 1re chose installée)
  • permet de faire de l'incrémental comme un rsync sans chiffrement
• Inconvénients
  • un peu lent, mais je reste limité par ma connexion, à tester avec une meilleure connexion (~780kbps contre ~860kbps pour un rsync over ssh “ordinaire”)
  • le contenu et les noms des fichiers sont chiffrés, mais l'arborescence, les tailles de fichiers et les proprios sont visibles sur le serveur (les noms des dossiers sont incompréhensibles, mais vu le nombre et les tailles respectives, avec l'uid, on peut “deviner” lequel est un dossier utilisateur, lequel correspond à des photos ou de la musique, etc.), pas bien gênant pour moi mais…

C'est assez simple, vous trouverez pas mal de tutos sur le net en cherchant sshfs+encfs

Pour résumer, coté machine à backuper

# on installe sshfs et encfs (ça ajoute fuse), en root
aptitude install sshfs encfs
usermod -a -G fuse [utilisateur qui va monter les dossiers]
# puis avec le user qui fera le backup
sshfs $user@$serveur:/path/2/backup /un/dossier/local/pour/monter/sshfs -o uid=$(id -u) -o gid=$(id -g)
# en cas de pb de droits fuse, vérifier avec id que ce user fait bien parti du groupe fuse, se déloguer/reloguer sinon
encfs /un/dossier/local/pour/monter/sshfs /un/dossier/local/pour/sshfs/dechiffré
# lancer des rsync vers /un/dossier/local/pour/sshfs/dechiffré
# puis démonter
fusermount -u /un/dossier/local/pour/sshfs/dechiffré
fusermount -u /un/dossier/local/pour/monter/sshfs