Taille: 12128
Commentaire:
|
Taille: 19764
Commentaire:
|
Texte supprimé. | Texte ajouté. |
Ligne 1: | Ligne 1: |
Cette page a pour but de rassembler toutes les astuces qui peuvent simplifier la vie grace à ssh. | Cette page a pour but de rassembler toutes les astuces qui peuvent [[https://www.youtube.com/watch?v=vxmYOZCnB5w|changer la vie]] avec SSH. |
Ligne 5: | Ligne 5: |
= .ssh = Dans votre home, il y a potentiellement un dossier {{{.ssh}}}. Si il n'y est pas, vous pouvez le créer. Attention il doit avoir les droits {{{rwx------}}} (700). {{{ $ cd $ mkdir .ssh $ chmod 700 .ssh }}} On peut placer dans ce dossier tout un tas de choses intéressantes, notamment des [[../ConnexionSsh#Les_clefs_SSH|clés SSH]] ou un [[#A.ssh.2Fconfig|fichier de configuration]], dont vous allez rapidement vous demander comment vous faisiez pour vous en passer avant. |
|
Ligne 7: | Ligne 17: |
''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 <login> }}} '''présélection des clés ssh''' {{{ host zamok hostname zamok.crans.org user <login> identityfile /home/<user>/.ssh/id_dsa }}} '''connexions enchaînées''' {{{ host zamok hostname zamok.crans.org user <login> identityfile /home/<user>/.ssh/id_dsa forwardagent yes }}} '''proxy''' {{{ host iris hostname iris.crans.org user <login> identityfile /home/<user>/.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 : |
Ce fichier permet d'appliquer automatiquement des paramètres de configuration quand on ouvre une connexion SSH. En gros, on tape moins de chose pour en faire plus. == Fichier tout fait == Les cranseux mettent à votre disposition un fichier de config déjà tout fait avec plein de trucs dedans, allez voir [[VieCrans/FichiersConfiguration#config|ici]]. Si vous voulez en comprendre le contenu, il est bourré de commentaire, maison va expliquer des bases dans les paragraphes suivant. == Syntaxe == Vous pouvez placer des paramètres de configuration sans indentation, et faire des blocs Host. Exemple : {{{ HashKnownHosts no Host machin ForwardAgent yes Host bidule HashKnownHosts yes }}} Alors, pour toute connexion SSH que vous ouvrez, vous aurez le paramètre {{{HashKnownHosts}}} à no, sauf pour bidule, où il sera à yes. Si vous vous connectez à la machine "machin", vous aurez bien {{{HashKnownHosts}}} à no et en plus {{{ForwardAgent}}} à yes. == Alias de machine == Parce que taper {{{ssh zamok}}}, c'est nettement mieux que {{{ssh zamok.crans.org}}}. {{{ Host zamok adherents HostName zamok.crans.org }}} Alors taper {{{ssh zamok}}} ou {{{ssh adherents}}} reviendra à taper {{{ssh zamok.crans.org}}}. Vous pouvez mettre autant d'alias que vous voulez sur la ligne {{{Host}}} en les séparant par des espaces. == Spécifier un login == Par défaut, si vous ne précisez rien, SSH utilise votre login actuel, mais comme vous ne vous appelez pas forcément pareil sur toutes vos machines, il faut pouvoir spécifier un login. Vous pouvez utiliser {{{ssh login@machine}}} ou {{{ssh machin -l login}}}, mais le mieux, c'est encore de le mettre une fois pour toutes dans le {{{.ssh/config}}} et de ne plus avoir besoin de le préciser à chaque fois. {{{ Host zamok HostName zamok.crans.org User monlogin }}} Bien entendu, si vous spécifiez quelque chose en commandline (avec {{{@}}} ou {{{-l}}}), c'est prioritaire. == Sécification de clé SSH == Par défaut, SSH regarde les clés dans {{{/home/username/.ssh/}}} et les essaye toutes. Mais vous n'avez le droit qu'à un nombre d'essais limité, donc si vous avez beaucoup de clés, ça peut poser problème. Et puis vous avez le droit de ranger vos clés à un endroit bizarre que SSH n'aura pas forcément l'idée de tester. {{{ Host zamok HostName zamok.crans.org User monlogin IdentityFile /path/vers/cle/privee/id_rsa }}} == Connexions enchaînées == Si vous avez un [[../ConnexionSsh#Utiliser_la_cl.2BAOk-|agent SSH]] qui retient vos clés, sachez que, par défaut, ça ne marche que depuis votre machine vers une autre. Je développe : si vous faites {{{ssh zamok}}} depuis votre machine, votre agent est sur votre machine et permet donc l'accès à votre clé et vous pouvez entrer sur zamok. Si vous faites {{{ssh tahines}}} depuis votre machine, pareil. Mais si vous faites {{{ssh zamok}}}, puis une fois sur zamok, {{{ssh tahines}}}, cette fois-ci, on va vous demander un mot de passe. C'est parce que zamok ne sait pas que vous avez votre agent chez vous et n'a aucun moyen de le joindre. Vous pouvez explicitement demander à votre agent de "venir avec vous" sur zamok : {{{ Host zamok HostName zamok.crans.org User monlogin ForwardAgent yes }}} Alors, quand vous arriver sur zamok, vous allez automatiquement ouvrir une socket (stockée dans le {{{/tmp}}} de zamok) vers votre agent SSH sur votre machine. Ainsi, quand vous ferez ensuite "ssh tahines", SSH pourra utiliser cette socket pour comuniquer avec votre agent chez vous, et vous aller rentrer sur tahines sans fournir de mot de passe. Donc il faut bien retenir que l'agent reste toujours sur votre machine, le {{{ForwardAgent}}} permet la création de socket pour remonter vos connexions. (Par exemple, si vous avez correctement spécifié le paramètre de conf aussi pour tahines, en arrivant dessus, vous ouvrirez une socket pour comuniquer avec celle de zamok, elle-même toujours en relation avec votre agent chez vous, et ainsi de suite…). '''Attention''' : cette socket est protégées en lecture/écriture pour que seul vous y ayez accès. Cependant, root n'est pas limité par ce genre de restriction, donc, toute personne root sur la machine où vous forwardez votre agent peut accéder à cette socket. Cela lui donne la possibilité de se loguer en votre nom sur toute machine où vous avez placé un clé publique dont la clé privée est déverrouillée dans la mémoire de votre agent. Détail intéressant : il ne peut faire ça que tant que vous ne fermez pas votre connexion à votre agent. En effet, cette socket ne lui donne pas accès directement à votre clé, mais lui permet de demander à votre agent de résoudre un challenge SSH (en pratique, la clé privée ne quitte jamais la mémoire de votre machine, c'est la machine sur laquelle vous voulez vous connecter qui chiffre un truc avec votre clé publique, vous l'envoie, et si vous arrivez à le déchiffrer (et c'est ce que fait l'agent), c'est que vous possédez bien la clé privée, donc vous pouvez entrer). == Proxy == Il arrive qu'une machine ne soit pas accessible directement, pour des raisons de firewalling ou de [[CransTechnique/AdminRéseau/VLAN|VLANs]], par exemple. Dans ce cas, il faut passer par une autre machine pour accéder à votre cible, mais plutôt que d'établir manuellement cette connexion à la première puis d'aller sur la deuxième, autant le faire automatiquement : {{{ Host tselin HostName tselin.clietu.ens-cachan.fr User loginENS ProxyCommand ssh loginENS@tahines.ens-cachan.fr -W %h:%p }}} Ainsi, lorsque vous chercherez à accéder à tselin, SSH passera automatiquement par tahines. == Connexions master == Le principe des connexion master est d'ouvrir une connexion une seule fois vers un serveur, et toutes les connexions suivantes que vous ouvrirez vers le même hôte passeront par la même connexion TCP. Cela permet d'ouvrir plus rapidement les connexion suivantes, et de ne pas emplafonner des limites telles que le nombre de connexions SSH par minute que vous avez le droit d'établir à travers un firewall comme celui de komaz. {{{ Host zamok Hostname zamok.crans.org ControlMaster auto ControlPath ~/.ssh/master-%r-%h:%p }}} {{{ControlPath}}} est l'endroit où sera stockée la socket dans votre arborescence de fichiers. %r sera remplacé par le login distant, %h par le nom de l'hôte distant et %p par le port de connexion. Cela permet que les sockets soient stockées dans des noms distincts, sinon ça risque de créer des problèmes. == Blocs sioux == === Serveur du crans === Il y a moyen de définir un seul bloc de config pour se connecter sur tous les serveurs du crans. {{{ Host *,c proxycommand nc -q 30 $(echo %h | sed -r 's/..$//').crans.org %p username loginCrans }}} Avec ça vous pouvez faire `ssh zamok,c` `ssh rouge,c` ou encore `ssh vo,c`. === Tunnel en passant par un serveur truc === En imaginant que vous faisiez régulièrement des connexions en passant par l'hote truc vers des cibles variés {{{ Host *,t proxycommand ssh truc nc -q 30 $(echo %h | sed -r 's/..$//') %p }}} En hop, pour se conecter à une cible nommée cible en passant par truc, quelque soit la cible, il suffit de faire `ssh cible,t` === Tunnel généraux === Dans le cas où vous faisez des tunnels en passant par divers serveurs, une version plus détaillée {{{ Host *,T proxycommand ssh $(echo %h | cut -d , -f 2) nc -q 30 $(echo %h | cut -d , -f 1) %p }}} Ainsi pour se connecter sur une cible nommée cible en passant par un relai nommé relai, il suffit de faire `ssh cible,relai,T` = Contourner les ports bloqués = Parfois, vous êtes dans un environnement réseau que vous ne contrôlez pas, et qui est méchant avec vous (stage, labo, résidence étudiante pas couverte par le Cr@ns, box bizarre…). Il arrive donc que les ports que vous aimeriez contactés vous soient interdits. Par exemple, si votre "Internet" décide que vous n'avez pas le droit de parler à un port 22, vous ne pouvez pas contacter des serveurs en SSH ''a priori''. Là où on commence à voir une solution, c'est qu'en général, les ports 80 et 443 ne sont pas bloqués (parce que, quand même, on vous laisse faire du HTTP(S) pour aller sur facebook). Donc vous avez le droit de parler au monde sur le port 443. Seulement voilà, en général sur ce port, il n'y a pas un serveur SSH mais un serveur web, justement. Mais la bonne nouvelle, c'est que les cranseux y ont pensé ! On peut donc contacter {{{ssh2.crans.org}}} sur le port 443 et tomber sur un serveur SSH. (En fait, quand vous contactez le port 443 de l'IP {{{138.231.136.2}}} ({{{ssh2.crans.org}}}), il est redirigé vers le port 22 de {{{138.231.136.1}}} ({{{zamok.crans.org}}}).) Tous les adhérents disposant d'un compte Cr@ns peuvent utiliser ce service. = Via proxy HTTP = {{{#!wiki tip Astuce précédemment nommée '''SSH à travers un proxy''', mais je dois avouer que je comprends pas trop ce dont il est question… -- [[Wiki20-100]] <<DateTime(2014-07-24T19:08:37+0200)>> }}} Dans certains cas, les serveurs proxy autorisent le transfert des connexions vers le port 22. Mais, dans la plupart des cas, les serveurs 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 : |
Ligne 88: | Ligne 177: |
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. |
|
Ligne 96: | Ligne 183: |
{{{ | {{{ |
Ligne 98: | Ligne 185: |
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. |
ProxyCommand corkscrew ip.du.serveur.proxy portduproxy ssh2.crans.org 443 User monlogin }}} Ensuite pour se connecter, il suffit de tapper {{{ssh zamok-via-proxy}}} dans une console et de s'authentifier. |
Ligne 111: | Ligne 198: |
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'''. | Pour éviter de voir sa connexion fermée par timeout, on peut demander à Putty d'envoyer régulièrement des paquets (via le paramètre '''Connection/Seconds between keep alive'''). |
Ligne 114: | Ligne 201: |
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 : | 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. Ça peut servir : |
Ligne 117: | Ligne 204: |
* Et plein d'autres choses ... | * Et plein d'autres choses… |
Ligne 150: | Ligne 237: |
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}}}. |
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 chiffrer des répertoires), donc n'importe 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}}}. |
Ligne 162: | Ligne 249: |
Ligne 164: | Ligne 250: |
Ligne 168: | Ligne 253: |
Ligne 174: | Ligne 258: |
Il faut ajouter les utilisateurs autorisés à monter des volumes ''via'' sshfs au groupe {{{fuse}}}. Pour cela : {{{ | Il faut ajouter les utilisateurs autorisés à monter des volumes ''via'' sshfs au groupe {{{fuse}}}. Pour cela (en root) : {{{ |
Ligne 179: | Ligne 263: |
Ligne 181: | Ligne 264: |
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). |
L'utilisateur côté client n'a juste qu'à taper : {{{ sshfs logindistant@machinedistante:/chemin/cible /point/de/montage/local }}} et entrer un mot de passe si nécessaire. |
Ligne 188: | Ligne 271: |
Par défaut, cela monte le home de l'utilisateur. Pour changer, il suffit de spécifier un autre répertoire après {{{:}}}. | Si on ne précise pas {{{/chemin/cible}}}, cela monte le home de l'utilisateur {{{logindistant}}}. |
Ligne 191: | Ligne 274: |
Lorsque l'on a fini, pour démonter il suffit de tapoter :{{{ fusermount -u pointdemontage |
Lorsque l'on a fini, pour démonter :{{{ fusermount -u /point/de/montage/local |
Ligne 215: | Ligne 298: |
* Par exemple, le système de locks utilisés par [[CransTechnique/ServicesMineurs/CransDarcs|Darcs]] ne fonctionne pas. C'est possible d'utiliser Darcs quand même en mettant la variable d'environnement {{{DARCS_SLOPPY_LOCKS=1}}}. | |
Ligne 216: | Ligne 300: |
* 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 {{{ | * 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 {{{ |
Ligne 225: | Ligne 309: |
* À compléter (je suis sur qu'il y a encore plein d'autres petites astuces pratiques)... | * À compléter (je suis sur qu'il y a encore plein d'autres petites astuces pratiques)… |
Ligne 229: | Ligne 313: |
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 }}} |
Pour se connecter à une machine en ISO 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 }}} = Séquences d'échappement = Le caractère d'échappement par défaut est '~' (on peut le changer avec l'option {{{-e}}} de {{{ssh}}}). Voici les différentes actions possibles (plus de détails dans {{{man ssh}}}, section '''ESCAPE CHARACTERS''') : * ~. : déconnexion de la session * ~^Z (~``+Ctrl+Z) : suspend la connexion ssh * ~# : liste les connexions forwardées * ~& : passe la connexion en background et attends la fermeture des sessions X11 ou des forwards pour finir * ~? : affiche la liste des caractères d'échappement * ~B : envoie un BREAK à l'hôte distant * ~C : ouvre la ligne de commande ssh (utile pour créer des forwards, ..., voir l'option -h pour plus de détails) * ~R : demande le renouvellement de la clé |
Cette page a pour but de rassembler toutes les astuces qui peuvent changer la vie avec SSH.
Sommaire
.ssh
Dans votre home, il y a potentiellement un dossier .ssh. Si il n'y est pas, vous pouvez le créer. Attention il doit avoir les droits rwx------ (700).
$ cd $ mkdir .ssh $ chmod 700 .ssh
On peut placer dans ce dossier tout un tas de choses intéressantes, notamment des clés SSH ou un fichier de configuration, dont vous allez rapidement vous demander comment vous faisiez pour vous en passer avant.
.ssh/config
Ce fichier permet d'appliquer automatiquement des paramètres de configuration quand on ouvre une connexion SSH. En gros, on tape moins de chose pour en faire plus.
Fichier tout fait
Les cranseux mettent à votre disposition un fichier de config déjà tout fait avec plein de trucs dedans, allez voir ici.
Si vous voulez en comprendre le contenu, il est bourré de commentaire, maison va expliquer des bases dans les paragraphes suivant.
Syntaxe
Vous pouvez placer des paramètres de configuration sans indentation, et faire des blocs Host.
Exemple :
HashKnownHosts no Host machin ForwardAgent yes Host bidule HashKnownHosts yes
Alors, pour toute connexion SSH que vous ouvrez, vous aurez le paramètre HashKnownHosts à no, sauf pour bidule, où il sera à yes. Si vous vous connectez à la machine "machin", vous aurez bien HashKnownHosts à no et en plus ForwardAgent à yes.
Alias de machine
Parce que taper ssh zamok, c'est nettement mieux que ssh zamok.crans.org.
Host zamok adherents HostName zamok.crans.org
Alors taper ssh zamok ou ssh adherents reviendra à taper ssh zamok.crans.org.
Vous pouvez mettre autant d'alias que vous voulez sur la ligne Host en les séparant par des espaces.
Spécifier un login
Par défaut, si vous ne précisez rien, SSH utilise votre login actuel, mais comme vous ne vous appelez pas forcément pareil sur toutes vos machines, il faut pouvoir spécifier un login. Vous pouvez utiliser ssh login@machine ou ssh machin -l login, mais le mieux, c'est encore de le mettre une fois pour toutes dans le .ssh/config et de ne plus avoir besoin de le préciser à chaque fois.
Host zamok HostName zamok.crans.org User monlogin
Bien entendu, si vous spécifiez quelque chose en commandline (avec @ ou -l), c'est prioritaire.
Sécification de clé SSH
Par défaut, SSH regarde les clés dans /home/username/.ssh/ et les essaye toutes. Mais vous n'avez le droit qu'à un nombre d'essais limité, donc si vous avez beaucoup de clés, ça peut poser problème. Et puis vous avez le droit de ranger vos clés à un endroit bizarre que SSH n'aura pas forcément l'idée de tester.
Host zamok HostName zamok.crans.org User monlogin IdentityFile /path/vers/cle/privee/id_rsa
Connexions enchaînées
Si vous avez un agent SSH qui retient vos clés, sachez que, par défaut, ça ne marche que depuis votre machine vers une autre. Je développe : si vous faites ssh zamok depuis votre machine, votre agent est sur votre machine et permet donc l'accès à votre clé et vous pouvez entrer sur zamok. Si vous faites ssh tahines depuis votre machine, pareil. Mais si vous faites ssh zamok, puis une fois sur zamok, ssh tahines, cette fois-ci, on va vous demander un mot de passe. C'est parce que zamok ne sait pas que vous avez votre agent chez vous et n'a aucun moyen de le joindre.
Vous pouvez explicitement demander à votre agent de "venir avec vous" sur zamok :
Host zamok HostName zamok.crans.org User monlogin ForwardAgent yes
Alors, quand vous arriver sur zamok, vous allez automatiquement ouvrir une socket (stockée dans le /tmp de zamok) vers votre agent SSH sur votre machine. Ainsi, quand vous ferez ensuite "ssh tahines", SSH pourra utiliser cette socket pour comuniquer avec votre agent chez vous, et vous aller rentrer sur tahines sans fournir de mot de passe.
Donc il faut bien retenir que l'agent reste toujours sur votre machine, le ForwardAgent permet la création de socket pour remonter vos connexions. (Par exemple, si vous avez correctement spécifié le paramètre de conf aussi pour tahines, en arrivant dessus, vous ouvrirez une socket pour comuniquer avec celle de zamok, elle-même toujours en relation avec votre agent chez vous, et ainsi de suite…).
Attention : cette socket est protégées en lecture/écriture pour que seul vous y ayez accès. Cependant, root n'est pas limité par ce genre de restriction, donc, toute personne root sur la machine où vous forwardez votre agent peut accéder à cette socket. Cela lui donne la possibilité de se loguer en votre nom sur toute machine où vous avez placé un clé publique dont la clé privée est déverrouillée dans la mémoire de votre agent. Détail intéressant : il ne peut faire ça que tant que vous ne fermez pas votre connexion à votre agent. En effet, cette socket ne lui donne pas accès directement à votre clé, mais lui permet de demander à votre agent de résoudre un challenge SSH (en pratique, la clé privée ne quitte jamais la mémoire de votre machine, c'est la machine sur laquelle vous voulez vous connecter qui chiffre un truc avec votre clé publique, vous l'envoie, et si vous arrivez à le déchiffrer (et c'est ce que fait l'agent), c'est que vous possédez bien la clé privée, donc vous pouvez entrer).
Proxy
Il arrive qu'une machine ne soit pas accessible directement, pour des raisons de firewalling ou de VLANs, par exemple.
Dans ce cas, il faut passer par une autre machine pour accéder à votre cible, mais plutôt que d'établir manuellement cette connexion à la première puis d'aller sur la deuxième, autant le faire automatiquement :
Host tselin HostName tselin.clietu.ens-cachan.fr User loginENS ProxyCommand ssh loginENS@tahines.ens-cachan.fr -W %h:%p
Ainsi, lorsque vous chercherez à accéder à tselin, SSH passera automatiquement par tahines.
Connexions master
Le principe des connexion master est d'ouvrir une connexion une seule fois vers un serveur, et toutes les connexions suivantes que vous ouvrirez vers le même hôte passeront par la même connexion TCP.
Cela permet d'ouvrir plus rapidement les connexion suivantes, et de ne pas emplafonner des limites telles que le nombre de connexions SSH par minute que vous avez le droit d'établir à travers un firewall comme celui de komaz.
Host zamok Hostname zamok.crans.org ControlMaster auto ControlPath ~/.ssh/master-%r-%h:%p
ControlPath est l'endroit où sera stockée la socket dans votre arborescence de fichiers. %r sera remplacé par le login distant, %h par le nom de l'hôte distant et %p par le port de connexion. Cela permet que les sockets soient stockées dans des noms distincts, sinon ça risque de créer des problèmes.
Blocs sioux
Serveur du crans
Il y a moyen de définir un seul bloc de config pour se connecter sur tous les serveurs du crans.
Host *,c proxycommand nc -q 30 $(echo %h | sed -r 's/..$//').crans.org %p username loginCrans
Avec ça vous pouvez faire ssh zamok,c ssh rouge,c ou encore ssh vo,c.
Tunnel en passant par un serveur truc
En imaginant que vous faisiez régulièrement des connexions en passant par l'hote truc vers des cibles variés
Host *,t proxycommand ssh truc nc -q 30 $(echo %h | sed -r 's/..$//') %p
En hop, pour se conecter à une cible nommée cible en passant par truc, quelque soit la cible, il suffit de faire ssh cible,t
Tunnel généraux
Dans le cas où vous faisez des tunnels en passant par divers serveurs, une version plus détaillée
Host *,T proxycommand ssh $(echo %h | cut -d , -f 2) nc -q 30 $(echo %h | cut -d , -f 1) %p
Ainsi pour se connecter sur une cible nommée cible en passant par un relai nommé relai, il suffit de faire ssh cible,relai,T
Contourner les ports bloqués
Parfois, vous êtes dans un environnement réseau que vous ne contrôlez pas, et qui est méchant avec vous (stage, labo, résidence étudiante pas couverte par le Cr@ns, box bizarre…). Il arrive donc que les ports que vous aimeriez contactés vous soient interdits. Par exemple, si votre "Internet" décide que vous n'avez pas le droit de parler à un port 22, vous ne pouvez pas contacter des serveurs en SSH a priori.
Là où on commence à voir une solution, c'est qu'en général, les ports 80 et 443 ne sont pas bloqués (parce que, quand même, on vous laisse faire du HTTP(S) pour aller sur facebook). Donc vous avez le droit de parler au monde sur le port 443. Seulement voilà, en général sur ce port, il n'y a pas un serveur SSH mais un serveur web, justement.
Mais la bonne nouvelle, c'est que les cranseux y ont pensé ! On peut donc contacter ssh2.crans.org sur le port 443 et tomber sur un serveur SSH. (En fait, quand vous contactez le port 443 de l'IP 138.231.136.2 (ssh2.crans.org), il est redirigé vers le port 22 de 138.231.136.1 (zamok.crans.org).)
Tous les adhérents disposant d'un compte Cr@ns peuvent utiliser ce service.
Via proxy HTTP
Astuce précédemment nommée SSH à travers un proxy, mais je dois avouer que je comprends pas trop ce dont il est question… -- Wiki20-100 2014-07-24 17:08:37
Dans certains cas, les serveurs proxy autorisent le transfert des connexions vers le port 22. Mais, dans la plupart des cas, les serveurs 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
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 monlogin
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 connexion 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. Ça 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 fuse (système de fichier en userspace pour Linux, la même chose que ce qui est utilisé par encfs pour chiffrer des répertoires), donc n'importe 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.
|
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 (en root) :
adduser utilisateur fuse
Usage
Montage
L'utilisateur côté client n'a juste qu'à taper :
sshfs logindistant@machinedistante:/chemin/cible /point/de/montage/local
et entrer un mot de passe si nécessaire.
Si le nom d'utilisateur distant est différent, alors on remplacera machinedistante par utilisateur@machinedistante.
Si on ne précise pas /chemin/cible, cela monte le home de l'utilisateur logindistant.
Démontage
Lorsque l'on a fini, pour démonter :
fusermount -u /point/de/montage/local
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).
Par exemple, le système de locks utilisés par Darcs ne fonctionne pas. C'est possible d'utiliser Darcs quand même en mettant la variable d'environnement DARCS_SLOPPY_LOCKS=1.
- 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 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
Séquences d'échappement
Le caractère d'échappement par défaut est '~' (on peut le changer avec l'option -e de ssh).
Voici les différentes actions possibles (plus de détails dans man ssh, section ESCAPE CHARACTERS) :
- ~. : déconnexion de la session
~^Z (~+Ctrl+Z) : suspend la connexion ssh
- ~# : liste les connexions forwardées
~& : passe la connexion en background et attends la fermeture des sessions X11 ou des forwards pour finir
- ~? : affiche la liste des caractères d'échappement
- ~B : envoie un BREAK à l'hôte distant
- ~C : ouvre la ligne de commande ssh (utile pour créer des forwards, ..., voir l'option -h pour plus de détails)
- ~R : demande le renouvellement de la clé