Cette page a pour but de rassembler toutes les astuces qui peuvent simplifier la vie grace à ssh. <> = .ssh/config = ''Extrait du wiki du CMLA, auteur : Nicolas Limare'' Il est possible de "préconfigurer" les connexions ssh dans le fichier `.ssh/config` (le répertoire `.ssh` est à la base de votre répertoire personnel). '''alias de machine''' {{{ host zamok hostname zamok.crans.org }}} '''présélection des identifiants''' {{{ host zamok hostname zamok.crans.org user }}} '''présélection des clés ssh''' {{{ host zamok hostname zamok.crans.org user identityfile /home//.ssh/id_dsa }}} '''connexions enchaînées''' {{{ host zamok hostname zamok.crans.org user identityfile /home//.ssh/id_dsa forwardagent yes }}} '''proxy''' {{{ host iris hostname iris.crans.org user identityfile /home//.ssh/id_dsa proxycommand ssh zamok nc -q 30 %h %p }}} = Accéder à un réseau interne = Dans le cas où l'on veut se connecter à une machine d'un réseau interne qui n'est pas accessible directement mais pour lequel il y a au moins une machine qui accepte le ssh. On peut inscrire dans le fichier {{{~/.ssh/config}}} les lignes suivantes : {{{ Host machine_accessible.reseau.interne # par exemple acces1.rip.ens-cachan.fr ProxyCommand none Host *.réseau.interne # par exemple *.rip.ens-cachan.fr user son_login ProxyCommand ssh son_login@machine_accessible.reseau.interne "nc -w1 %h %p" }}} Ensuite ssh fera le saut de façon transparente quand on lancera la commande {{{ssh une_machine.reseau.interne}}} La première partie n'est nécessaire que si la machine accessible matche le {{{*.réseau.interne}}}. On peut l'omettre sinon. Dans cet exemple, ce n'est pas nécessaire : {{{ Host *.crans.org IdentityFile ~/.ssh/crans/clef Host *.adm.crans.org ProxyCommand ssh egon.crans.org "nc -w1 %h %p" }}} En effet, la machine sur laquelle on saute ({{{egon.crans.org}}}) n'est pas dans le réseau {{{adm.crans.org}}}. {i} il faut que {{{netcat}}} soit installé sur la machine du milieu (c'est le cas dans 99.999% des cas, sauf à l'ENS). S'il n'est pas installé, un coup de {{{scp /bin/nc user@machine_accessible.reseau.interne:}}} (en remplaçant bien sûr {{{nc}}} ci dessus par {{{~/nc}}}) fera l'affaire, si toute fois on a la même architecture que la machine accessible. De plus certaines versions de netcat ne semblent pas connaître l'option "-w1". {i} On peut aussi essayer {{{tcpconnect %h %p}}} à la place de {{{nc -w1 %h %p}}}. {i} Il peut être utile de remplacer le %h par le vrai nom d'hôte. Par exemple si l'on a défini dans son fichier 'hosts' 138.231.jesaispasquoi labo, un ssh user@labo ne va pas marcher si le nc %h est fait sur une machine qui ne connaît pas ce nom d'hôte maison = SSH à travers un proxy = Dans cerains cas, les serveus proxy autorisent le tranfert des connexions vers le port 22. Mais, dans la plupart des cas, les serveur proxy n'autorisent de transférer (méthode ''connect'' du proxy) que les ports 443 (utilisé par défaut pour l'https). On peut donc passer à travers un proxy dans l'un des deux cas suivants : * le serveur ssh distant tourne sur le port 443 * le proxy autorise la méthode connect sur le port 22 Zamok est disponible soit sur le port 22 (IP {{{138.231.136.1}}} alias {{{ssh.crans.org}}}), soit sur le port 443 (IP {{{138.231.136.2}}} alias {{{ssh2.crans.org}}}). Tous les adhérents peuvent utiliser ce service. == Avec OpenSsh sous Linux == Sous linux il faut : * installer '''corkscrew''' * modifier son fichier ''~/.ssh/config'' {{{ Host zamok-via-proxy ProxyCommand corkscrew ip.du.serveur.proxy portduproxy ssh2.crans.org 443 user tonlogin }}} Ensuite pour se connecter, il suffit de tapper '''ssh zamok-via-proxy''' dans une console et de s'authentifier. == Avec Putty sous Windows == Il suffit d'aller dans le menu '''Connection/Proxy''' et de renseigner les paramètres : * Proxy type : HTTP * Proxy hostname : ip.du.serveur.proxy * Port : port du serveur proxy (3128 ou 8080 par exemple) Pour éviter de voir sa connection fermée par timeout, on peut demander à putty d'envoyer régulièrement des paquets (via le paramètre '''Connection/Seconds between keep alive'''. = Faire un tunnel SSH = Le protocole SSH permet de créer un tunnel, permettant de faire transiter des connexions par ce tunnel et de demander à la machine distante d'effectuer ces connexions à votre place. Par exemple, en lançant un tunnel SSH vers une machine B et un utilisant le tunnel, les connexions que vous ferez à travers le tunnel apparaîtront pour le site distant comme venant de la machine B, et non de votre machine. Ca peut servir : * Pour se connecter à des sites accessibles seulement depuis un réseau interne * Pour contourner des limitations (par exemple, sur le réseau ouvert de l'ENS Cachan) * Et plein d'autres choses ... == Rediriger un seul port == Parfois, vous n'avez besoin de rediriger qu'un seul port (accéder à une seule machine sur un seul port). Exemple : vous voulez accéder au site {{{mon.site.interne}}} sur le port 80, et vous ne pouvez le faire que depuis une machine machine_accessible. Ici, on va rediriger le port local 3128 vers le port 80 de {{{mon.site.interne}}}. * Avec OpenSSH : {{{ ssh -L 3128:mon.site.interne:80 -N login@machine_accessible}}} ''L'option {{{-N}}} n'est pas nécessaire; elle spécifie que l'on n'a pas besoin d'ouvrir un terminal sur la machine distante. (On n'a donc pas de ligne de commande en même temps que la redirection.)'' * Avec PuTTY : Lors de la configuration de la connexion, * Aller dans {{{Connexion > SSH > Tunnels}}} * Mettre 3128 dans {{{Source port}}} * Mettre {{{mon.site.interne:80}}} dans {{{Destination}}} * Ne pas oublier de cliquer sur le bouton {{{Ajouter}}}. Ainsi, toute connexion au port local 3128 sera redirigée vers le port 80 de {{{mon.site.interne}}} : par exemple, taper {{{http://localhost:3128}}} dans un navigateur affichera la page {{{http://mon.site.interne}}}. == Créer un tunnel Socks == Si vous voulez rediriger plusieurs connexions par le même tunnel, c'est mieux de lancer un tunnel Socks, car cela permet d'utiliser le même tunnel avec des hôtes de destination différents. Pour plus d'informations sur comment utiliser un serveur Socks, regardez ../ConfigurationSocks . Ici, on va lancer un serveur Socks sur le port local 12345, et les connexions passant par ce serveur seront émises depuis {{{machine_distante}}}. * Avec OpenSSH : {{{ ssh -D 12345 -N login@machine_distante}}} * Avec PuTTY : Lors de la configuration de la connexion, * Aller dans {{{Connexion > SSH > Tunnels}}} * Mettre 12345 dans {{{Source port}}} * Cocher {{{Dynamique}}} * Ne pas oublier de cliquer sur le bouton {{{Ajouter}}}. = sshfs = == Présentation == Comme son nom le suggère, '''sshfs''' est un système de fichier basé sur le protocole SSH. '''sshfs''' est basé sur [[http://fuse.sourceforge.net/|fuse]] (système de fichier en userspace pour Linux, la même chose que ce qui est utilisé par encfs pour crypter des répertoires), donc nimporte quel utilisateur pourra ensuite monter ce système de fichier sans être root (il faudra tout de même qu'il fasse parti du groupe fuse) et sans aucune modification du fichier {{{/etc/fstab}}}. La page du site officiel : http://fuse.sourceforge.net/sshfs.html Il existe aussi shfs basé sur lufs, mais ces projets ont l'air un peu morts, rendus obsolètes par fuse. || /!\ '''Mise en garde''' ||<#FFFFA0> Si vous utilisez sshfs sur zamok au sein du réseau crans, il n'y aura pas de problème puisque les transferts de données seront limités à zamok et votre machine et par conséquent ne quitteront pas le réseau. En revanche, soyez prudents si vous montez un répertoire de votre home sur zamok à partir de l'extérieur du réseau crans. En effet, toute manipulation sur ce répertoire et les fichiers qu'il contient générera une quantité non nulle d'upload à partir de zamok et en direction de l'extérieur, ce qui peut être lourdement sanctionné si cette dernière devient significative.|| == Installation == === Côté serveur === Si le serveur possède déja un serveur SSH, alors il n'y a rien à faire. === Côté client === Il est nécessaire d'avoir le module de noyau fuse. Sous debian, un simple {{{ aptitude install sshfs }}} suffit pour l'installation, la dépendance envers fuse étant automatiquement résolue. Il faut ajouter les utilisateurs autorisés à monter des volumes ''via'' sshfs au groupe {{{fuse}}}. Pour cela : {{{ adduser utilisateur fuse }}} == Usage == === Montage === L'utilisateur côté client n'a juste qu'à tapoter sur son clavier :{{{ sshfs machinedistante: pointdemontage }}} et entrer un mot de passe si nécessaire (cas de pas de clefs). Si le nom d'utilisateur distant est différent, alors on remplacera {{{machinedistante}}} par {{{utilisateur@machinedistante}}}. Par défaut, cela monte le home de l'utilisateur. Pour changer, il suffit de spécifier un autre répertoire après {{{:}}}. === Démontage === Lorsque l'on a fini, pour démonter il suffit de tapoter :{{{ fusermount -u pointdemontage }}} === Options intéressantes === Pour un descriptif complet des options : {{{ man sshfs }}} À mon humble avis, l'option la plus intéressante est {{{-C}}} qui active la compression (permet de limiter le volume d'upload). Sinon, on peut également changer le port de connexion distant avec {{{-P}}} et tout plein d'autres choses que je n'ai pas envie de décrire. Par défaut, le '''''caching''''' est utilisé, ce qui est plutôt bien. == Intérêt == Pour l'instant, si vous êtes habitué de {{{ssh}}} et {{{scp}}}, vous ne voyez peut être pas encore ce que cela apporte de plus. Voici quelques intérêts que je lui trouve (à compléter si vous avez d'autres idées). * Cela correspond bien à la philosophie d'UNIX où tout est fichier. * On a un serveur de fichiers distant bien moins chiant à configurer que NFS, CIFS/Samba, CODA et en plus sécurisé par défaut (par contre, à la base SSH n'est pas fait pour ça donc il doit y avoir des inconvénients par rapport aux vrais systèmes de fichiers réseau). * Une fois le système monté, on peut utiliser les commandes classiques directement dans son arborescence locale de manière transparente (par exemple cp, mv, rm, plutôt que de s'embêter à coup de scp). * On peut utiliser des programmes que l'on dispose sur la machine locale (et qui ne sont pas sur la machine distante) pour travailler sur des fichiers distants. Exemple : vous disposez de fichiers photos sur zamok. Vous faites {{{ sshfs login@ssh.crans.org: zamok/ gqview zamok/ & }}} Et vous pouvez visualiser directement ces photos. De même, vous pouvez aussi éditer les fichiers html de votre site web avec votre éditeur préféré qui n'est pas forcement installé sur zamok (bon les utilisateurs d'Emacs avaient déjà tramp). * On a l'impression d'avoir un gros disque dur :{{{ ~; df -h zamok Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur sshfs#rozel@ssh.crans.org: 7,5T 0 7,5T 0% /home/benoit/zamok }}} Il faut cependant faire attention, il y a un quota qui limite la taille de ce répertoire. * À compléter (je suis sur qu'il y a encore plein d'autres petites astuces pratiques)... = Problèmes d'encodage = Pour se connecter à une machine en ISO ( par exemple zamok ) depuis un terminal en utf-8, une des solutions pour éviter des problèmes d'accents est d'utiliser Luit qui effectue une traduction simultanée entre les deux encodages: {{{ luit -encoding ISO8859-15 ssh login@zamok }}} ---- CatégoriePagePublique