Faille OpenSSL : regénérer les clés SSH
Avec cette faille OpenSSL connue de tous, il est urgent de corriger le problème, c’est à dire :
- mettre à jour sa distribution Debian ou Ubuntu (ou autre dérivée de Debian)
- regénérer les clés utilisées
Mettre à jour sa distribution, vous savez certainement tous le faire :
aptitude update
aptitude dist-upgrade
Éventuellement, ajoutez le sudo si vous êtes en Ubuntu.
La regénération des clés SSH est pourtant indispensable, car même avec les packages corrigés, les clés host restent celles qui avaient été générées à l’installation du serveur : elles sont donc faibles et crackables !
Avant de continuer, je rappelle que cette faille n’est pas due au package OpenSSL lui-même, mais à une modification du code source faite par un développeur Debian il y a déjà plus de 2 ans…
Cela n’enlève rien à la très grande qualité de cette distribution, les erreurs de ce genre étant rares, et encore plus rarement dues à l’équipe Debian elle-même. De plus, les failles de sécurité sont en général corrigées très rapidement.
En Ubuntu, distribution dérivée de Debian et incorporant le même bug, j’ai eu l’agréable surprise que celui-ci me regénère automatiquement les clés SSH. Après la mise à jour des packages et la regénération, je retrouve ceci :
$ cd /etc/ssh
$ ls -l
-rw-r--r-- 1 root root 2064867 2008-05-13 14:10 blacklist.DSA-1024
-rw-r--r-- 1 root root 2064867 2008-05-13 14:10 blacklist.RSA-2048
-rw-r--r-- 1 root root 132777 2007-10-05 00:52 moduli
-rw-r--r-- 1 root root 1532 2007-10-05 00:52 ssh_config
-rw-r--r-- 1 root root 1873 2007-11-13 00:25 sshd_config
-rw------- 1 root root 668 2008-05-14 00:41 ssh_host_dsa_key
-rw------- 1 root root 668 2007-11-11 05:25 ssh_host_dsa_key.broken
-rw-r--r-- 1 root root 603 2008-05-14 00:41 ssh_host_dsa_key.pub
-rw-r--r-- 1 root root 603 2007-11-11 05:25 ssh_host_dsa_key.pub.broken
-rw------- 1 root root 1675 2008-05-14 00:41 ssh_host_rsa_key
-rw------- 1 root root 1675 2007-11-11 05:25 ssh_host_rsa_key.broken
-rw-r--r-- 1 root root 395 2008-05-14 00:41 ssh_host_rsa_key.pub
-rw-r--r-- 1 root root 395 2007-11-11 05:25 ssh_host_rsa_key.pub.broken
Les anciennes clés non sécures ont été renomées “.broken” et de nouvelles clés ont été crées.
En Debian, j’ai eu droit à la mise à jour des packages, mais pas à la regénération des clés. Il faut donc les regénérer soi-même.
Ce billet de Jean-Christophe Dubacq donne la commande à passer pour regénérer ces clés.
Voici d’abord une explication détaillée pour bien comprendre la manipulation. Mais attention, ce n’est pas la façon de faire conseillée pour une machine distante !
# cd /etc/ssh # mkdir backup # mv ssh_host_* backup
# dpkg-reconfigure -plow openssh-server
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Restarting OpenBSD Secure Shell server: sshd.
Vérifiez votre dossier :
# ls -l
drwxr-xr-x 2 root root 4096 2008-05-16 01:09 backup
-rw-r--r-- 1 root root 2064867 2008-05-13 16:23 blacklist.DSA-1024
-rw-r--r-- 1 root root 2064867 2008-05-13 16:23 blacklist.RSA-2048
-rw-r--r-- 1 root root 132777 2007-04-29 03:37 moduli
-rw-r--r-- 1 root root 1424 2007-04-29 03:37 ssh_config
-rw-r--r-- 1 root root 1749 2007-04-29 03:44 sshd_config
-rw------- 1 root root 672 2008-05-16 01:12 ssh_host_dsa_key
-rw-r--r-- 1 root root 603 2008-05-16 01:12 ssh_host_dsa_key.pub
-rw------- 1 root root 1675 2008-05-16 01:12 ssh_host_rsa_key
-rw-r--r-- 1 root root 395 2008-05-16 01:12 ssh_host_rsa_key.pub
Les nouvelles clés ont été générées. Ca devrait fonctionner.
AVANT de couper votre session SSH, vérifiez que tout est ok en établissant une 2ème session SSH depuis votre poste de travail :
didier@didier-desktop:~$ ssh 192.168.168.250 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is f3:17:1e:0f:6d:c8:6b:17:ca:98:d3:7a:55:58:f2:0c. Please contact your system administrator. Add correct host key in /home/didier/.ssh/known_hosts to get rid of this message. Offending key in /home/didier/.ssh/known_hosts:4 RSA host key for 192.168.168.250 has changed and you have requested strict checking. Host key verification failed.
La session est refusée et c’est NORMAL !
Votre client SSH vous protège ainsi et vous averti que la clé du serveur que vous contactez n’est plus la même. Il a raison: ce pourrait être une attaque pour capturer votre logon.
Mais ici bien évidemment, la situation est correcte puisque c’est vous même qui venez de changer la clé du serveur 
Supprimez la clé du fichier known_hosts. Vous avez le numéro de la ligne a supprimer dans le message précédent (la clé 4 dans mon cas).
$ vi .ssh/known_hosts (supprimer la ligne 4)
Je refais ma session SSH. Cette fois je peux l’établir après avoir reçu ce message de warning disant que cette machine est inconnue (puisque j’ai supprimé son ancienne clé du fichier known_hosts)
didier@didier-desktop:~$ ssh 192.168.168.250
The authenticity of host ‘192.168.168.250 (192.168.168.250)’ can’t be established.
RSA key fingerprint is f3:17:1e:0f:6d:c8:6b:17:ca:98:d3:7a:55:58:f2:0c.
Are you sure you want to continue connecting (yes/no)? yes
Si vous essayez d’établir la connexion SSH depuis un poste Windows avec PuTTY, vous recevrez un message d’avertissement de ce genre :
Là aussi, c’est normal puisque vous avez vous-même changer la clé Host. Il suffit donc de cliquer sur “Yes”.
Voilà, cela fonctionne avec de nouvelles clés hosts. Votre machine est de nouveau sécure !
Il vous reste à supprimer le backup que nous avions fait. Il ne sert plus à rien.
La méthode fonctionne, mais je ne la conseille pas en tant que telle pour un serveur distant.
Pourquoi ?
Simplement car, même si le risque est faible, vous pouvez être déconnecté en cours d’opération. Un ADSL qui coupe, ça arrive… ou tout autre raison (un orage, une coupure de courant, un plantage de votre PC, les batteries de votre laptop vide ou votre fils de 3 ans qui se prend les pieds dans la prise…)
Si cette coupure arrive entre le déplacement ou la suppression de vos anciennes clés et la génération des nouvelles, votre serveur SSH n’aura plus aucune clé pour accepter une session SSH ! Ce serait pour le moins gênant de se retrouver avec le SSH en panne, sur un serveur à l’autre bout de la planète.
L’opération n’étant pas réellement compliquée, le mieux est de tout mettre sur une seule ligne de commande pour que le serveur exécute toutes les commandes à la suite. Même si vous êtes déconnecté en cours d’exécution, votre serveur terminera les commandes entrées et regénérera les clés
La commande donnée par Jean-Christophe est parfaite. Je ne vais pas me compliqué la vie à la réécrire
C’est donc simplement un delete (rm) des anciennes clés (sans backup, pas vraiment nécessaire) suivit ( ; ) directement de la regénération des clés :
rm /etc/ssh/ssh_host*key*;dpkg-reconfigure -plow openssh-server
Voilà, en une seule ligne, les nouvelles clés RSA et DSA sont générées.
Testez quand même une seconde session SSH avant de couper la première, mais ça devrait être bon, et sécure maintenant.
Merci à Jean-Christophe Dubacq pour “la-commande-qui-va-bien”