déchiffrer un disque LUKS par SSH avec DROPBEAR

sur un serveur Debian wheezy (7.7)

Après avoir essayé plusieurs tutoriels qui ne marchaient pas pour la partie déchiffrement du disque, voici la bidouille simple (mais peut-être pas très orthodoxe) qui fonctionne sous debian wheezy 7.7

prérequis

(installation)

  • Installer dropbear sur le serveur contenant le disque dur chiffré que l’on veut pouvoir déchiffrer à distance (et installer aussi busybox si pas présent)
    sudo apt-get install dropbear

(configuration)

  • À l’installation dropbear génère une paire de clé et met à jour l’initrd.
  • Par défaut, la connexion au réseau est configurée automatiquement par DHCP. Si on veut une ip statique, définir le paramètre ip= dans les paramètres du kernel (/etc/default/grub)GRUB_CMDLINE_LINUX_DEFAULT="quiet ip=xxx.xxx.xxx.xxx::yyy.yyy.yyy.yyy:zzz.zzz.zzz.zzz::eth0:none" avec xxx.xxx.xxx.xxx l’ip, yyy.yyy.yyy.yyy la passerelle et zzz.zzz.zzz.zzz le masque réseau.

(authentification)

  • Il faut avoir placé la clé publique (id_rsa.pub) de son propre client SSH dans le fichier /etc/initramfs-tools/root/.ssh/authorized_keys de dropbear sur le serveur.
    Avant cela il faut donc:
    • générer une paire de clé pour authentification SSH sur l’ordinateur client ssh-keygen -b 4096
    • zipper le fichier de la clé publique ! (il se termine par .pub) avant de l’envoyer gzip ~/.ssh/id_rsa.pub
    • envoyer le zip de la clé publique sur le serveur distant où est installé dropbear sudo scp -P 3333 '~/.ssh/id_rsa.pub.gz' login@ip.du.serveur:/home/login/id_rsa.pub.gz (-P est nécessaire si vous avez changé le numéro de port du serveur SSH, “login” est votre nom d’utilisateur sur le serveur, et “ip.du.serveur” est l’adresse ip de votre serveur)
    • se connecter sur le serveur distant contenant dropbear ssh -p 3333 login@ip.du.serveur
    • dézipper le fichier qu’on a envoyé précédemment unzip ~/id_rsa.pub.gz
    • passer root su root
    • faire une copie de secours de fichier cp /etc/initramfs-tools/root/.shh/authorized_keys /etc/initramfs-tools/root/.shh/authorized_keys.bak
    • rajouter notre clé publique à la liste des clés authorisées par dropbear cat /home/login/id_rsa.pub >> /etc/initramfs-tools/root/.shh/authorized_keys (remplacer “login” par votre nom d’utilisateur sur le serveur
    • attention !! bien penser à régénérer l’initramfs sur le serveur distant après toute modification du paramétrage grub ou dropbear update-initramfs -u -k all. Sinon, les modifications ne seront pas prises en compte.

Lu sur un forum: il pourrait y avoir sur certaines versions de dropbear un problème avec l’autorisation de clés extérieures. Ce problème n’a pas été rencontré ici.
Le problème peut être contourné en copiant la clé privée générée par dropbear qui est sur le serveur distant et en la collant dans le dossier de clés ssh de l’ordinateur client. Ainsi la première clé publique autorisée par défaut par dropbear étant la propre clé que dropbear a généré automatiquement pendant son installation, en possédant la clé privée de dropbear sur le client SSH on peut bien s’authentifier. Cette clé générée par dropbear n’a cependant pas de mot de passe pour la protéger. (Testé, ça fonctionne)

se connecter à DROPBEAR:

Testé uniquement en réseau local pour l’instant

  • entrer la commande
    ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" -i ~/.ssh/id_rsa_dropbear root@ip.du.serveur

    (id_rsa_dropbear correspond au nom de la clé privée sur le client SSH et peut bien sur être différent)
    le login root est apparemment (à vérifier) le seul possible pour cette manoeuvre.
    Pour la suite il est bien sûr conseillé d’avoir désactivé le login root du serveur open-ssh qui prend le relai après dropbear

Déchiffrer le disque dur et lancer le système d’exploitation

  • Une fois connecté avec un shell dans dropbear, il faut éxécuter la commande cryptsetup qui permet de déchiffrer votre disque.
    Pour avoir la commande exacte qui est éxécutée automatiquement lorsque le serveur démarre et qui demande la passphrase, mais qu’on ne voit pas encore par SSH, il faut lister les processus en cours sur le serveur en éxécutant la commande
    ps

    puis trouver la commande ainsi listée qui contient “cryptsetup luksOpen” pour l’éxécuter dans le shell en la copiant/collant. Une commande qui ressemble à :
    /sbin/cryptsetup -T 1 luksOpen /dev/disk/by-uuid/1e280824-699f-4b88-878f-111bd609eba1 md1_crypt --key-file=-

    A l’invitation, entrer la passphrase pour déchiffrer le disque du serveur
  • Une fois le disque dur déchiffré, il faut arrêter une autre commande qui attend une réponse sur la console du serveur. Cette commande listée avec PS est /lib/cryptsetup/askpass. Si on ne fait pas ça le système ne démarre jamais. Utiliser le PID correspondant à cette commande que donnera PS et lancer:
    kill -9 PID
  • le système démarre sans rien afficher dans le shell dropbear. Se déconnecter de dropbear:
    exit
  • Se connecter ensuite normalement en SSH pour l’administration du serveur si besoin.
  • Note, durant le boot, il faut ajouter “pre-up ip addr flush dev eth0” dans /etc/network/interfaces pour que ifup fonctionne correctement, sinon, la machine reste dans la configuration réseau de l’initramfs

Notes sur l’accès par internet

 

concernant l’accès par internet, il n’y a pas de conflit à redouter entre dropbear et openssh par défaut. Si on installe dropbear alors qu’openssh est déjà présent, dropbear se paramètre automatiquement de manière à ne pas tourner comme service, mais uniquement à s’installer dans l’initramfs. Il semble donc tout à fait envisageable de le confirgurer sur le même port ou un port différent de openssh.
Par défaut d’ailleurs, il tourne bien sur le port 22 (comme openssh).

Tutoriel appliqué avec succès pour une ip fixe et avec une paire de clé ssh créées pour l’occasion.
pour ma part, je ne comprend pas comment le trick d’utiliser la clé privée dropbear pourrait marcher.

 
 

Alors l’histoire de la clé privée de dropbear fonctionne, j’ai essayé sans autre clé autorisée, juste pour être sur. Mais sinon en condition normale j’ai pas eu ce problème qui empêcherait la connexion avec une clé extérieure. J’ai laissé la référence au cas où, ça pourrait toujours servir… ?

Pour le reste (IP statique et port openssh) je finirais de tester ce soir ou dans les prochains jours pour confirmer dans le tuto qu’on peut sans problème avoir openssh et dropbear sur le même port non standard.

Sinon est-ce qu’il y aurait une raison de sécurité pour arrêter quand même dropbear une fois le système lancé?

 
 

tu ne peux pas avoir les deux en écoute sur le même port en même temps. L’installation par défaut avec debian n’active pas dropbear si openssh-server est présent.

 
 

ah ok… bon en tout cas tout ça marche très bien pour moi aussi à distance avec dropbear sur le port 22 et openssh sur un autre port :)

 
 

Tu augmentes la surface d’attaque sur ton serveur en laissant 2 logiciels différents pour le même usage.

 
 

oui c’est ce qui me dérange.
Mais le défaut de ma config c’est surtout que j’ai deux ports différents ouverts sur ma passerelle pour le NAT: le 22 pour dropbear et un autre pour openssh, ce qui est un peu stupide…

Après j’avais l’impression que dropbear n’est plus vraiment accessible au lancement du système car je ne le vois ni avec ‘netstat -tpl’ ni avec ‘nmap localhost’. et en plus j’ai l’option NO_START=1 dans le fichier de config de dropbear (/etc/default/dropbear), ce qui empêche de le relancer. Mais bon par contre quand je fais ‘sudo service dropbear stop’ le message est “Stopping Dropbear SSH server: dropbear.” donc il est quand même toujours là derrière.

Mon dilemme c’est que je n’arrive pas à encore à me résoudre à abandonner openssh pour ne garder que dropbear. Je ne connais pas assez bien le sujet, mais la version dropbear de debian wheezy est un peu ancienne packages.debian.org/search?keywords=dro... par rapport à l’actuelle matt.ucc.asn.au/dropbear/dropbear.html
(Qu’est-ce que vous en pensez?)

Alors ma question est: si je configure dropbear sur le même port non standard que openssh et que je met un script pour arrêter dropbear dans le runlevel 2 ou 3 avant le démarrage d’openssh, est-ce que c’est une connerie? comme ça j’ai vraiment qu’un seul service qui tourne à la fois et je peux fermer le port 22 sur la passerelle…

 
 

Je le ferais plutôt autrement =)
ce n’est pas parce que tu lance un script et qu’il te répond qu’il stoppe un process que c’est bien le cas.
Je viens de regarder de mon côté. htop ou ps aux montrent bien l’existence de sshd et l’absence de dropbear. Pour autant, sudo /etc/init.d/dropbear stop m’affiche bien stopper dropbear ? deux fois de suite même !?!
Donc à ta place, je ferais plutôt confiance à netstat et nmap.
T’as pas besoin d’en faire plus, dropbear ne doit pas tourner sur ta machine.

 
 

…j’avais oublié de mettre à jour cette fiche.
Alors petit bug: en essayant de changer le port de Dropbear dans son fichier de config, et après avoir bien mis à jour l’initramfs, je me suis rendu compte que les changements n’étaient pas pris en compte. C’est toujours le port 22 sur lequel dropbear écoute.

Au final j’ai vu que j’étais pas le seul à avoir ce problème, et j’ai utilisé la méthode conseillée dans les commentaires ici: bugs.launchpad.net/ubuntu/+source/dropb...

A savoir modifier le fichier /usr/share/initramfs-tools/scripts/init-premount/dropbear en ajoutant “-p numéro du port voulu” (sans oublier de mettre à jour l’initram avec update-initramfs -u )

J’ai aussi appliqué ça avant comme conseillé(je ne connaissais pas l’usage de dpkg-divert, ça m’a permis de me dcumenter un peu):

dpkg-divert —rename —divert /usr/share/initramfs-tools/dropbear.original /usr/share/initramfs-tools/scripts/init-premount/dropbear
ainsi que:
cp /usr/share/initramfs-tools/dropbear.original /usr/share/initramfs-tools/scripts/init-premount/dropbear

Et maintenant ça marche, j’ai un serveur dropbear sur un port autre que 22, et qui est le même que le numéro de port utilisé ensuite par open-ssh, comme ça j’ouvre qu’un port sur ma passerelle.
Et tout se passe bien ;)

 
 

Je viens de mettre en place LUKS over Dropbear sur un debian Jessie. Je me suis plus servi du tuto : projectgus.com/2013/05/encrypted-rootfs...

Son unlock script marche à merveille !

j’ai décidé d’avoir les mêmes figerpring RSA pour dropbear et openSSH en utilisant la méthode ici :
projectgus.com/2013/05/encrypted-rootfs...

j’ai utilisé la méthode que tu décris ci-dessus pour changer le port de dropbear en initramfs (j’avais le même problème que toi, ca n’est à priori pas corrigé dans debian Jessie)

Ca fonctionne comme un charme avec ma clé ssh, pas besoin d’utiliser la clé privée de dropbear.

Si tu m’y autorise, je me propose d’éditer ton tuto pour y ajouter mon expérience.

 
 

salut bkpk
merci pour ta contribution, n’hésite pas à ajouter ce qui manque pour jessie dans le tuto.

 
 

Pour l’"anecdote", après une migration debian wheezy vers jessie, le réseau ne fonctionnait plus pour une machine avec dropbear et xen, alors que ça marchait bien sous wheezy. l’ajout de l’option “pre-up ip addr flush dev eth0” dans /etc/network/interfaces a tout rétabli. On me signale la même mésaventure avec libvirtd.

 
 

Ça vous va si je rend public la page ?

 
   

(avec du retard) ok pour rendre publique