Même si j’utilise un ordinateur en tant que développeur depuis longtemps, la configuration et l’administration de serveur n’est pas ma spécialité même si j’ai quelques notions (en plus je sais aussi lire les explication des autres).
Depuis quelques temps je me suis pris un abonnement pour un hébergement mutualisé chez OVH. Ce qui me fait choisir OVH, entre autre, est la possibilité d’avoir accès à un serveur svn (Subversion). Bien sur ce serveur svn n’est accessible que via un tunnel ssh car le connexion entre mon ordinateur et mon serveur se feront via Internet, qui n’est pas le meilleur endroit pour laisser trainer son code source, et non un réseau local (fermé par définition).
OVH a bien un tutoriel sur le sujet mais il est suffisamment léger pour que je me sois cassé les dents sur le sujet (moi et quelques personnes que je connais). L’une de ces personnes (mon frère) avait plus de temps que moi pour creuser le sujet et nous a fait un petit email pour résumé la procédure à suivre. Voici ses explications adapté a ma sauce après les avoir mis en œuvre.
Avant de commencer quelques explications :
- un texte comme ça correspond à une commande exécutée sur le client
- un texte comme ça correspond à une commande exécutée sur le serveur
De plus ces explications sont issus de tests effectués sous MacOSX. Ces explications sont donc valables pour tous systèmes Unix.
1. première connexion en ssh :
> ssh login_ssh@votredomaine.com
La première fois qu’on se connecte à un site en ssh, on a un message du genre
The authenticity of host 'votredomaine.com (213.186.33.4)' can't be established.
RSA key fingerprint is a1:b4:fa:5a:6d:80:00:2a:7c:fa:ec:27:7a:de:1d:17.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'votredomaine.com,213.186.33.4' (RSA) to the list of known hosts.
login_ssh@votredomaine.com's password:
En tapant “yes” et en entrant le mot de passe que vous avez reçu d’OVH une entrée est ajoutée dans le fichier ~/.ssh/known_hosts. Et normalement la question ne sera plus jamais posée. Vous pouvez effacer ce fichier ou bien l’éditer pour réinitialiser votre connexion à votre serveur ssh.
2. création du repository svn sur le serveur :
> mkdir svn
> svnadmin create svn/test
Si vous tappez la commande suivante :
> ls -al svn/test
Vous vevriez voir le résultat suivant :
drwxr-xr-x+ 7 hognon users 9 2009-10-12 22:37 .
drwxr-xr-x+ 3 hognon users 3 2009-10-12 22:37 ..
drwxr-xr-x+ 2 hognon users 5 2009-10-12 22:37 conf
drwxr-xr-x+ 2 hognon users 2 2009-10-12 22:37 dav
drwxr-sr-x+ 5 hognon users 10 2009-10-12 22:37 db
-r--r--r--+ 1 hognon users 2 2009-10-12 22:37 format
drwxr-xr-x+ 2 hognon users 11 2009-10-12 22:37 hooks
drwxr-xr-x+ 2 hognon users 4 2009-10-12 22:37 locks
-rw-r--r--+ 1 hognon users 229 2009-10-12 22:37 README.txt
Pour l’instant on laisse la configuration du serveur svn telle quelle.
3. création des clés publique/privée sur le client :
Maintenant il va falloir créer 2 clés : une pour la connexion ssh et une pour l’éxécution de svn via ssh. Pour créer les clés on utilise la command ssh-keygen. Lors de la génération d’une clé on vous demande d’entrer une passphrase. Pour mon test je n’en ai pas mis. Je penses qu’on peut en mettre une pour la clé utilisée pour la connexion ssh. Par contre svn via le tunnel ssh ne semble pas supporté d’avoir une passphrase sur la clé car dans ce cas les commandes svn ne passe (ssh doit attendre le passphrase et svn ne transmet pas le demande). Donc pour la 2ème clé il ne faut pas mettre de passphrase.
- la clé pour la connexion ssh :
> ssh-keygen -t dsa
Au final 2 fichiers sont créés : ~/.ssh/id_dsa et ~/.ssh/id_dsa.pub
> ssh-keygen -t dsa -f ./ssh/id_dsa_svn_ovh
Au final 2 fichiers sont créés : ~/.ssh/id_dsa_svn_ovh et ~/.ssh/id_dsa_svn_ovh.pub
4. ajout des clés sur le serveur :
Ces clés doivent être stockées dans le fichier .ssh/authorized_keys2 sur le serveur. Le créer si il n’existe pas.
> mkdir .ssh
> chmod 700 .ssh
On créé et on édite le fichier authorized_keys2 :
> vi .ssh/authorized_keys2
On insère les 2 clés publiques créées précedement. Chaque clé doit tenir sur une seule ligne.
1ère ligne:
mettre le contenu intégral du fichier id_dsa.pub qui se trouve chez le client2ème ligne:
command=”/usr/bin/svnserve –root=/homedirectory/login_ssh/svn –tunnel –tunnel-user=login_local”,no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
suivi (sur la même et sur une seule ligne) du contenu intégral du fichier
id_dsa_svn_ovh.pubqui se trouve chez le client.
- /homedirectory/login_ssh/ correspond au chemin ou se trouve votre compte chez ovh. Pour connaitre le votre il suffit de taper pwd sur le serveur.
- –tunnel-user=login_local : je vous conseils d’utiliser le login avec lequel vous êtes connecté sur votre machine qui sera de client svn.
5. Demander à svn d’utiliser une clé bien spécifique pour ses connexions ssh :
A ce stade, on devrait déjà pouvoir faire une connexion ssh sans demande de password par le serveur ssh. Par contre si lors de la génération de la clé vous avez entrez une pass phrase il faudra la rentrez maintenant. On peut la stocker dans le trousseau de MacOSX, c’est ce que j’ai fait.
ssh login_ssh@votredomaine.com
Quand on fait une connexion ssh, le client va voir s’il y a des clés registrées dans ~/.ssh/ Par défaut il va chercher id_dsa (clé qu’on a créé)
Pour dire à svn d’utiliser l’autre clé il faut register une variable d’environnement. Pour cela il suffit de taper
open ~/.MacOSX/environment.plist
Une fois dans l’interface ajouter une variable SVN_SSH dont la valeur est ssh -i ~/.ssh/id_dsa_svn_ovh (ici il faut peut être plutôt avoir un chemin absolue ssh -i /Users/login/.ssh/id_dsa_svn_ovh)
Pour que la variable soit effectivement affectée il faut fermer et relancer votre shell. On doit pouvoir aussi utiliser un .bash_profile ou autres en fonction de votre shell.
On devrait maintenant taper la commande suivante sur le client :
svn checkout svn+ssh://login_ssh@votredomaine.com/test/
6. Explications :
Dans le cas de la clé id_dsa_svn_ovh, on lui associe une commande sur le serveur. Ça veut en gros dire qu’un client qui se connecte avec cette clé aura un accès svn qui cache le chemin complet du répertoire svn et qui ne permet de rien faire d’autre. C’est pour ca que si on a que cette clé, une simple connexion ssh va foirer. Donc il a fallu créer une autre clé qui est celle utilisée par défaut pour la connexion ssh.
On sait jamais, si à un moment donné il y a un problème qui fait que vous n’arrivez plus du tout à vous connecter sur le serveur en ssh, pas de panique. Il suffit d’effacer tout le contenu du répertoire ~/.ssh/ sur le client. Et dans ce cas, ce sera comme si rien ne s’était passé.
7. Ouvrir l’accès svn pour d’autres utilisateur
Pour que d’autres utilisateurs aient accès à votre serveur svn via ssh chez ovh il suffit d’ajouter une ligne command par utilisateur supplémentaire. Par exemple si je veux ajouter un utilisateur “julien” j’ajouterais :
command=”/usr/bin/svnserve –root=/homedirectory/login_ssh/svn –tunnel –tunnel-user=julien“,no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
suivi (sur la même et sur une seule ligne) du contenu intégral de son fichier id_dsa_svn_ovh.pub.
Ensuite pour que julien accède à votre svn il lui suffira de faire comme vous :
svn checkout svn+ssh://login_ssh@votredomaine.com/test/
Avec le même login_ssh que vous. Il ne vous reste plus que correctement paramétrer vos différents dépôts svn pour que les différents utilisateurs n’accède que ce à quoi ils ont le droit. Pour cela il faudra utiliser les différents tunnel-user et leur attribuer des droits d’accès différents si nécessaire.
8. Et sous Windows, on fait comment ?
Comme sous MacOSX/Unix on va générer une couple clef public/privée : on le fait à l’aide de PuTTY Key Generator. Choisir SSH-2 DSA en bas à droite. Puis cliquer sur Generate. Ensuite vous générez une clef public (svn_ovh_pub) et une clef privé (svn_ovh.ppk). Avant de générer les clefs vous pouvez indiquer un mot de passe (passphrase). Je ne l’ai pas fait mais il me semble qu’avec TortoiseSVN et PuTTY il y a possibilité d’en utiliser un (sous Unix/MacOSX ça doit être possible aussi mais on n’a pas creuser le sujet pour l’instant).
Maintenant il faut copier la clef public sur votre serveur dans le fichier .ssh/authorized_keys2 (j’ai utilisé un login différent dans ce fichier mais je suis pas sur que ce soit utile). Puis en double cliquant sur le fichier ppk vous lancez Pagent (PuTTY authentication agent). Je ne sais pas encore si il y a une méthode particulière pour les démarrer automatiquement. Pour l’instant je le fais manuellement.
Pour finir assurer vous que votre client TortoiseSVN est bien configuré pour utiliser TortoisePlink.exe (TortoiseSVN -> Settings -> Network -> SSH Client -> indiquer le chemin vers TortoisePlink.exe qui se trouve dans le répertoire d’installation de TortoiseSVN). Ensuite il ne vous reste plus qu’à faire votre checkout avec l’url suivante : svn+ssh://login_ssh@votredomaine.com/test/.
. cette situation semble temporaire en attendant que le légal de chez Nintendo clarifie la situation.
.
