par ·3 Commentaires

Dans la famille « les petits tracas du quotidien du sysadmin en vadrouille », je veux « la connexion SSH à mon serveur GNU/Linux préféré depuis Windows ». Le premier stagiaire venu vous lancera un condescendant « et Putty, c’est pour les ‘iench ? » (oui, le stagiaire moderne aime massacrer sa langue maternelle, l’air de rien). Seulement en bon paranoïaque que vous êtes, vous avez banni ce vieux duo grabataire qu’est l’identifiant/mot de passe au profit d’un séduisant couple de clés publique/privée DSA, on ne peut plus légitime s’il en est. Dans un élan de satisfaction non dissimulé, vous demandez alors au jeune impudent comment utiliser cette clé privée DSA dans Putty, la sempiternelle réponse « ch’ais pas c’est quoi » ne tardant évidemment pas à suivre. Le bougre se retrouve vulnérable, il n’y a plus qu’à l’achever d’un coup (bas) de RTFM. Il semble meurtri, à l’évidence il a subi ce Finish Him un grand nombre fois auparavant. Le grand pédagogue en vous le prend alors en pitié et tente de soigner à la fois son amour propre et son inculture manifeste.

Pré-requis :

  • GNU/Linux Debian 6 « Squeeze » pour la partie serveur
  • SSH avec authentification par clés DSA (voir ici pour un exemple)
  • Windows pour la partie cliente
  • Putty / Puttygen
  • Un stagiaire (optionnel)

Putty est donc un logiciel émulant un terminal de commande GNU/Linux depuis Windows. Il faut maintenant télécharger et installer les versions stables de Putty et Puttygen. Ce dernier permet de convertir la clé privée DSA, que vous aurez préalablement récupérée sur votre poste Windows, au format .ppk utilisable par Putty.

On lance donc Puttygen et on y importe la clé privée. Saisissez le mot de passe demandé si vous en avez ajouté un lors de la création des clés.

Il ne reste plus qu’à sauver la clé ainsi convertie sous le nom id_dsa.ppk par exemple.

Si vous êtes confronté au message d’erreur « Couldn’t load private key (ciphers other than DES-EDE3-CBC not supported », il faut utiliser la version de développement de Puttygen.

Il ne reste plus qu’à créer la session sous Putty et à y ajouter la clé .ppk dans le menu « Connection > SSH > Auth »

 

Mission accomplie, mais pour avoir l’esprit serein et vous assurer que votre stagiaire a tout bien compris, vous lui demandez de refaire la manipulation pour les 92 autres serveurs de l’entreprise. Quand il aura fini, afin de la vacciner contre le « ch’ais pas c’est quoi », il tâchera de vous expliciter les formules de la page Wikipedia concernant DSA. Tout ceci dans un soucis de pédagogie évidemment ;).

par ·0 Commentaires

Alors voilà, on est tout content de son serveur auto-hébergé fraîchement installé (si si), on y colle un peu tout et n’importe quoi, on teste des tas de services et là c’est le drame : lors de la sauvegarde d’un fichier de configuration, le système vous gifle sournoisement d’un revers de « no space left on device ». Un petit df -h plus loin le constat est accablant, l’installeur de Debian en qui vous aviez toute confiance, n’a réservé que 300 pauvres méga-octets pour le volume logique root alors que le disque en fait mille fois plus, que de cruauté !

Pas de problème vous dîtes vous alors, redimensionner un volume logique avec LVM, c’est de la rigolade, sauf qu’en bon paranoïaque que vous êtes vous avez chiffré tout ce petit monde à grands coup de LUKS. Bref la tâche semble ardue, les live-CD vont être de sortie suivis fatalement d’une réinstallation en bon et due forme, vous l’avez bien cherché !

Avant de sortir l’artillerie lourde, on se pose 5 minutes, on prend un café et on va jeter un œil sur le web des fois que d’autres inconscients n’auraient pas fait la même erreur. Miracle, ils sont légions (mais eux n’attaquent pas le PSN…) ou presque, l’espoir renaît, tout va bien se passer, méthode Coué, méthode Coué… Pour faire simple, l’idée est de prendre quelques giga-octets sur un autre volume logique (dans mon cas /home) pour les ré-affecter à ce goinfre de root. Deuxième miracle, cette périlleuse opération va se faire en 10 commandes ni plus ni moins.

Pré-requis :

  • GNU/Linux Debian 6 « Squeeze » dont les partitions sont chiffrées avec LUKS

Conventions :

  • prompt : # commande : exécuter la commande sous le compte root ou précédée de la commande « sudo »
  • prompt : $ commande : exécuter la commande sous le compte utilisateur

 

On commence par arrêter tous les services qui accèdent au volume logique sur lequel on va récupérer de l’espace disque (il peut être nécessaire de redémarrer le serveur pour arrêter certains processus récalcitrants) et on démonte le volume :

# umount /home

Il faut ici distinguer le système de fichiers et le volume logique (le premier étant « à l’intérieur » du deuxième). Le système de fichiers doit toujours être réduit à une taille inférieure à celle prévue pour le volume logique (ex : LV : 260 Gio / FS : 259 Gio). On va donc commencer par diminuer la taille du système de fichiers (attention : resize2fs est utilisé pour les systèmes de fichier ext3/ext4 uniquement) :

# resize2fs -p /dev/mapper/debian-home 259G

Le système nous demande alors, avant d’aller plus loin, de lancer la commande « e2fsck -f /dev/mapper/debian-home » afin de vérifier l’intégrité du système de fichier :

# e2fsck -f /dev/mapper/debian-home

Un fois cette commande terminée, on peut seulement alors lancer la commande resize2fs.

Le système de fichier étant redimensionné, on passe maintenant au volume logique que l’on va passer de 280 Gio à 260 Gio :

# lvresize --size=260G /dev/mapper/debian-home

Il ne reste plus qu’à étendre le système de fichiers à l’intégralité du volume logique :

# resize2fs /dev/mapper/debian-home

On remonte le volume logique :

# mount /dev/mapper/debian-home /home

Et on contrôle que la taille du volume est conforme à nos attentes :

# df -h

Jusque là tout va bien, il va maintenant falloir réattribuer l’espace libéré au volume root. On réalise alors qu’on ne peut pas le démonter, malédiction ! Le cercle vicieux live-CD/bidouillage/réinstallation refait surface. Que nenni, j’avais promis 10 commandes, les 3 dernières vont régler le problème avec une facilité déconcertante pour la simple et bonne raison qu’on peut redimensionner le volume root à chaud sans le démonter.

On commence par augmenter la taille du volume root en lui ajoutant 5 Gio (J’ai récupéré 20 Gio sur /home, mais j’en garde sous le coude pour une prochaine fois. A noter qu’il vaudrait mieux laisser de l’espace libre à la création des volumes, lors de  l’installation, afin de palier à ce genre de problème) :

# lvresize --size=+5G /dev/mapper/debian-root

Il ne reste plus qu’à étendre le système de fichiers à tout le volume logique :

# resize2fs /dev/mapper/debian-root

Et pour finir, on vérifie que l’opération s’est bien déroulée :

# df -h

Le serveur est sain et sauf, avec un système de partitions classique, cette opération aurait été bien plus compliquée à mettre en œuvre et surtout plus risquée : la flexibilité et la facilité de LVM en actions !

Sources :

 

par ·2 Commentaires

… Ou comment sentir poindre sur vous le regard réprobateur de vos amis lors d’une soirée, alors qu’en toute candeur vous abordiez ce fascinant sujet avec un confrère émérite, le « Vos discussions d’admins, ça commence à… » ne tardant jamais à suivre. Le fait est qu’en société, le profane ne goûte guère à vos échanges académiques en la matière. Encore que périodiquement, ils souhaitent connaître votre position sur le « NTLDR is missing, Operating System not found », un sujet qui curieusement semble les intéresser grandement.

Pré-requis :

  • GNU/Linux Debian 6 « Squeeze » dont les partitions sont chiffrées avec LUKS
  • SSH installé

Conventions :

  • prompt : # commande : exécuter la commande sous le compte root ou précédée de la commande « sudo »
  • prompt : $ commande : exécuter la commande sous le compte utilisateur

Cet épineux problème, le montage partition chiffrée pas le NTLDR, survient quand on souhaite chiffrer son serveur GNU/Linux et pouvoir le redémarrer à distance via SSH. En effet, le mot de passe/clé privée est demandé avant le lancement du service SSH, un cas de Jörmungand informatique classique.

Après moultes recherches sur le sujet et divers essais infructueux, je suis tombé sur ce post de l’auteur du tutoriel pour Debian qui indiquait que cette problématique était prise en charge nativement par Debian depuis fin 2008.

On commence par installer Dropbear (un serveur/client SSH) et Busybox (un mini shell avec les commandes basiques). Initrd sera mis à jour lors de l’installation pour inclure ces logiciels.

# apt-get install dropbear busybox

Lors de l’installation de Dropbear, les clés publique /etc/initramfs-tools/root/.ssh/id_rsa.pub et privées /etc/initramfs-tools/root/.ssh/id_rsa sont générées. De plus, la clé publique est automatiquement ajoutée au fichier /etc/initramfs-tools/root/.ssh/authorized_keys.

On va donc récupérer la clé privée sur notre PC local afin l’utiliser pour l’authentification sur le serveur lors du démarrage de ce dernier :

# scp root@myserver:/etc/initramfs-tools/root/.ssh/id_rsa /home/user/

Il ne reste plus qu’à redémarrer le serveur Debian et lancer la commande suivante qui outre l’authentification SSH va déchiffrer le volume LUKS et par la suite monter la partition  :

# ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" -i "/home/user/id_rsa" root@myserver "echo -ne \"myLUKSpassword\" >/lib/cryptsetup/passfifo"

-o « UserKnownHostsFile=~/.ssh/known_hosts.initramfs » : utilise un autre fichier « known_hosts » car la clé publique du serveur SSH « classique » n’est pas identique à celle du serveur Dropbear, sans cette option, le client SSH interpréterait cette nouvelle clé comme une compromission du serveur et refuserait de s’y connecter.

-i « /home/user/id_rsa » : on utilise la clé privée générée lors de l’installation de Dropbear et qu’on a récupérer précédemment.

« echo -ne \ »myLUKSpassword\ » >/lib/cryptsetup/passfifo » : le mot de passe est envoyé dans fichier FIFO /lib/cryptsetup/passfifo ce qui permet le déchiffrage du volume.

Plusieurs remarques pour finir :

  • Si votre mot de passe LUKS contient des caractères exotiques qui peuvent être interprétés par bash pendant l’exécution de la commande SSH, il faut les précéder de \ ou  »  » ou ‘ ‘ afin de les « échapper ».  Le ! par exemple (Se transforme en PID de la commande (asynchrone) exécutée en arrière-plan le plus récemment dixit man bash) nécessite de désactiver l’interprétation de l’historique par la commande set +H avant d’entrer la commande SSH, set -H réactivera l’interprétation de l’historique.
  • Ce tutoriel n’a été validé que sur Debian 6, dans le principe il devrait fonctionner sur d’autres distributions. J’ai cependant vu plusieurs sujets indiquant des problèmes avec Ubuntu à cause notamment de l’utilisation de Plymouth.
  • Je n’ai pas vu de solution utilisant le mot de passe root afin de se connecter au serveur SSH Dropbear mais ça existe peut-être…

Sources :