Certificats x509 pour SSH

Niveau :
Résumé : SSH et cer­ti­fi­cats x509

Vous avez une ferme de ser­veurs ? Vous avez une ferme d’uti­li­sa­teurs ? Vous avez déjà une infra­struc­ture de ges­tion de clés pour des cer­ti­fi­cats x509 (ssl) ?

Si vous répon­dez oui à deux de ces points alors cet arti­cle va vous inté­res­ser.

Sachez qu’il est pos­si­ble d’uti­li­ser des cer­ti­fi­cats x509 avec ssh. Quel inté­rêt ? Tout sim­ple­ment vous pou­vez réu­ti­li­ser votre PKI si vous en avez déjà une en x509. Ensuite les cer­ti­fi­cats fonc­tion­nent par un sys­tème de signa­ture hié­rar­chi­sée, donc il n’est plus néces­saire de met­tre en place un sys­tème de dis­tri­bu­tion des clés des uti­li­sa­teurs sur les machi­nes. Et inver­se­ment, les uti­li­sa­teurs n’auront plus à se repo­ser sur leur pifo­mè­tre pour accep­ter les clés des ser­veurs à leur pre­mière con­nexion.

Main­te­nant qu’on sait qu’on va pou­voir ven­dre de la sécu­rité à notre boss tout en évi­tant de se far­cir des sys­tè­mes de syn­chro­ni­sa­tion, on va pou­voir se lan­cer dans les cho­ses sérieu­ses.

Com­pi­la­tion

Tout d’abord il nous faut une ver­sion de ssh qui sup­porte ce mode de fonc­tion­ne­ment. On la trou­vez chez un cer­tain Rou­men Petrov. Bon, petite décep­tion, il ne four­nit que des patchs. A nous d’en faire un vrai ssh com­pilé. Pour une fois, ça va être une peu plus dif­fi­cile pour les debia­nis­tes. Pour ceux qui recom­pi­lent leur ssh direc­te­ment :

# à adapter à vos besoins et à votre version
$ wget http://www.roumenpetrov.info/openssh/x509-6.1.1/openssh-5.1p1+x509-6.1.1.diff.gz
$ cd openssh-source
$ zcat ../openssh-5.1p1+x509-6.1.1.diff.gz | patch -p1
$ ./configure
$ make
$ make install

Pour ceux qui sont sur debian, il serait quand même plus sympa de se refaire un paquet. Le pro­blème est que le patch de Rou­men Petrov s’appli­que mal sur des sour­ces debian. Il y a donc 3 rejets à appli­quer avant de pou­voir lan­cer la com­pi­la­tion :

# récupération des sources debian
$ apt-get source openssh
# récupération du patch
$ wget http://www.roumenpetrov.info/openssh/x509-6.1.1/openssh-5.1p1+x509-6.1.1.diff.gz
$ cd openssh-5.1p1
$ zcat ../openssh-5.1p1+x509-6.1.1.diff.gz | patch -p1

# ICI relisez les fichiers .rej et appliquez à la main, c'est assez simple

# recompilation
$ dpkg-buildpackage -rfakeroot -b
# installation
$ cd ..
$ su
$ dpkg -i openssh-client*.deb openssh-server*.deb

Pour ceux qui sont tou­jours en etch vous pou­vez soit upgra­der ssh en récu­pé­rant le paquet source de lenny soit uti­li­ser la ver­sion etch avec une ver­sion plus ancienne du patch.

Pour la méthode upgrade avec etch, modi­fiez le fichier debian/con­trol qui se trouve dans le réper­toire source ssh et sup­pri­mez les ver­sions de libssl et lsb-base indi­quées dans les dépen­dan­ces avant de com­pi­ler. Cela mar­che très bien.

Pour ceux qui vou­draient res­ter en ssh4.1, appli­quez le patch de Rou­men Petrov et for­cez l’appli­ca­tion du patch avec les erreurs. Ensuite lis­tez les fichier .rej (ils sont tous à la racine) et appli­quez les à la main (retrou­ver la bonne ligne, ajou­ter …). C’est un peu plus long.

Uti­li­sa­tion

Ça y est le nou­veau ssh est ins­tallé sur le ser­veur et sur le client. Main­te­nant uti­li­sons un cer­ti­fi­cat pour se con­nec­ter au ser­veur et prou­ver que ça mar­che.

Tout d’abord il nous faut une auto­rité de cer­ti­fi­ca­tion, c’est à dire un cer­ti­fi­cat qui a le droit de signer d’autres cer­ti­fi­cats et que nous ins­tal­le­rons par­tout (l’arti­cle expli­que com­ment la créer et l’uti­li­ser). Avec cette auto­rité, il faut géné­rer deux pai­res de clés : une paire pour le ser­veur, une paire pour le client. Rien n’oblige à avoir la même auto­rité pour les deux, mais cela sim­pli­fie les exem­ples, c’est donc ce que je vais faire.

On a donc :

• ca.crt : le cer­ti­fi­cat de l’auto­rité
• ser­ver.crt et ser­ver.key : le cer­ti­fi­cat et la clé à uti­li­ser sur le ser­veur ssh
• client.crt et client.key : le cer­ti­fi­cat et la clé à uti­li­ser sur le client ssh

Authen­ti­fi­ca­tion du ser­veur

Com­men­çons par con­fi­gu­rer l’authen­ti­fi­ca­tion du ser­veur par le client. Le client sera sûr que le ser­veur est recon­nue par une auto­rité.

Côté ser­veur

Ins­tal­lons le cer­ti­fi­cat sur le ser­veur ssh. On place la clé dans un nou­veau fichier pour le ser­veur :

$ cat server.key server.crt > /etc/ssh/ssh_host_x509_key
$ chmod 600 /etc/ssh/ssh_host_x509_key
# mise à jour de la clé publique pour la forme
$ ssh-keygen -y -f /etc/ssh/ssh_host_x509_key > /etc/ssh/ssh_host_x509_key.pub

Et on ajoute cette clé à celle que le ser­veur envoie au client pour authen­ti­fi­ca­tion en ajou­tant une ligne/etc/ssh/sshd_con­fig :

HostKey /etc/ssh/ssh_host_x509_key

Vous pou­vez même com­men­ter les ancien­nes lignes Host­Key si vous vou­lez for­cer l’uti­li­sa­tion de x509, mais je ne pense pas que ce soit judi­cieux (par con­tre ça per­met d’être sur de ce qu’on teste). Et hop on relance le ser­veur.

# n'ayez pas peur cela ne coupe pas les connexions existantes
$ /etc/init.d/ssh restart

Côté client

Main­te­nant il faut que le client accepte cette clé. On va lui dire qu’il peut accep­ter tout ce qui a été signé par notre auto­rité. Pour cela, il suf­fit de copier le cer­ti­fi­cat de l’auto­rité dans /etc/ssh/ca/ca-bundle.crt (vous pou­vez met­tre tou­tes les auto­ri­tés que vous vou­lez dans ce fichier) :

$ cp ca.crt /etc/ssh/ca/ca-bundle.crt

Atten­tion : ssh véri­fie que le cer­ti­fi­cat est bien signé par une auto­rité valide mais cela ne veut pas dire qu’il accepte direc­te­ment la clé. Il passe tou­jours par une véri­fi­ca­tion uti­li­sa­teur comme expli­qué dans un autre arti­cle. Atten­tion : ssh refuse les clés mal signées mais auto­rise les clés sans cer­ti­fi­cat. A l’uti­li­sa­teur d’accep­ter ou refu­ser la clé. Atten­tion : ssh véri­fie la chaine de cer­ti­fi­ca­tion, mais ne véri­fie pas que le cn cor­res­pond au nom du ser­veur.

A noter qu’il est dom­mage que la véri­fi­ca­tion de la chaine de cer­ti­fi­ca­tion se fasse après l’accep­ta­tion par le client.

Authen­ti­fi­ca­tion du client

Cette fois c’est le ser­veur qui va véri­fier que le client dis­pose d’un cer­ti­fi­cat véri­fié par une auto­rité.

Côté client

Pour uti­li­ser notre cer­ti­fi­cat comme iden­tité, on le copie sur le client :

$ cat client.key client.crt > ~/.ssh/id_x509
$ chmod 600 ~/.ssh/id_x509
# on met a jour la clé publique
$ ssh-keygen -y -f ~/.ssh/id_x509 > ~/.ssh/id_x509.pub

Et on con­fi­gure le client pour qu’il l’uti­lise (au choix dans /etc/ssh/ssh_con­fig ou dans ~/.ssh/con­fig) :

Host *
        IdentityFile ~/.ssh/id_x509

Côté ser­veur

Main­te­nant il faut que le ser­veur accepte cette clé. On va lui dire qu’il peut accep­ter tout ce qui a été signé par notre auto­rité. Pour cela, il suf­fit de copier le cer­ti­fi­cat de l’auto­rité dans /etc/ssh/ca/ca-bundle.crt (vous pou­vez met­tre tou­tes les auto­ri­tés que vous vou­lez dans ce fichier) :

$ cp ca.crt /etc/ssh/ca/ca-bundle.crt

Et on adapte l’autho­ri­zed_keys sur le ser­veur. Pour cela deux solu­tions, la pre­mière est de copier tel quel le fichier id_x509.pub généré pré­cé­dem­ment. Ça mar­che, mais ce n’est pas très inté­res­sant. Puisqu’on a des cer­ti­fi­cats qui sont véri­fiés autant en pro­fi­ter et ne don­ner que le DN ce qui nous per­met­tra de le chan­ger.

# on réutilise le certificat pour sortir le dn au bon format
$ openssl x509 -noout -subject -in client.crt -nameopt RFC2253 >> ~/.ssh/authorized_keys

Atten­tion : ssh refuse les clés mal signées mais auto­rise les clés sans cer­ti­fi­cat. A l’uti­li­sa­teur de rem­plir son autho­ri­zed_keys cor­rec­te­ment

Con­clu­sion

Cet arti­cle com­mence à être long, je vais donc m’arrê­ter ici. Vous voyez qu’il est pos­si­ble de met­tre en place des cer­ti­fi­cats pour ssh sans trop se for­cer. Le patch de Rou­men Petrov est bien fait puisqu’il ajoute beau­coup d’options (je les ai laissé ici à leur valeur par défaut pour sim­pli­fier l’arti­cle) et sur­tout, elles sont tou­tes docu­men­tées dans les pages de manuel. De plus le sup­port de x509 est étendu à tous les outils ssh, c’est à dire le client, le ser­veur, mais aussi ssh-key­gen et ssh-agent. En dehors du man, la meilleure docu­men­ta­tion c’est le README.

Tout cela est bien pra­ti­que mais seul un usage basi­que a été cou­vert ici. Un des gros avan­ta­ges de l’uti­li­sa­tion des cer­ti­fi­cats est de pou­voir gérer des lis­tes de révo­ca­tion pour inter­dire auto­ma­ti­que­ment des cer­ti­fi­cat qui ne sont plus vali­des (l’uti­li­sa­teur est parti, la clé est trop vieille …). Nous en par­le­rons sure­ment dans un pro­chain arti­cle.