SSH sur lfo Gilles LAMIRAL $Revision: 1.10 $ $Date: 2002/08/27 19:23:47 $ Comment utiliser ssh sur linux-france.org ______________________________________________________________________ Table des matières 1. Historique de ce document 2. Disponibilité, version 3. Pour les impatients 4. Génération des clefs 5. premiers tests 6. Automatisation, cas "passphrase" vide 7. Automatisation, cas "passphrase" non vide 8. Conclusion ______________________________________________________________________ Version générée le Samedi 17 mars 2007 Vous trouverez la dernière version du présent document à l'adresse: 1. Historique de ce document $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" 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 : · la section "Connexion à lfo" du document "maint" de Nat · la FAQ ssh 2. Disponibilité, version L'accès au serveur (tuxinette) du site lfo impose l'usage du protocole ssh version 2. Avez-vous ssh ? ssh -V 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 "ssh: command not found", c'est qu'il n'est pas installé. Installez- le. Quelle version utiliser sous Unix ? La commande ssh -V donne sur le serveur et chez moi: 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) 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. Quelle version utiliser sous MSWindows ou Macintosh ? . . . Pour les maceux voir la page Nifty Telnet SSH de césar (limité à ssh v1 apparemment et donc inutilisable sur lfo) et surtout , limité à ssh v2 mais utilisable sur lfo. 3. Pour les impatients Résumé pour les impatients qui ne lisent pas et utilisent un Unix : # 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 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. 4. Génération des clefs Avez-vous une clef privée et une clef publique ? # Vous êtes chez vous, sous un compte banalisé. cd ls .ssh/id_dsa Si vous obtenez une réponse du type: ls: .ssh/id_dsa: No such file or directory alors, vous n'avez pas de clef publique de type dsa. Créez vos clefs privée et publique avec la commande ssh-keygen -t dsa 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. 5. premiers tests Testons la connexion ssh sur lfo. Dans les commandes suivantes remplaçez le compte "toto" par le votre sur lfo. La variable $cptlfo 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) # Vous êtes chez vous, sous un compte banalisé. cptlfo=toto # remplacez toto par votre compte sur lfo ssh $cptlfo@linux-france.org ls La commande vous demande d'ajouter le site à la liste des machines connues. Vous répondez yes. "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)?" 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. 6. 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: ssh $cptlfo@linux-france.org ls 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 ~/.ssh/id_dsa.pub (situé chez vous) dans le fichier ~/.ssh/authorized_keys de votre compte sur lfo. 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 ~/' Voila. recommençons: ssh $cptlfo@linux-france.org ls Cette fois, la commande ssh ne vous demande plus rien et exécute directement la commande ls. 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. 7. 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 ssh-agent Cette commande lance un agent ssh et génère sur la sortie standard des commandes permettant de l'utiliser. Vous copier-collez ces comman- des dans votre shell. Par exemple: SSH_AUTH_SOCK=/tmp/ssh-IVmE4635/agent.4635; export SSH_AUTH_SOCK; SSH_AGENT_PID=4636; export SSH_AGENT_PID; echo Agent pid 4636; Suivi de la commande: ssh-add Là, vous fournissez la "passphrase", qui peut être vide. Ensuite, recommençons: ssh $cptlfo@linux-france.org ls 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 ~/.ssh/id_dsa.pub (situé chez vous) dans le fichier ~/.ssh/authorized_keys de votre compte sur lfo. rsync -e ssh ~/.ssh/id_dsa.pub $cptlfo@linux-france.org: ssh $cptlfo@linux-france.org 'cat id_dsa.pub >> ~/.ssh/authorized_keys' Voila. recommençons: ssh $cptlfo@linux-france.org ls Cette fois, la commande ssh ne vous demande plus rien et exécute directement la commande ls. 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 $SSH_AGENT_PID $SSH_AUTH_SOCK et de la commande ssh-add. 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 startx ou bien ~/.xinitrc ou bien ~/.xsession, en résumé avant le lancement de votre gestionnaire de fenêtres. Par exemple, si c'est le fichier ~/.xinitrc qui lance le gestionnaire de fenêtres, il ressemblera à ceci: #!/bin/sh ssh-agent -s > /tmp/ssh.hskepzj . /tmp/ssh.hskepzj rm /tmp/ssh.hskepzj exec enlightenment Ainsi, au prochain lancement d'un serveur X, vous n'aurez plus qu'à ouvrir une xterm et taper la commande: ssh-add Nous pouvons allez plus loin et lancez la demande automatiquement en ajoutant la commande suivante dans le fichier ~/.xinitrc, juste avant le lancement du gestionnaire de fenêtre (exec enlightenment) xterm -e ssh-add 8. 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.