Dual Blog : DeFr's Weblog

Février 2008Avril 2008Mars 2008

Dual Blog libéré | jeudi 20 mars 2008, 15h07

Mood: Goggle

Utilisateur de logiciels libres depuis de longues années déja, programmeur, je n'avais pourtant, jusqu'à présent, rien réellement sorti sous une license libre qui puisse être particulièrement utile à d'autres... Probablement pour plusieurs raisons, notamment un certain perfectionnisme (vouloir publier du beau code, essayer d'optimiser un certains nombres de choses, ...) et un relatif manque de confiance dans l'utilité que mes divers utilitaires pourraient avoir pour d'autres. Cela a, d'un point de vue technique, changer lorsque j'ai commencé à mettre en ligne, par exemple, les codes pour les différents projets que j'ai effectué à l'ECN, une instance de Trac ayant même été crée pour le projet de groupe, mais cela est resté relativement marginal, d'une part due à l'absence de publicité faites à ces divers référentiels, et d'autres part à la spécificité de ces projets, qui présentent relativement peu d'interet pour les personnes étrangères à Centrale Nantes.

Cela a commencé à changer lorsque j'ai commencé, l'année passé, à travailler sur une classe en PHP de templates, basé sur XML, XPath et DOM, librement inspiré des principes de XML::Template. Je cherchais une solution de ce genre depuis un certain temps, et j'avais envie d'un projet pour tester Mercurial, le petit système distribué de controle de version (DVCS pour les intimes) qui a mes faveurs depuis plus d'un an déja. J'ai donc profité de l'occasion pour combiné les deux, et de publier le référentiel. Je me suis assez rapidement convaincu du potentiel de cette solution pour avoir une séparation propre des couches de présentations et de logique du code, en envoyant l'ensemble du XHTML dans les divers fichiers XML de templates, mais j'avoue qu'il devait être relativement difficile de juger du potentiel réel de la solution en se basant uniquement sur les quelques exemples que j'avais inclu dans le référentiel afin de servir de tests unitaires me permettant d'éviter les régressions.

En conséquence, j'ai décidé de l'appliquer sur quelques choses de plus gros. La cible évidente aurait été Méga-Poudlard, mais deux facteurs importants m'ont fait lui préférer Dual Blog, du moins dans un premier temps:

  1. Je pensais qu'il s'agissait de la bonne solution, mais j'avoue que je conservais quelques doutes sur la flexibilité du système, et notamment sur la possibilité de s'adapter à plus ou moins n'importe quelle structure XHTML. J'ai donc préféré commencer par un projet de nettement moins grande envergure:-)
  2. Je souhaitais l'utiliser dans un projet qu'il me serait possible de libérer ensuite. En l'état, c'était parfaitement envisageable pour Dual Blog, nettement moins pour Méga-Poudlard.

J'ai donc commencé à ré-écrire Dual Blog, en utilisant au maximum ces templates: cet effort s'est conclu en novembre dernier, moment où j'ai mis en ligne la nouvelle version, présentant une caractéristique fort plaisante: la possibilité d'utiliser exactement le même code pour la génération de la page en xhtml ou du flux de syndication Atom, au moyen d'un simple chargement de modèles différents. J'aurais probablement pu rendre public le code à ce moment là, toutefois, l'utilité en aurait été réduite: le code comportait en effet un certain nombre de présupposé sur l'adresse ou il résidait (sous-répertoire /blog par endroit, adresse complète dans d'autres, comme il est possible de le voir ), présupposait que les tables correctes soient crée en base de données... Quelques problèmes somme toutes embettant pour qui aurait voulu tester le tout ^^... La bonne nouvelle, c'est que je les ai récement régler, notamment en ajoutant un installeur.

Je voulais aussi faire un petit audit de sécurité du code avant de le publier, puisque ce dernier fonctionne en direct sur ce serveur, et qu'il m'aurait ennuyer de me retrouver avec une faille exploitée. L'interface d'administration repose entièrement sur l'authenfication de l'utilisateur via le serveur web, donc si le serveur web possède lui même une faille a ce niveau, le code est vulnérable... Mais il est probable que de plus grosses proies tombent avant ce weblog :-) D'autre part, le code valide les données qu'il recoit (notamment via l'utilisation d'une classe Requete fort pratique crée lors de mon premier stage chez OWS), donc ça devrait aller. Si toutefois vous trouver un problème manifeste, un petit mail à webmaster AT defr DOT org serait fortement apprécié ^^;

SSH: Authentification par clé, sous Linux | lundi 10 mars 2008, 12h57

Mood: Neutral

Voila un petit billet inspiré des instructions que Kévin a posté pour pouvoir se connecter par paire de clé sous Windows en utilisant Putty. Ce billet a en fait deux buts distincts:

  1. Fournir une documentation en français sur la façon de faire ça, car si les sources anglophones sont abondantes, il me semble qu'on ne peut pas en dire de même pour le web francophone.
  2. Montrer que c'est plus simple à mettre en oeuvre sous Linux ;-)

Commencons par satisfaire les gens pressés qui pourraient tomber sur ce post par Google: ce que vous souhaitez savoir se résume à quatres commandes

ssh-keygen eval `ssh-agent -s` ssh-add ssh-copy-id hostname

Maintenant que les gens pressés sont partis, rentrons dans le détail de ces différentes opérations ^^

Génération d'une paire de clé

Avant toute chose, pour pouvoir s'identifier sur un serveur avec une paire de clé (le même principe cryptographique que celui qui est utilisé pour pouvoir signer ses courriels, ou dans certains protocoles sécurisés comme HTTPS), il est necessaire de générer la-dites paire de clé, c'est-à-dire une clé publique, que l'on insérera sur l'ensemble des serveurs sur lesquels on veut pouvoir se connecter, et une clé privé qu'il est indispensable de conserver en lieu sur, et qui nous permettra de nous identifier.

Pour cela, on dispose d'une commande particulièrement utile, ssh-keygen, qui se charge de cette tâche. Il est possible de lui préciser le type de clé et la taille de cette dernière, ce qui donnerait quelque chose du genre ssh-keygen -t rsa -b 1024. L'emplacement par défaut nous conviendra dans 99% des cas, il est donc possible de simplement appuyer sur entrée pour répondre à la première question que la commande va alors poser. Il s'agit ensuite de choisir une phrase de passe, permettant de sécuriser la clé: je vous laisse seul juge, mais le champ s'appelle phrase de passe et non pas mot de passe pour une bonne raison ;-). Une fois cette formalité accomplie, ca y est, vous avez votre paire de clé

Une session en terminal typique générant cette paire de clé ressemble donc à :

defr_test@Albus> ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/defr_test/.ssh/id_rsa): Created directory '/home/defr_test/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/defr_test/.ssh/id_rsa. Your public key has been saved in /home/defr_test/.ssh/id_rsa.pub. The key fingerprint is: e8:f9:37:dc:3b:e0:c4:6c:00:c1:fb:c7:c3:f8:2d:28 defr_test@Albus

Lancement de votre agent d'identification

On entre désormais dans les opérations qui devront s'effectué à chaque fois que l'on souhaitera se connecter. Il est tout d'abord necessaire de lancer ssh-agent, via eval `ssh-agent -s`. Je vous conseille d'ajouter cela au lancement de votre session, donc à la fin de votre fichier .bashrc, .zshrc, ...

Validation de votre identité

Une fois l'agent lancé, potentiellement automatiquement si vous avez suivi le conseil de le lancer automatiquement lorsque vous ouvrez une session sur le système, il est necessaire de lui ajouter votre clé privé. Pour cela, il suffit d'utiliser ssh-add, qui vous demandera la phrase de passe qui a été utilisé lors de la création de la clé. Il est à noter que pour les personnes réfractaires au terminal, il est tout à fait possible d'utiliser gtk2-ssh-askpass, qui vous créera une jolie interface dans laquelle vous devrez taper la phrase de passe, mais je n'ai pas trop exploré cette option.

Une session comportant le lancement de ssh-agent et ssh-add ressemble à cela:

defr_test@Albus> eval `ssh-agent -s` Agent pid 12883 defr_test@Albus> ssh-add Enter passphrase for /home/defr_test/.ssh/id_rsa: Identity added: /home/defr_test/.ssh/id_rsa (/home/defr_test/.ssh/id_rsa)

Copie de votre clé publique sur un serveur distant

Il reste désormais une dernière étape, faire connaitre au serveur sur lequel vous souhaitez vous connectez la clé publique. Là encore, ssh fournit gentiment un utilitaire pour faire cela, ssh-copy-id. En supposant que vous souhaitiez ainsi pouvoir vous connecter par clé à l'hôte example.com, il vous suffit donc de taper dans votre gentil terminal ssh-copy-id example.com. Comme d'habitude, on vous demandera à cette connexion un mot de passe... et fera tout le reste tout seul ^^ Vous commencerez à voir la différence à partir de votre prochaine connexion en SSH à ce serveur: votre agent s'identifiera, et vous serez par conséquent automatiquement connecté, sans mot de passe supplémentaire à fournir.

Février 2008Avril 2008Mars 2008
Sites visités