SSH sur lfo <author> <name> <htmlurl name="Gilles LAMIRAL" url="mailto:glamiral@linux-france.org?subject=lfoyer 0.01"> </name> </author> <date> $Revision: 1.10 $ $Date: 2002/08/27 19:23:47 $ </date> <abstract> Comment utiliser ssh sur linux-france.org </abstract> </titlepag> <toc> Version générée le Samedi 17 mars 2007  <#if output="html"> <htmlurl url="../.." name="Index des documents"> </#if> Vous trouverez la dernière version du présent document à l'adresse: <newline> <tt><url url="http://www.linux-france.org/prj/lfoyer"></tt> <sect>Historique de ce document <verb> $Log: ssh.fr.m4,v $ Revision 1.10 2002/08/27 19:23:47 gilles ssh v2 imposé Revision 1.9 2002/07/27 07:14:18 gilles Ajout d'urls, meilleurs explications. Revision 1.8 2002/06/07 23:33:44 gilles Ajout de la section "Historique de ce document" </verb> La lecture du présent document devrait suffire car il est adapté à la connexion sur linux-france.org, cependant, je vous mentionne deux autres documents qui peuvent vous aider en cas de problème : <itemize> <item>la section "Connexion à lfo" du document "maint" de Nat <newline> <url url="http://www.linux-france.org/maint/"> <item>la FAQ ssh<newline> <url url="http://www.employees.org/~satch/ssh/faq/"> </itemize> <sect>Disponibilité, version L'accès au serveur (tuxinette) du site lfo impose l'usage du protocole ssh version 2. <bf>Avez-vous ssh ?</bf> <verb> ssh -V </verb> La commande précédente vous renvoie la version de ssh utilisée, si ssh est installé sur votre machine. Si vous obtenez une réponse du type <tt>"ssh: command not found"</tt>, c'est qu'il n'est pas installé. Installez-le. <bf>Quelle version utiliser sous Unix ?</bf> La commande <tt>ssh -V</tt> donne sur le serveur et chez moi: <verb> tuxinette: OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f chez moi : OpenSSH_3.4p1 Debian 1:3.4p1-0.0potato1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f c'est du debian stable de base (pas besoin de recompiler openssh) </verb> Note: Pour ceux ayant un serveur sshd (inutile pour une connection sur lfo), il est recommandé de passer à la version 3.4p1 ou supérieure à cause d'un trou de sécurité dans les versions antérieures. <bf>Quelle version utiliser sous MSWindows ou Macintosh ?</bf> <tt><htmlurl url="http://www.openssh.com/windows.html"></tt>.<newline> <tt><htmlurl url="http://www.networksimplicity.com/openssh/"></tt>. <newline> <tt><htmlurl url="http://www.chiark.greenend.org.uk/~sgtatham/putty/"></tt>. <newline> Pour les maceux voir la page <url name="Nifty Telnet SSH" url="/article/cesar/nifty/"> de césar (limité à ssh v1 apparemment et donc inutilisable sur lfo) et surtout <url url="http://www.macssh.com/">, limité à ssh v2 mais utilisable sur lfo. <sect>Pour les impatients Résumé pour les impatients qui ne lisent pas et utilisent un Unix : <verb> # Vous êtes chez vous, sous un compte banalisé. cptlfo=toto # remplacez toto par votre compte sur lfo cd ls .ssh/id_dsa || ssh-keygen -t dsa ssh $cptlfo@linux-france.org ls rsync -e ssh ~/.ssh/id_dsa.pub $cptlfo@linux-france.org: ssh $cptlfo@linux-france.org 'cat id_dsa.pub >> ~/.ssh/authorized_keys' ssh $cptlfo@linux-france.org 'chmod -R g-w ~/' ssh $cptlfo@linux-france.org ls # plus besoin de mot de passe </verb> Si la dernière commande ne nécessite pas de donner le mot de passe, c'est que tout s'est bien passé, vous pouvez quitter la lecture de ce document. Sinon, les impatients doivent devenir patient et lire la suite pour comprendre où le problème se situe, et le régler. Pour les lecteurs moins impatients, les sections suivantes présentent les mêmes commandes expliquées en détail. <sect>Génération des clefs Avez-vous une clef privée et une clef publique ? <verb> # Vous êtes chez vous, sous un compte banalisé. cd ls .ssh/id_dsa </verb> Si vous obtenez une réponse du type: <verb> ls: .ssh/id_dsa: No such file or directory </verb> alors, vous n'avez pas de clef publique de type dsa. Créez vos clefs privée et publique avec la commande <verb> ssh-keygen -t dsa </verb> Deux possibilités. Soit vous fournissez une "passphrase" et dans ce cas souvenez-vous de votre "passphrase". Soit vous n'en fournissez pas, c'est plus simple car vous n'aurez même pas besoin d'agent ssh à gérer. <sect>premiers tests Testons la connexion ssh sur lfo. Dans les commandes suivantes remplaçez le compte <tt>"toto"</tt> par le votre sur lfo. La variable <tt>$cptlfo</tt> représente votre compte sur lfo et vous pouvez alors utiliser les commandes tel qu'elles sont écrites en faisant des simples copier-coller dans un shell Bourne (bash, sh mais pas csh) <verb> # Vous êtes chez vous, sous un compte banalisé. cptlfo=toto # remplacez toto par votre compte sur lfo ssh $cptlfo@linux-france.org ls </verb> La commande vous demande d'ajouter le site à la liste des machines connues. Vous répondez <tt>yes</tt>. <verb> "The authenticity of host 'linux-france.org' can't be established. Key fingerprint is 1024 f1:ac:4a:48:27:cc:3f:a6:fa:b1:6e:05:c8:35:bf:b7. Are you sure you want to continue connecting (yes/no)?" </verb> Ensuite, la commande vous demande le mot de passe (qui n'est pas la "passphrase") de votre compte sur lfo mais simplement le mot de passe unix de votre compte sur lfo. Une fois la connexion authentifiée, la commande ls s'exécute sur lfo et vous liste les fichiers et répertoires de votre compte sur lfo. <sect>Automatisation, cas "passphrase" vide Il est parfois usant de donner le mot de passe à chaque commande lancée. C'est le cas notamment avec l'utilisation de cvs. Nous allons donc mettre en place un mécanisme qui permet de ne plus avoir à donner de mot de passe. Commençons: <verb> ssh $cptlfo@linux-france.org ls </verb> La commande vous demande encore le mot de passe de votre compte unix sur le site lfo. Nous n'avons pas encore copié votre clef publique sur le site lfo. Pour cela il faut copier votre clef publique, c'est à dire le contenu du fichier <tt>~/.ssh/id_dsa.pub</tt> (situé chez vous) dans le fichier <tt>~/.ssh/authorized_keys</tt> de votre compte sur lfo. <verb> rsync -e ssh ~/.ssh/id_dsa.pub $cptlfo@linux-france.org: ssh $cptlfo@linux-france.org 'cat id_dsa.pub >> ~/.ssh/authorized_keys' ssh $cptlfo@linux-france.org 'chmod -R g-w ~/' </verb> Voila. recommençons: <verb> ssh $cptlfo@linux-france.org ls </verb> Cette fois, la commande <tt>ssh</tt> ne vous demande plus rien et exécute directement la commande <tt>ls</tt>. Cela vous semble surement un peu compliqué et encore trop lourd. Vous n'avez plus à taper de mot de passe, il n'y a pas plus simple. <sect>Automatisation, cas "passphrase" non vide Il est parfois usant de donner le mot de passe à chaque commande lancée. C'est le cas notamment avec l'utilisation de cvs. Nous allons donc mettre en place un mécanisme qui permet de ne donnez qu'une seule fois un mot de passe pour l'ensemble des connexions ssh d'une session, au cas où vous utilisez une passphrase non vide. Lancement de l'agent <verb> ssh-agent </verb> Cette commande lance un agent ssh et génère sur la sortie standard des commandes permettant de l'utiliser. Vous copier-collez ces commandes dans votre shell. Par exemple: <verb> SSH_AUTH_SOCK=/tmp/ssh-IVmE4635/agent.4635; export SSH_AUTH_SOCK; SSH_AGENT_PID=4636; export SSH_AGENT_PID; echo Agent pid 4636; </verb> Suivi de la commande: <verb> ssh-add </verb> Là, vous fournissez la "passphrase", qui peut être vide. Ensuite, recommençons: <verb> ssh $cptlfo@linux-france.org ls </verb> La commande vous redemande encore le mot de passe de votre compte unix sur le site lfo. Nous n'avons pas encore copié votre clef publique sur le site lfo. Pour cela il faut copier votre clef publique, c'est à dire le contenu du fichier <tt>~/.ssh/id_dsa.pub</tt> (situé chez vous) dans le fichier <tt>~/.ssh/authorized_keys</tt> de votre compte sur lfo. <verb> rsync -e ssh ~/.ssh/id_dsa.pub $cptlfo@linux-france.org: ssh $cptlfo@linux-france.org 'cat id_dsa.pub >> ~/.ssh/authorized_keys' </verb> Voila. recommençons: <verb> ssh $cptlfo@linux-france.org ls </verb> Cette fois, la commande <tt>ssh</tt> ne vous demande plus rien et exécute directement la commande <tt>ls</tt>. Cela vous semble surement un peu compliqué et encore trop lourd. Cependant pour une nouvelle session, vous n'avez plus besoin que d'exporter les variables d'environnement <tt>$SSH_AGENT_PID</tt> <tt>$SSH_AUTH_SOCK</tt> et de la commande <tt>ssh-add</tt>. Pour généraliser le mecanisme à l'ensemble de votre session X window, il est nécessaire que ces variables d'environnement soient définies avant le lancement du serveur X, qui les exportera par défaut à l'ensemble de vos applications graphiques (lancées sous X). Cela peut être fait dans le fichier <tt>startx</tt> ou bien <tt>~/.xinitrc</tt> ou bien <tt>~/.xsession</tt>, en résumé avant le lancement de votre gestionnaire de fenêtres. Par exemple, si c'est le fichier <tt>~/.xinitrc</tt> qui lance le gestionnaire de fenêtres, il ressemblera à ceci: <verb> #!/bin/sh ssh-agent -s > /tmp/ssh.hskepzj . /tmp/ssh.hskepzj rm /tmp/ssh.hskepzj exec enlightenment </verb> Ainsi, au prochain lancement d'un serveur X, vous n'aurez plus qu'à ouvrir une <tt>xterm</tt> et taper la commande: <verb> ssh-add </verb> Nous pouvons allez plus loin et lancez la demande automatiquement en ajoutant la commande suivante dans le fichier <tt>~/.xinitrc</tt>, juste avant le lancement du gestionnaire de fenêtre (<tt>exec enlightenment</tt>) <verb> xterm -e ssh-add </verb> <sect>Conclusion Ainsi, vous n'aurez plus à taper de mot de passe pour l'ensemble des machines et comptes qui connaissent votre clef publique, tout en restant dans un environnement continuellement crypté. Merci ssh. </article>