J'ai récemment eu l'occasion de louer un serveur chez Online.net (filiale de Illiad) Voulant depuis pas mal de temps gérer un serveur sous FreeBSD (et tester bhyve) et n'ayant pour différentes raisons pas eu l'occasion de le faire sur mon serveur auto-hebergé ni sur ce serveur ci, j'ai commencé a chercher comment le faire sur ce serveur.

Étant donné que Online ne propose pas directement d'image FreeBSD sur ses serveurs, il m'a fallu chercher un peu plus loin. Il se trouve que ce post sur les forums d'online explique une procédure, mais celle-ci ne fonctionnait pas pour mon serveur en particulier.

J'ai donc cherché un peu sur internet, puis demandé sur irc (#freebsd-fr@freenode), ou l'on m'a dirigé vers mfsbsd, un projet d'installeur alternatif, minimaliste et simplifié pour FreeBSD.

Pour installer FreeBSD sur votre serveur, donc, il vous faudra accéder a une console KVM (dans mon cas personnel, iLO). Cela doit être faisable depuis le panel Online. Une fois cela fait, lancez une console, puis téléchargez l'image mfsbsd. Dans la console iLO, choisissez de booter sur une image CD/DVD, puis choisissez l'image mfsbsd. Ensuite, rebootez le serveur. Choisissez de booter sur l'image CD/DVD (F11 puis 1). Une fois ceci fait, un FreeBSD a l'air tout a fait classique va démarrer. Une fois ceci fait, la partie importante arrive: mfsbsd contient un script d'installation root-on-zfs, nommé logiquement zfsinstall, qui va se charger de tout le travail pour nous.

Utilisez donc ce script ainsi :

# tout d'abord, wipons le MBR :
dd < /dev/zero > /dev/da0 count=1
# maintenant, installons le système
zfsinstall -g da0 -u ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.0-RELEASE/ -s 2G -p root -c

Avec -g da0 votre disque dur principal, -s 2G la quantité de swap désirée, -p root le nom du zpool, et -c pour activer la compression. D'autres options sont disponibles, je vous invite a faire un zfsinstall -h si mon setup ne vous convient pas.

Une fois ceci fait, faites un chroot dans /mnt (ou doit se trouver le nouveau système) et éditez /etc/rc.conf :

zfs_load="YES"
sshd_load="YES
hostname="whatever"
ifconfig_igb0="DHCP"

Remplacez whatever par votre hostname, et igb0 par le nom de votre interface physique connectée a internet. Quittez le chroot, rebootez, et voila, vous avez maintenant un système FreeBSD tout propre installé sur zfs a découvrir et utiliser!

Voila, c'est la fin de ce tutoriel. (Cela dit, bon courage pour tester bhyve, vu que l'IPv6 chez online est... peu crédible, disons)

Bon sinon sur d'autres sujets, j'ai mis en place des bots twitter wxcafe_ebooks, petitefanfare, capet_ebooks, zengisse, et kim_ebooks. Ils sont tous basés sur ce code, qui vient de @m1sp (github.com/twitter_ebooks). Donc voila.

A plus

Le DNS (Domain Name System) est le service permettant la résolution des noms de domaines en différentes informations : adresses IPv4, adresses IPv6, certificats DNSSEC ou IPsec, localisation géographique, ou encore texte. En général, le DNS est utilisé pour résoudre des noms de domaines en adresses IP, et ainsi pour simplifier la vie de tous les utilisateurs (je doute que tout le monde retienne de se connecter a http://173.194.45.66, ou a http://199.16.156.70. Voire même a http://5.39.76.46).

Cependant, le DNS est un système qui date de 1984, et les exigences de l'époque en termes d'expérience utilisateur n'étaient pas forcément aussi importantes que de nos jours. La configuration des serveurs DNS peut ainsi être assez contre intuitive. Cela étant dit, comprendre le fonctionnement de DNS et contrôler ses enregistrements est important.

Tout d'abord, une petite explication théorique. Le DNS fonctionne de la même façon que le système de fichiers : en arborescence. Cependant, là ou la racine du FS est /, celle de DNS est ., et là ou il convient d'écrire, par exemple, /usr/ et ou la progression se fait de gauche a droite pour le FS, pour DNS le . n'est pas obligatoire et la progression se fait de droite a gauche. Par exemple, le tld(top level domain, domaine de haut niveau) com, et le domaine google.com appartient a com, on écrit donc google.com sans écrire le point a la fin de façon courante.

Le reverse DNS est une variante du DNS "classique" permettant de résoudre les adresses IP en nom de domaine. Ainsi, 5.39.46.76 a pour domaine wxcafe.net. Cependant, le reverse DNS n'a, par définition, pas de TLD sur lequel se diriger quand on lui adresse une query. Les "adresses" que l'on query en reverse DNS sont donc constituées de l'adresse IP, dans le sens contraire a l'ordre habituel, et du faux domaine .in-addr.arpa Par exemple, pour connaitre le reverse de 5.39.46.76, il faudra faire dig PTR 76.46.39.5.in-addr.arpa. La réponse sera, évidemment, wxcafe.net

Voyons maintenant comment mettre en place son propre serveur DNS. Tout d'abord, quelques informations. DNS fonctionne sur le port 53 en UDP, et la commande utilisée pour faire des tests DNS est dig. Le DNS fonctionne avec des "enregistrements", records en anglais. Par exemple, un record A indique une adresse IP, un record NS indique un Serveur de nom, etc. dig se base sur ces records : par défaut, il ira chercher le(s) record(s) A correspondant(s) au nom de domaine que vous donnez en argument, mais en précisant un autre type de record, vous pouvez obtenir n'importe quelle information : par exemple, dig NS wxcafe.net devrait vous renvoyer

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> NS wxcafe.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13846
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;wxcafe.net.            IN  NS

;; ANSWER SECTION:
wxcafe.net.     3600    IN  NS  ns.wxcafe.net.
wxcafe.net.     3600    IN  NS  ns.home.wxcafe.net.

;; Query time: 60 msec
;; SERVER: 10.0.42.1#53(10.0.42.1)
;; WHEN: Tue Dec 10 13:31:18 2013
;; MSG SIZE  rcvd: 67

Comme vous pouvez le voir, les serveurs DNS principaux pour wxcafe.net sont ns.wxcafe.net et ns.home.wxcafe.net, qui sont respectivement des alias pour wxcafe.net et home.wxcafe.net. Ainsi, chacun fait autorité pour lui même, et le problème évident est que le résolveur ne peut résoudre la query si il est renvoyé encore et encore vers le même serveur. Il convient donc de définir dans le même fichier de configuration l'adresse de ces deux serveurs. Ainsi, le résolveur, au bout de son deuxième loop, se rendra compte qu'il est en train de faire une boucle infinie et demandera l'adresse au serveur auquel il est connecté. La première indication de direction se fait grâce au serveur du TLD.

La configuration de bind est assez simple dans le principe, le plus complexe étant en fait d'écrire les fichiers de zone. La configuration de bind sous debian se fait dans le dossier /etc/bind/. Il existe 4 fichiers de configuration principaux : named.conf, named.conf.default-zones, named.conf.local et named.conf.options. named.conf contient les options par défaut de bind, named.conf.default-zones les déclarations des zones par défaut (auxquelles il vaut mieux ne pas toucher), named.conf.local contient les déclarations de vos zones, et named.conf.options contient les options que vous rajoutez pour changer le comportement de bind.

Pour commencer, il convient de préciser que nous allons parler ici du cas dans lequel se trouve wxcafe.net: deux domaines dont nous voulons faire l'autorité, deux serveurs DNS, et un service de résolution récursive limitée a quelques IPs (notamment mon accès chez moi).

Examinons tout d'abord les fichiers de configuration de named. named.conf.local contient les définitions des zones forward et reverse. Sur wxcafe.net, les zones wxcafe.net et 76.46.39.5.in-addr.arpa sont gérées en master, et les zones home.wxcafe.net et 103.177.67.80.in-addr.arpa sont gérées en slave. Nous n'examinerons ici que les déclarations de zones sur ce serveur, et pas sur home., car elles sont sensiblement les mêmes. La différence principale étant que l'un héberge en slave les masters de l'autre. Le fichier named.conf.local sur wxcafe.net contient donc

zone "wxcafe.net" {
    type master;
    file "/etc/bind/master/wxcafe.net";
    allow-transfer {
        80.67.177.103;
    };
};

zone "home.wxcafe.net" {
    type slave;
    file "/etc/bind/slave/home.wxcafe.net";
    masters {
        80.67.177.103;
    };
};

zone "46.76.39.5.in-addr.arpa" {
    type master;
    file "/etc/bind/master/46.76.39.5.in-addr.arpa";
    allow-transfer {
        80.67.177.103;
    };
};

zone "103.177.67.80.in-addr.arpa" {
    type slave;
    file "/etc/bind/slave/103.177.67.80.in-addr.arpa";
    masters {
        80.67.177.103;
    };
};

Cela devrait être relativement clair. Globalement, les zones master ont un fichier dans /etc/bind/master/, et les slaves un fichier dans /etc/bind/slave/, les masters autorisent le transfert vers home.wxcafe.net tandis que les slaves déclarent home.wxcafe.net comme master, et le reste est assez parlant.

Voyons maintenant le fichier de zone concernant wxcafe.net, soit /etc/bind/master/wxcafe.net :

$TTL 3600    ; 1 hour
@               IN SOA ns.wxcafe.net. wxcafe.wxcafe.net. (
                        2014011001  ; serial
                        3h          ; refresh  
                        1h          ; retry
                        168h        ; expire
                        300         ; negative response ttl
                        )

; Name servers
                IN  NS      ns.wxcafe.net.
                IN  NS      ns.home.wxcafe.net.

; Mail exchangers
                IN  MX  10  wxcafe.net.
                IN  SPF "v=spf1 ip4:5.39.76.46 a -all"

; Main A/AAAA records
                IN  A       5.39.76.46
ns              IN  A       5.39.76.46

; Aliases
data            IN  CNAME   wxcafe.net.
;        [...]
www             IN  CNAME   wxcafe.net.


; home.wxcafe.net. definition
$ORIGIN home.wxcafe.net.
@               IN  NS      ns.home.wxcafe.net.
                IN  NS      ns.wxcafe.net.
ns              IN  A       80.67.177.103
                IN  A       80.67.177.103

Alors. Expliquons ligne par ligne.
Tout d'abord, le TTL (time to live) est un paramètre définissant le temps pendant lequel les serveurs récursif (qui font un cache des données) doivent cacher ce fichier de zone.
Le @ est un raccourci pour exprimer le nom de domaine courant. Ici, donc, wxcafe.net.
Maintenant, nous arrivons a un record important : SOA (Start of Authority). Ce record prend de nombreux arguments, dans l'ordre :
- Le nameserver autoritaire pour le nom de domaine en question,
- L'adresse email du responsable de cette zone, avec le premier point remplacé par un @,

puis entre parenthèses :
- Le numéro de série ("version" du fichier de zone, ici au format YYYYMMDDNN)
- La période de refresh, période entre chaque mise a jour du nameserver authoritaire secondaire,
- La période de retry, le temps entre chaque essai de mise a jour si le nameserveur authoritaire primaire est indisponible,
- La période d'expire, le temps qu'attendra le serveur autoritaire secondaire avant de supprimer les informations de son cache si le primaire reste indisponible, et enfin
- La période de TTL négatif, le temps qu'attendra le serveur secondaire avant de ne plus offrir les informations de cette zone si le serveur primaire est injoignable.

Bon, tout ceci est peut-être un peu confus, mais ce n'est pas le record le plus important a lire (pour les humains en tout cas). Continuons :

NS (nameserver) permet de désigner les différents nameservers faisant autorité pour ce domaine.

MX permet d'indiquer ou il convient d'envoyer les emails pour ce domaine. SPF est un record d'authentification pour les emails. Les records A désignent l'association entre un nom de domaine et une adresse IPv4. Les records AAAA font de même pour les IPv6, mais malheureusement ce site n'est pas encore en IPv6.

Les CNAME (canonical name) sont en quelque sorte des alias, ils permettent de mettre en place des domaines exactement semblables a d'autre (ce qui permet par exemple de filtrer ensuite avec les Virtual Hosts d'Apache, pour le web)

Enfin, la partie qui suit commence avec une déclaration $ORIGIN, ce qui permet de changer la valeur du @ et des noms de domaine non complets (qui ne se terminent pas avec un .). Ainsi, la partie suivant définit les nameservers et l'adresse IP principale de home.wxcafe.net et de ns.home.wxcafe.net. Comme on l'a vu, étant donné que ce nom de domaine est géré par un autre serveur DNS, cela permet de rediriger les requêtes nous parvenant et demandant un domaine se trouvant sous home.wxcafe.net.

Les autres fichiers de zone sont sensiblement similaires, avec les quelques différences n'étant en fin de compte que des différences de valeurs (dues au fait que, eh bah, c'est pas les mêmes domaines...).

Voila donc une courte explication de ce qu'est le DNS. Bien entendu, tout n'est pas expliqué ici, je ne suis passé que sur ce qui est en place au niveau de wxcafe.net, et encore, rapidement. Si vous voulez en savoir plus, vous pouvez aller vous renseigner directement a la source : le RFC 1034 et le RFC 1035. Dans un autre style (bien plus avancé) le blog de Stéphane Bortzmeyer est interessant aussi.

sed est un outil Unix très largement utilisé et très pratique pour manipuler le texte (ce qui se montre relativement indispensable dans un environnement Unix, puisque ce système est assez porté sur le texte). Cependant, il assez peu connu en détail, et la plupart du temps une seule fonction est utilisée : le remplacement de texte.
Or sed a bien plus de possibilités que ça, comme nous allons le voir.

Tout d'abord, rappelons les bases : sed est un programme Unix de base, mais aussi un langage de manipulation de texte dérivé de ed, l'éditeur original. ed est un éditeur de ligne, conçu a l'époque ou les ordinateurs n'étaient pas personnels et étaient utilisés avec des téléscripteurs, c'est a dire des machines dépourvues d'écrans et ne permettant donc pas l'utilisation d'éditeurs dits "visuels", tels que vim, emacs, et globalement tous les éditeurs ayant un curseur et affichant plusieurs lignes. sed est donc une évolution de ed, le s signifiant stream, sed est un éditeur de flux, prenant donc avantage du concept Unixien de flux de données (voir Flux standards) pour éditer plus d'une ligne a la fois. En pratique, sed est principalement utilisé sur des fichiers.

sed a quelques options pratique, notamment -s qui permet d'empêcher l'affichage systématique des lignes traitées, ou bien -i (pour GNU sed) qui permet de rediriger l'output dans le fichier d'input. Cela dit, l'intérêt unique du programme est son langage de manipulation de texte.

ed, et donc sed, utilise un langage basé sur les séparations (en général des /). Ainsi, la commande de base dans sed est

/[regex]/

qui permet de ne sélectionner que les lignes qui matchent [regex] (et donc de n'exécuter les commandes qui suivent que sur ces lignes.)

La commande sed la plus utilisée est bien entendu le s, qui s'utilise de la façon suivante :

s/[old text]/[new text]/[options]

qui se propose donc de remplacer (substitute) [old text] (qui peut être une regex) par [new text] (qui doit être un texte fixe, avec quelques exceptions), en appliquant [options], la plus connue des options étant g, qui permet d'appliquer la commande affectée a toutes les occurrences du texte matché sur la/les lignes concernée-s.
Les exceptions a la "fixité" de [new text] sont particulièrement intéressantes. En effet, sed utilise un langage de regex plutôt standard, excepté le fait qu'il permet jusqu'à 9 "holding spaces", qui sont délimités par \( et \), et qui sont représentées dans le texte de remplacement par \1 à \9.

Par exemple, la commande

sed 's/\(hello world\) world/\1/'

sur le texte "hello world world" renverrait comme résultat

hello world

De la même façon, le symbole & dans le texte de remplacement représente le texte original. Ainsi, la commande

sed 's/hello world/& world/'

sur le texte "hello world" renverrait comme résultat

hello world world

Une autre commande utile est p, qui sert a afficher le texte présent dans l'espace courant :

/[regex]/p

sed stocke en effet la ligne sur laquelle il travaille dans un espace mémoire dédié, que j'appelle l'espace courant (pattern space en anglais). La commande p affiche (print) ce qui ce trouve dans cet espace. La /[regex]/ réduit le pattern space de façon a ce qu'il ne contienne que les lignes matchant, et le p affiche donc ce dernier.

Un autre exemple de commande sont c, i et a, qui s'utilisent ainsi :

c \
[text]

De la même façon, pour le i :

i \
[text]

Et de même pour a.

Ces trois commandes s'utilisent de la même façon pour la bonne raison qu'elles sont très proches. i sert a insérer du texte avant le pattern space. a sert a insérer du texte après le pattern space, et enfin c sert a remplacer tout le pattern space. Les trois utilisent [text] comme remplacement ou insert. Attention, les insertions se font sur la ligne précédant ou suivant le pattern space, et non sur la ligne en question.

Enfin, dernière commande ne fonctionnant que ligne par ligne, d : /[regex]/d d (delete) supprime les contenus du pattern space.

sed est un outil puissant, mais complexe. Dans un prochain article, je parlerai des commandes multilignes et des labels.

Le chiffrement en tant que concept informatique est traditionnellement associé au chiffrement de fichiers, c'est a dire au fait de passer d'un fichier en clair a un fichier chiffré dit cyphertext. Cependant, il ne se limite pas a ça, et peut aussi servir a garantir l'intégrité d'un système d'exploitation, ou bien la confidentialité d'un support de stockage, par exemple. Nous allons ici voir comment mettre en place un système de ce type sous GNU/Linux. Cet article n'a pas pour but de vous apprendre a mettre en place un système basé sur une procédure de boot sécurisée, mais plutôt d'expliquer les concepts qui entrent en jeu dans l'utilisation du sous-système du noyau Linux dm_crypt et de présenter un rapide tutoriel concernant la création d'un support chiffré sur lequel garder vos informations confidentielles (par exemple, votre clé GPG)

dm-crypt est un sous-système de device-mapper, qui est lui-même un sous-système du noyau Linux, et s'appuie sur LUKS, un standard de chiffrement de disques. Comme son nom l'indique, device-mapper est un système qui a pour but de mapper des block devices. Pour être plus clair, le kernel considère comme "block device" tout fichier spécial (en gros, les fichiers disques dans /dev/, les systèmes de fichiers type LVM, les RAID logiciels, et, dans le cas qui nous intéresse, les systèmes de fichier chiffrés). Son mode de fonctionnement est simple : a partir d'un "fichier de périphérique" (trad. Wikipédia), il en "crée" un nouveau, virtuel, ayant des propriétés différentes. Par exemple, un disque partitionné via LVM apparaîtra comme un seul disque dans /dev, et device-mapper est requis pour pouvoir en voir les partitions (qui apparaîtront donc dans /dev/mapper)

Ainsi, dans le cas qui nous intéresse ici, device-mapper prend un système de fichier chiffré, crée un périphérique virtuel non chiffré dans /dev/mapper, et déchiffre a la volée tous les accès disques a ce périphérique non chiffré en les traduisant sur le système de fichier chiffré, le tout de manière tout a fait transparente pour les applications utilisant le disque en question. Cela induit bien entendu une baisse de performance relativement significative dans le cas d'un chiffrement du système de fichier root, mais quasiment insignifiante dans le cas de chiffrement de partitions de données.

D'ailleurs, certain-e-s se demandent peut-être comment le système peut démarrer si le système de fichier root est chiffré. Dans ce cas précis, la procédure de boot doit s'appuyer sur une image initrd (l'initrd est un système de fichier minimal qui sert uniquement a initialiser le système. Les kernels de base de la plupart des distributions GNU/Linux en utilisent un dans tous les cas, pour des raisons de compatibilité) et sur une partition de boot qui elle n'est pas chiffrée. Ainsi, le bootloader de niveau 2 (grub, syslinux,...) charge en mémoire le kernel depuis la partition de boot, puis ce dernier décompresse et charge l'initrd en RAM, celui-ci a son tour lance un script permettant de charger les modules nécessaires a la suite du boot (que ce soit pour un boot sans disque root local, ou bien comme ici avec un système chiffré), puis le système de fichier "cible" est remonté sur la racine, et l'initrd est démonté est la RAM qu'il occupait est libérée, puis la procédure de boot normale reprend depuis le système de fichier maintenant monté sur la racine.

La méthode la plus évidente pour contourner le chiffrement du disque est alors de remplacer le fichier compressé initrd dans /boot, qui n'est pas chiffrée, par un autre modifié, copiant par exemple la phrase de passe permettant de déchiffrer la partition cible. Plusieurs méthodes permettent de se prémunir contre ce genre d'attaques : l'une des plus simple est de faire un checksum du fichier initrd utilisé et reconnu comme sûr, et de vérifier lors du vrai boot que l'initrd présente toujours le même checksum. Cela dit, cette méthode a l'inconvénient d'intervenir après les faits, et de nécessiter au moins un accès a un fichier initrd reconnu comme sûr.
Une autre approche consisterait a placer le système de fichier /boot sur un périphérique dédié, protégé en écriture de façon matérielle (par exemple, une carte SD) ou, de façon encore plus efficace, sur un périphérique chiffré et protégé en écriture de façon matérielle. Ainsi, il n'est pas possible pour un attaquant de modifier ce système de fichier, et l'initrd est alors toujours de confiance. Cependant, cela a pour conséquence de rendre la mise a jour de l'initrd et du noyau beaucoup plus difficile qu'elle ne le serait sans.

Pour en revenir aux systèmes de fichiers chiffrés, leur gestion est faite par un programme dédié, cryptsetup. Ce dernier était en charge de cryptoloop, l'ancien sous-système de chiffrement du kernel Linux (déprécié depuis), et est maintenant responsable de l'utilisation userspace de dm-crypt, qui pour sa part est entièrement kernel-space. Cryptsetup permet ainsi le chiffrement, la manipulation (montage/démontage/...) et la gestion de clé des systèmes de fichier LUKS. Cryptsetup est cependant conçu pour être utilisé en tant que root, et les utilisateurs qui veulent monter de systèmes de fichiers chiffrés devront ainsi obligatoirement être capables de le faire en tant que root.

Voyons comment il faudrait procéder pour créer une image disque chiffrée de 1Go :
Tout d'abord, il nous faut créer le fichier qui contiendra l'image. Pour cela, dans une situation réelle ou l'on cherche a chiffrer un disque, il convient d'utiliser /dev/urandom comme source, pour éviter la détection du système de fichier chiffré sur le disque. Ici, par exemple, nous allons faire :

dd bs=1000 count=1000000 if=/dev/urandom of=image.img

Maintenant que notre image est créée, nous pouvons la chiffrer :

sudo cryptsetup luksFormat image.img

cryptsetup va alors nous demander si nous sommes absolument surs de vouloir formater ce disque (nous allons donc valider en tapant YES), puis une passphrase. Il convient ici de choisir une passphrase particulièrement sûre, puisque toute personne ayant accès a la passphrase aura aussi accès au disque et donc a vos secrets.
Une fois cela fait, nous allons mapper cette image :

sudo cryptsetup luksOpen image.img crypto

cryptsetup nous redemande la passphrase, charge pendant quelques secondes, puis nous redonne le prompt. Que s'est-il passé? En cherchant un peu, nous voyons qu'il n'y a pas de nouveau disque dans /dev. C'est tout a fait normal. En effet, cryptsetup (et par lui, device-mapper et dm-crypt) ne monte pas les systèmes de fichiers chiffrés, il les mappe, et ça n'a rien a voir. On remarque qu'est apparu dans /dev/mapper le fichier crypto. Ce fichier est le disque virtuel qui correspond a notre image. Il se comporte comme toute partition, et peut donc être monté, formaté, etc (il ne peut cependant pas être partitionné. Il se comporte en effet comme une partition, et non comme un véritable disque.) Bon, ceci fait, notre disque virtuel n'est pas formaté. Il nous reviens donc de le faire, pour pouvoir l'utiliser.

sudo mkfs.ext4 /dev/mapper/crypto

Maintenant que notre disque est formaté, il peut être monté :

sudo mount /dev/mapper/crypto /mnt

Et voila, nous avons un système de fichier fonctionnel et chiffré! Si vous voulez vérifier, un mount | grep crypto devrait vous donner le résultat suivant :

/dev/mapper/crypto on /mnt type ext4 (rw,relatime,data=ordered)

Vous pouvez maintenant commencer a stocker tous vos secrets sur ce fichier, ils sont (en fonction de votre passphrase) en sécurité.

Pour résumer :

• Pour monter vos partitions :

  sudo cryptsetup luksOpen <fichier chiffré> <nom de disque virtuel>
  sudo mount /dev/mapper/<nom de disque virtuel> <emplacement>
  

• Pour démonter vos partitions :

  sudo umount <emplacement>
  sudo cryptsetup luksClose <nom de disque virtuel>
  

Pour simplifier la vie de tous, j'ai créé deux petits scripts vous permettant de créer et de monter/démonter vos images/disques chiffré-e-s en une seule commande. Ils se trouvent sur github.

Par ailleurs, si vous comptez transferer votre image disque sur un véritable disque (ou clé usb, ou autre), il est préférable de créer une partition de taille appropriée et de faire un dd if=votre_image of=/dev/votre_partition pour ce faire.

Il y a un certain temps, j'avais parlé du concept du self-hosting. Il s'agit de posséder son propre serveur, et donc, par extension, ses données.

Bien entendu, il n'est pas nécessaire pour cela de posséder physiquement son propre serveur (encore que ce soit possible, mais ce n'est pas le sujet abordé ici.)
Nous expliquerons ici les étapes nécessaires pour arriver a avoir un serveur utilisable, du moment ou vous arrivez sur le système fraichement installé, au moment ou vous possédez un serveur avec tous les paquets nécessaires a l'utilisation que l'on veut en faire ici d'installés. Cette partie va consister a paramétrer le système (ici un debian squeeze. Il est bien sur possible de faire la même chose avec a peu près toutes les distributions Linux disponibles, tout comme avec les BSD et tous les autres systèmes UNIX, mais je vais ici me limiter a debian 6.0.x squeeze, parce que c'est une distribution simple a utiliser comme serveur, stable, et facile a configurer (puisqu'une bonne partie de la configuration est déjà faite et incluse dans le paquet), donc adaptée au but de cet article, a savoir rendre l'installation simple et compréhensible).

La première chose a faire est bien entendu d'obtenir le serveur en lui même. Cette partie de la chose ne sera pas traitée dans cet article. Il existe en effet un nombre infini d'obtenir un serveur, que ce soit en le louant chez OVH/1&1/n'importe quel autre hébergeur commercial, en participant a un système d'hébergement collaboratif (je vous laisse chercher), en achetant un serveur et en le faisant fonctionner de chez vous, en utilisant un vieux PC... Bref, les possibilités sont multiples. Dès lors que vous avez accès a un système debian serveur, peu importe sur quel matériel il fonctionne, et a priori peu importe aussi la manière dont vous y accédez, le résultat est le même (et la procédure aussi...). Dans cet article, nous parlerons de la configuration de base, du moment ou vous avez le serveur vierge dans les mains au moment ou vous installez le serveur http.

Dans cet article, lorsque est précisée le type d'IP a utiliser, il convient de mettre ce type précisément. Quand le type n'est pas précisée, libre a vous de choisir ipv4 ou ipv6.

Bref. Commençons au point ou vous avez un accès root a votre serveur, n'ayant soit aucun mot de passe, soit un choisi par l'hébergeur, et ou rien n'est configuré. Connectez vous a celui-ci (ssh root@). Commencez donc par faire un passwd, pour mettre au plus vite un mot de passe solide sur le compte root. Continuons en allant vite mettre en place le nom de domaine. Pour cela, votre registrar doit vous fournir une interface vous permettant d'éditer l'entrée DNS pour votre nom de domaine.

Cette entrée doit donc pour l'instant ressembler a ca :

    <votre nom de domaine>  NS 1 
                            IN MX 1 
                            IN A        <IPv4 de votre serveur>
                            IN AAAA     <IPv6 de votre serveur>

Cela vous permet de rediriger tout le trafic se référant a votre nom de domaine vers votre ip (le fonctionnement exact du DNS est assez compliqué a expliquer, donc on va dire que c'est de la magie pour l'instant, ca sera peut être le sujet d'un autre article), et d'indiquer que les mails @votre-nom-de-domai.ne doivent aussi être redirigés vers votre serveur, ce qui est un bon début. Faisons un petit point sécurité ici : pour accéder a votre serveur, il vous suffit actuellement de taper le mot de passe root.

root est un utilisateur assez répandu, et il est assez simple de bruteforcer le mot de passe. (Relativement assez simple, en fonction du nombre de caractères, ça prend plus ou moins de temps, et si vous avez suffisamment de caractères, ça peut prendre un temps assez conséquent. Cela dit, il vaut mieux être prudent...) Ainsi, nous allons arrêter d'utiliser root et nous allons commencer a utiliser des couples clés publiques/privées pour nous connecter au serveur.
Cela se fait en deux temps : tout d'abord, créer un nouvel utilisateur, grâce auquel nous administrerons le serveur a l'avenir; puis configurer OpenSSH pour que celui ci n'accepte que les connections par clés et plus celles sur root.

Commençons par ajouter un utilisateur. Si vous êtes sous debian, cela se fait avec adduser, qui est interactif (vous ne devriez pas avoir de problème avec, puisqu'il crée tout les dossiers et fichiers nécessaires, et vous pose toutes les questions utiles pour vous aider.) sinon, vous devrez utiliser useradd, qui est (en plus d'être très chiant a distinguer de l'autre, bien plus chiant a utiliser. (adduser est en fait un simple script permettant l'utilisation d'useradd plus facilement.)

Avec adduser, vous pouvez soit utiliser le mode interactif en tapant juste adduser <username>, soit utiliser le mode non-interactif en faisant un adduser --group <username>

Avec useradd, vous devrez utiliser la commande suivante : useradd -m -N -g <username>. Cette commande ajoutera un utilisateur, créera son dossier principal dans /home/, et l'ajoutera au groupe du même nom que lui (ce qui est en général nécessaire pour des questions de vie privée).

Il convient maintenant d'ajouter cet utilisateur aux groupes qu'il sera amené a administrer: usermod <username> -a -G www-data postfix users staff sudo wheel, puis de changer son mot de passe passwd. Enfin, ajoutons le aux utilisateurs autorisés a utiliser sudo: echo "%sudo ALL=(ALL) ALL" >> /etc/sudoers
Enfin, changeons d'utilisateur : su. A ce point, vous avec un utilisateur complètement fonctionnel et utilisable pour toutes les taches d'administration. Si vous devez encore utiliser root, c'est que quelque chose ne va pas.

Vous êtes donc loggés sur le système en tant qu'utilisateur normal. Nous allons maintenant passer a la phase 2 du plan : désactiver le login ssh root et le login ssh par mot de passe.
Tout d'abord, qu'est-ce qu'un login par clé ssh? Il s'agit en fait d'un système assez semblable a celui vous permettant de chiffrer vos mail : vous avec une clé publique et une clé privée sur le client, et la clé publique est aussi sur le serveur. Lorsque vous vous connectez, openssh vérifie que vous possédez la clé privée qui correspond a la clé publique stockée sur le serveur (pour votre utilisateur, bien entendu). Il est également possible d'utiliser plusieurs clés publique pour chaque
utilisateur.

Bref, maintenant que nous avons la théorie, passons a la pratique : tout d'abord, il nous faut générer un couple de clés publique/privée sur le client. Openssh fait ça via la commande ssh-keygen -t rsa (le -t rsa précise a ssh que nous voulons un chiffrement rsa, qui est suffisamment solide pour cette utilisation.) Entrez les informations que ssh-keygen vous demande. Trois fichiers devraient maintenant se trouver dans votre dossier .ssh/ : id_rsa, id_rsa.pub, et known_hosts.
known_hosts liste les serveurs auxquels vous vous êtes connectés déjà une fois (pour éviter les attaques MITM, mais bref). Non, ce qui nous intéresse ici c'est id_rsa et id_rsa.pub . id_rsa contient votre clé privée, sauvegardez la sur une clé USB ou notez la sur un bout de papier, si vous la perdez, vous ne pourrez plus vous connecter au serveur. (planquez la clé usb/le bout de papier...) id_rsa.pub, quand a lui, contient votre clé publique. Copiez la sur le serveur, avec un scp ~/.ssh/id_rsa.pub <username>@<votre nom de domaine>:~/ , ou en la copiant a la main, si ça vous amuse.

Vous avez maintenant un fichier id_rsa.pub dans votre dossier personnel sur le serveur, il faut le mettre a un endroit ou openssh le reconnaitra. Il est donc nécessaire de créer le dossier .ssh (mkdir .ssh), puis de déplacer ce fichier a la bonne place (mv ~/id_rsa.pub ~/.ssh/authorized_keys). Testez si ça fonctionne : ouvez un autre terminal, et
connectez vous a votre serveur (ssh <username>@<votre nom de domaine>), et il ne devrait pas vous demander de mot de passe.Si il vous en demande un, NE PASSEZ PAS A LA SUITE. Quelque chose a foiré, donc vérifiez que vous avez suivi correctement les instruction ci-dessus.

Continuons. Il ne nous reste plus qu'a installer le serveur web, et a le configurer:

sudo apt-get install \
apache2 apache2.2-common apache2-doc apache2-mpm-prefork \
apache2-utils libexpat1 ssl-cert libapache2-mod-php5 \
php5 php5-common php5-gd php5-cgi libapache2-mod-fcgid \
apache2-suexec php-pear php-auth php5-mcrypt mcrypt \
php5-imagick imagemagick libapache2-mod-suphp libruby \
libapache2-mod-ruby

(faisons large, on aura besoin de l'excédent plus tard...), puis activons les
mods apache en faisant a2enmod suexec rewrite ssl actions include dav_fs dav auth_digest, et faisons en sorte que ces activations soient prises en compte par apache via un sudo service apache2 restart

Le serveur fonctionne, maintenant, il est necessaire de lui expliquer comment fonctionner sur notre nom de domaine et ou trouver les fichiers a envoyer.

Pour cela, nous allons faire un simple ln -s /etc/apache2/sites-{available,enabled}/default, car apache est assez sympa pour nous filer un fichier de configuration par défaut. Il nous faut encore l'éditer, en changeant l'adresse mail au début du document par la votre, et en changeant AllowOverride none en AllowOverride All, et enfin redémarrer apache pour qu'il prenne en compte les modifications, par un sudo service apache2 restart

Et maintenant, il vous reste a apprendre le html, parce que ca y est, votre serveur est fonctionnel! Voila voila. Dans la prochaine partie, on verra l'installation du serveur mail (c'est suffisamment complexe pour prendre un article seul...)

Les clients mails ont une particularité en commun : ils sont tous très mauvais. Cela pour nombre de raisons, mais la principale reste que leurs interfaces/raccourcis claviers ne sont pas efficaces pour une utilisation a la UNIX
Cependant, un d'entre eux se démarque par sa moins-mauvais-itude, c'est le relativement bien connu Outlook Express 2003 Mutt!
Mutt est un client mail en ligne de commande, qui, comme le dit sa page d’accueil, "just sucks less". Dans les faits, mutt est assez chiant a configurer mais particulièrement pratique a utiliser après.

La configuration de mutt se fait dans le fichier .muttrc ou dans /etc/Muttrc, et il est courant d'utiliser offlineimap en conjonction avec celui ci, de façon a accéder aux mails même sans accès internet (mutt dispose d'un système d'accès IMAP/POP et SMTP, mais ne crée pas de cache, ce qui empêche la consultation des emails sans connexion internet.) La configuration d'offlineimap se fait dans ~/.offlineimaprc ou dans rien d'autre en fait, c'est une config par user. Offlineimap est un petit logiciel en python qui synchronise un dossier en Maildir avec un serveur IMAP, ce qui tombe bien puisque justement mutt accepte les dossiers au format Maildir. (De plus, cela va tout a fait dans le sens de la libération des données en cela que vous possédez vos mails en local.)
Bref, passons aux choses serieuses : le code. Déjà, installez offlineimap et ce script fait par moi, qui vous permet d'installer mutt avec le patch sidebar, qui crée un listing des dossiers sur la partie gauche.
Ensuite, voyons pour la partie configuration :
Ma configuration d'offlineimap :

## Config file for offlineimap
## Originally located in ~/.offlineimaprc
## This should not be edited without creating a copy before
## Created by Wxcafe (Clément Hertling)
## Published under CC-BY-SA

[general]
# List of accounts to be synced, separated by a comma.
accounts = main

[Account main]
# Identifier for the local repository; e.g. the maildir to be synced via IMAP.
localrepository = main-local
# Identifier for the remote repository; i.e. the actual IMAP, usually non-local.
remoterepository = main-remote
# Status cache. Default is plain, which eventually becomes huge and slow.
status_backend = sqlite              # le type de cache. (plain ou sqlite)

[Repository main-local]
# Currently, offlineimap only supports maildir and IMAP for local repositories.
type = Maildir                        # le type de stockage (Maildir ou IMAP)
# Where should the mail be placed?
localfolders = ~/Emails/                # le dossier dans lequel vous
                                        # voulez que vos emails apparaissent

[Repository main-remote]
# Remote repos can be IMAP or Gmail, the latter being a preconfigured IMAP.
type = IMAP
remotehost = //placeholderhost//        # le serveur de votre messagerie
remoteuser = //placeholderusername//    # votre nom d'utilisateur
remotepass = //placeholderpassword//    # votre mot de passe
cert_fingerprint = //placeholdercert//  # le certificat du serveur (IMAPS only)

Ça devrait être assez simple a lire, j'ai tout bien commenté :3
Puis ma config mutt :

## Mutt MUA configuration file
## This file should not be edited without creating a copy
## File Created and edited by Wxcafe (Clément Hertling)
## Published under CC-BY-SA

# General config for reading (fetched via offlineimap)

set mbox_type = Maildir
# type de boite mail (voir dans offlineimap, mailbox par defaut)

set folder = ~/Email/
# dossier root mailbox/imap

set spoolfile = +INBOX
# dossier d'inbox

set mbox = +'All Mail'
# dossier ou archiver les emails

set copy = yes
# yes pour copier les messages dans les differents dossier, no pour...
# enfin voila quoi.

set header_cache = /.hcache/
# dossier ou sont stockés les headers (pour le cache)

set record = +Sent
# dossier dans lequel sont stockés les messages envoyés

set postponed = +Drafts
# dossier dans lequel sont stockés les brouillons

mailboxes = +INBOX +Drafts +Sent +Trash  +All\ Mail 
# liste des dossiers qui vont apparaitre dans la colonne de gauche

# General config for sending (using Mutt's native support)

set smtp_pass = 'password_placeholder'
# votre mot de passe

set smtp_url = "smtp://username@whatev.org:465/"
# l'url ou envoyer les emails

set send_charset = "utf-8"
# UTF8, NE PAS CHANGER

set signature = ".sign"
# vous pouvez mettre votre signature dans .sign

set sig_on_top = yes
# il est d'usge de mettre no ici. Cependant, je trouve ca plus lisible 
# comme ca.

set ssl_verify_host = no
# mettez yes ici si votre serveur a un certificat configuré correctement

set hostname = "wxcafe.net"
# mettez l'adresse de votre serveur ici

# Misc settings

auto_view text/html
# la façon de voir les emails par défaut.

set date_format = "%y-%m-%d %T"
# format de date d'envoi/de reception.

set index_format = "%2C | %Z [%D] %-30.30F (%-4.4c) %s"
# format de l'index (la présentation de l'interface)
# voir http://www.mutt.org/doc/manual/manual-6.html#index_format

set sort_alias = alias
set reverse_alias = yes 
set alias_file = "$HOME/.mutt/aliases"
# liste des alias noms/email. a créer et remplir vous même.
# format : "alias short_name long_email_adress"
source $alias_file

set beep = no
# ne pas biper. CE SON ME TUE T.T

set tilde = yes
set sleep_time = 0
# ?

set sidebar_visible = yes
set sidebar_width = 15
# parametres de la barre coté gauche

set realname = "Clément Hertling (Wxcafé)"
set from = "wxcafe@wxcafe.net"
set use_from = yes
set certificate_file = "$HOME/.mutt/cacert"
# parametres d'envoi. mettez vos propres infos a la place des miennes...

set edit_headers = yes
# vous permet de vois les headers des mails. j'aime, donc je laisse.

# Macros

# le titre dit tout. index veut dire que la macro est active dans les menus,
# pager qu'elle l'est dans la visionneuse, les deux qu'elle l'est dans les 
# deux
# \C represente la touche Control

bind index,pager \Cp sidebar-prev
# Control+p -> remonter d'un dossier dans la sidebar

bind index,pager \Cn sidebar-next
# Control+n -> descendre d'un dossier dans la sidebar

bind index,pager \Co sidebar-open
# Control+o -> ouvrir le dossier selectionné dans la sidebar

macro index,pager d "=Trash" "Trash"
# d supprime le message en cours

bind pager   previous-line
# permet de monter d'une ligne avec la touche up, au lieu de changer de message.

bind pager   next-line
# permet de descendre d'une ligne avec la touche down, au lieu de changer de 
# message

bind pager j next-line
bind pager k previous-line
# raccourcis vim

# PGP signing commands

set pgp_decode_command="gpg %?p?--passphrase-fd 0? --no-verbose --batch --output - %f"
set pgp_verify_command="gpg --no-verbose --batch --output - --verify %s %f"
set pgp_decrypt_command="gpg --passphrase-fd 0 --no-verbose --batch --output - %f"
set pgp_sign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f"
set pgp_clearsign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor --textmode --clearsign %?a?-u %a? %f"
set pgp_encrypt_only_command="pgpewrap gpg --batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust --encrypt-to 0x******** -- -r %r -- %f"
set pgp_encrypt_sign_command="pgpewrap gpg --passphrase-fd 0 --batch --quiet --no-verbose --textmode --output - --encrypt --sign %?a?-u %a? --armor --always-trust --encrypt-to 0x******** -- -r %r -- %f"
set pgp_import_command="gpg --no-verbose --import -v %f"
set pgp_export_command="gpg --no-verbose --export --armor %r"
set pgp_verify_key_command="gpg --no-verbose --batch --fingerprint --check-sigs %r"
set pgp_list_pubring_command="gpg --no-verbose --batch --with-colons --list-keys %r" 
set pgp_list_secring_command="gpg --no-verbose --batch --with-colons --list-secret-keys %r" 
set pgp_autosign=yes
set pgp_sign_as=0x********
# remplacez 0x******** par votre identifiant PGP!!!!!

set pgp_replyencrypt=no
set pgp_timeout=7200
set pgp_good_sign="^gpg: Good signature from"

# si vous ne comptez pas utiliser PGP, commentez toute cette section, depuis
# PGP signing options

# Palette for use with the Linux console.  Black background.

# Schéma de couleur Rouge et Noir. Commentez si vous voulez le 
# défaut noir et blanc.
# d'autres schémas sont trouvables sur google et autre.

color hdrdefault red black
color quoted brightblack black
color signature brightblack black
color attachment red black
color message brightwhite black
color error brightred black
color indicator black red
color status white black
color tree white black
color normal white black
color markers red black
color search white black
color tilde brightmagenta black
color index red black ~F
color index red black "~N|~O"

Voila, pour plus d'informations vous pouvez aller voir le manuel de mutt @ http://www.mutt.org/doc/manual/
J'espère que cette configuration "toute faite" vous aidera a commencer a utiliser mutt. Il est tout de fois important de se souvenir qu'utiliser une configuration toute faire n'aide pas a comprendre un programme ou un système, et que cette façon de faire devrait être réservée a l'introduction ou a des situations ou il est absolument nécessaire d'avoir rapidement une configuration fonctionnelle (c'est a dire, dans le cas d'un client email, euh... jamais?). Je vous invite donc a relire les annotations dont sont parsemés les fichiers de configuration en question, et surtout a lire le manuel, a chercher sur Bing Google Yahoo Seeks, et globalement a tenter de comprendre les configurations en question et a les améliorer!

PGP (pour pretty good privacy) est un système de chiffrement asymétrique (pour plus d'information sur le chiffrement asymétrique, voir ici) utilisant en général les algorithmes RSA et/ou DSA, et pouvant servir a chiffrer tout fichier, mais aussi a signer des emails. Le système de signature consiste a s'identifier en tant que la personne que l'on est, en certifiant de son identité, et repose sur un système dit de Web of Trust.

Ce concept de Web of Trust est simple: si je valide le code vous identifiant (votre clé), en certifiant que vous êtes qui vous êtes et que je vous connais, et que d'autres personnes m'ont déjà personnellement validé, les autres utilisateurs seront enclins a croire que vous êtes en effet la personne que vous prétendez être. Bien entendu, les utilisateurs validant trop de clés rapportées comme fausses voient la valeur de leurs signatures baissée, et toutes les clés signées par ces utilisateurs voient leur crédibilité baisser.
Inversement, les "bons utilisateurs" voient la valeur de leurs signatures augmentée, ce qui augmente la crédibilité des clés qu'ils ont signées.

Ceci dit, un email peut être a la fois signé et chiffré, de façon a être sûr, non seulement que l’expéditeur de l'email est bien celui qu'il dit être, mais aussi que l'email n'a pas été modifié entre l'envoi et la réception (en effet, avec un chiffrement de type RSA/DSA, une modification du corps de l'email rend ce dernier illisible, la clé publique ne  correspondant plus a la phrase de passe du message), ce qui offre bien évidemment des avantages non négligeables dans un environnement ou la protection des échanges est importante (soit a peu près partout sur internet, si vous tenez a votre vie privée. Pensez a quitter Gmail aussi, par exemple).

Il est cependant a noter que les clés publiques sont généralement situées sur un serveur de clés publiques, tel pgp.mit.edu ou encore subkeys.pgp.net (certaines personnes préfèrent garder leur clés hors des serveurs de clés publiques, craignant une compromission de ces serveurs. Dans le cas d'utilisateurs normaux (c'est a dire n'échangeant pas de secrets classés secret-défense par email), la protection offerte par les serveurs de clé publiques est suffisante)

L'une des implémentations les plus connues et utilisées de PGP est sans conteste GPG (GNU Privacy Guard) , qui comme son nom l'indique fait partie du projet GNU, et qui (<troll> de façon surprenante pour un programme GNU</troll>) est extrêmement efficace et claire.

Après ces explications techniques, voici venue le moment intéressant/utile, a savoir l'application. Le chiffrement et la signature de mails doivent cependant attendre un petit peu, étant donné qu'il vous faut d'abord créer votre clé et la placer sur un serveur de clés publiques, de façon à ce que votre destinataire puisse vous identifier lorsqu'il recevra le mail, mais aussi a configurer votre client mail pour utiliser gpg (je baserai les explications de cet article sur Thunderbird, mais des explications efficaces sont trouvables facilement sur les interwebs).

Tout d'abord, générons une clé GPG :

 gpg --gen-key

GPG va vous demander les méthodes de chiffrement que vous voulez utiliser, le plus sur est de laisser la valeur par défaut. La question suivante est de savoir quelle taille votre clé doit faire, il est préférable de choisir la taille la plus importante possible (4096). GPG veut ensuite savoir quand votre clé doit expirer. La méthode simple est bien évidemment de ne jamais la faire expirer, il est cependant plus intéressant dans une logique de sécurité de régler cette durée a six mois/un an.

Des informations personnelles vous sont ensuite demandées, concernant votre nom (mettez le vrai, tel qu'il apparaît sur votre carte d'identité, si vous souhaitez utiliser votre véritable identité), votre adresse mail (mettez la plus utilisée, vous pourrez en rajouter plus tard), et un mot de passe pour la clé (utilisez un mot de passe sécurisé!! Il est conseillé d'utiliser au moins 8 caractères, dont majuscules, minuscules, caractères spéciaux et nombres (vous pouvez utiliser la commande makepasswd, qui génère automatiquement un mot de passe)

GPG va maintenant prendre un peu de temps pour générer le couple clé publique/clé privée, vous devriez profiter de ce temps pour effectuer des opérations autres sur votre ordinateur : taper des textes, lancer des films, écouter de la musique... De façon à augmenter les chances d'obtenir un nombre bien aléatoire (le générateur d'aléatoire se base sur la RAM pour obtenir des bits au hasard)

Une fois cela fini, vous obtenez un couple clé publique/clé privée, que vous ne pouvez pas visualiser entièrement pour l'instant. Il est cependant possible (et recommandé) de les exporter pour les sauvegarder via une commande:

gpg --armor --export --output=pubkey.gpg

pour la clé publique, et

gpg --armor --export-secret-keys --output=seckey.gpg

pour la clé privée. Il est possible et même souhaitable de copier ces clés sur une clé USB, une carte SD, ou un autre support de stockage résistant, de façon a avoir une solution de sauvegarde, au cas ou vous perdiez ces clés sur ce PC.

Cela fait, listons les informations sur votre clé publique :

$ gpg --list-keys --fingerprint
pub     4096R/27D81AC8 2012-11-17
    Key fingerprint = 6345 A91A FF89 97E0 13D0 96A9 9E2A 1917 27D8 1AC8
uid             Clément Hertling (Wxcafe) 
uid             [jpeg image of size 14692]
sub     4096R/9ED7F77F 2012-11-17

La partie pub indique que c'est une clé publique, 4096R indique que c'est une clé RSA sur 4096 bits. La partie 27D81AC8 est l'identifiant de la clé publique, Key fingerprint = 6345 A91A FF89 97E0 13D0 96A9 9E2A 1917 27D8 1AC8 est appelé fingerprint de la clé. Les champs uid sont des manières d'identifier la clé et la personne associée a celle-ci, et enfin le champ sub est indicateur d'une subkey, système uniquement pris en charge par GPG et non inclus dans les premières versions de PGP, donc non-implémentées dans nombre de clients pgp.
Passons maintenant a la mise en place de cette clé publique sur un serveur de clés : nous utiliserons ici le serveur pgp.mit.edu.

gpg --keyserver pgp.mit.edu --send-keys *ID de la clé a uploader*

Maintenant que votre clé publique a été uploadée, vous pouvez l'utiliser pour signer et chiffrer vos emails!
Installons donc l'extension Enigmail pour Thunderbird, permettant de chiffrer/signer vos emails de façon transparente. Il conviendra de paramétrer cette extension, via le menu OpenPGP dans Thunderbird, puis Setup Wizard (l'option entre Help et About OpenPGP). Normalement, Enigmail détecte votre installation de gpg automatiquement, si cependant ce n'était pas le cas, vous pouvez utiliser la clé exportée tout a l'heure (pubkey.gpg) en l'important (import key from file).

Selon les options que vous avez utilisées, vos emails seront automatiquement signés et/ou chiffrés a l'envoi. Gardez cependant a l'esprit que si tout le monde peut lire les mails signés, il n'en est pas de même pour les mails chiffrés, pour lesquels il est nécessaire de posséder la clé publique du correspondant en question, et de posséder soi même une clé privée, donc d'utiliser OpenPGP aussi.
Concernant les signatures de clés, elles fonctionnent de manière très simple :
Vous devez télécharger la clé de votre correspondant, via un

 gpg --keyserver pgp.mit.edu --search-keys *ID de la clé de votre correspondant*

(a noter que cette commande fonctionne aussi en cherchant une adresse email ou un nom. Cependant, en cherchant via l'identifiant de la clé, vous êtes sur de trouver votre correspondant. Globalement, l'email est lui aussi assez sûr en terme de recherche de clés, tandis que le nom donne rarement un résultat). L'étape suivante est de vérifier que votre correspondant est bien la personne qui est spécifiée sur sa clé. Pour cela, il convient d'avoir déjà vu physiquement cette personne et si possible d'avoir vu une pièce d'identité lui appartenant, et d'avoir une confirmation de cette personne que la clé que vous voyez lui appartient bien.
Ceci fait, vous pouvez signer la clé via un

 gpg --sign *ID de la clé a signer*

puis la renvoyer au serveur via

 gpg --keyserver pgp.mit.edu --send-key *ID de la clé a signer*

Voila, la clé de votre correspondant est signée!

Ce tutoriel sur PGP/GPG est terminé, et votre sécurité est améliorée grâce a cette superbe invention qu'est la cryptographie!