Métaphore

Bon, ne vous inquiétez pas, ceci n'a aucun intérêt.

Il m'arrive pour des besoins très spécifiques d'utiliser FreeNX, une solution de prise de contrôle à distance en mode graphique, mais le bouzin est fait pour fonctionner avec une authentification par mot de passe sur la machine distante, et ça m'arrange peu : les mots de passe, c'est naze, je préfère de loin l'authentification par clef publique. Comme je ne suis pas un spécialiste du truc, je me suis un peu gratté la tête pour comprendre, et ce par deux fois puisque j'ai eu à faire une réinstallation. Pour qu'il n'y aie pas de troisième fois, je prends quelques notes et oui, ici, parce que je ne sais pas trop où, et puis soyons fous, peut-être quelqu'un en aura-t'il l'usage un jour.

Finalement, c'est tout con.

Nous avons donc deux machines que nous appellerons le maison (la votre) et le loin (celle qui est loin.) et trois comptes : totor (c'est vous) qui se connecte sur votre machine : totor@maison, ou sur la machine distante : totor@loin, et le compte système de FreeNX sur la machine distante : nx@loin.

L'ouverture d'une session FreeNX pour Totor se passe comme suit : toto@maison ouvre une session ssh en tant que nx@loin, et celui-ci ouvre une session en tant que totor@loin. Par défaut, le client FreeNX s'occupe de la première liaison, avec une authentification par clef, et le serveur s'occupe de la seconde, avec une authentification par mot de passe (mot de passe que totor aura fourni au client, lequel n'en aura pas l'usage mais le transmettra au serveur.

Moi, au niveau sécurité, ça me fait lever deux sourcils. Le premier parce que la clef entre toto@maison et nx@loin est une clef par défaut, et si j'ai bien compris, c'est la même pour toutes les installations du serveur et toutes les installations du client. Le second parce que désolé, mais moi, l'authentification par mot de passe, je l'ai désactivée depuis longtemps.

Bon bah une fois qu'on a le schéma en tête, c'est pas bien compliqué (je pars du principe que vous savez créer une paire de clefs quand même) :

1. Dans le client FreeNX, vous pouvez changer la clef. Vous y mettez la clef privée de totor@maison.
2. Vous collez la clef publique de totor@maison dans les clefs autorisées de nx@loin. Normalement, c'est le fichier authorizedkeys ou authorizedkeys2 dans le sous répertoire .ssh du répertoire home de nx@loin (/var/lib/nxserver/home, par défaut.) Et je parle de remplacer le fichier, puisque si vous laissez la clef par défaut dedans, la manip ne sert à rien.
3. Vous créez une paire de clefs pour nx@loin et vous allez coller la clef publique dans les clefs autorisées de totor@loin.

Ben c'est tout bon.

Il y aura bien l'histoire des known_hosts, moi je passe au dessus d'une manière toute bête, qui m'arrange aussi pour tester mon installation, voire pour créer les clefs de nx@loin : avant ma manip, je vais modifier le /etc/passwd de la machine loin pour remplacer son shell (/user/lib/nx/nxserver) par un shell normal, genre /bin/bash. Avant de rétablir ce réglage et d'utiliser le client, on doit pouvoir, en console, ouvrir les sessions suivantes :

totor@maison:~# ssh nx@loin
ns@loin:~# ssh totor@localhost

Si les deux ouvertures de session fonctionnent, c'est bon, vous pouvez rétablir les réglages de nx@loin dans le /etc/passwd et utiliser le client.

Je ne suis sans doute pas très clair pour vous autres, mais pour moi, ça va.

(note : arrangez vous pour trouver un client dont le numéro de version est proche du numéro de version du serveur. Le client 2.0 sur un serveur 1.5, ça ne marche tout simplement pas.)