Différences

Ci-dessous, les différences entre deux révisions de la page.

--- linux:ssh_en_profondeur [2009/04/27 12:08]
jce
+++ linux:ssh_en_profondeur [2021/04/11 13:50] (Version actuelle)
@@ Ligne 7: / Ligne 7: @@
 **Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
-**Résumé** : apt-get install sshfs &amp;&amp; sshfs user@machine:/rep /mnt
+**Résumé** : apt-get install sshfs && sshfs user@machine:/rep /mnt
 ==== Sshfs ou comment vous faciliter la vie. ====
@@ Ligne 19: / Ligne 19: @@
 Il existe "Ô miracle" un outil fait pour vous, taillé à votre image : sshfs. Grâce à lui vous pourrez enfin vous sentir chez vous tout en manipulant des fichiers distants. Mais laissons parler la ligne de commande :
-<code>
+<code bash>
  $ ssh loin.tresloin.com "ls -a ~/devel/"
  > . .. README projetv1 projetv2
@@ Ligne 46: / Ligne 46: @@
    apt-get install
-   tar xvfz &amp;&amp; ./configure &amp;&amp; make &amp;&amp; sudo make install
+   tar xvfz && ./configure && make && sudo make install
 L'information se trouve ici : http://fuse.sourceforge.net/sshfs.html
@@ Ligne 54: / Ligne 54: @@
 Sur le même principe, il existe de nombreux fs dont ftpfs, bien pratique pour le développement de sites web sur un hébergement mutualisé.
-----
 ===== Connexion sans mot de passe =====
@@ Ligne 91: / Ligne 90: @@
 <code>
  $ # à mettre dans un script et a lancer à la main après chaque reboot
- $ ssh-agent | head -n 2 &gt; ~/ssh-info
+ $ ssh-agent | head -n 2 > ~/ssh-info
  $ source ~/ssh-info
  $ ssh-add
@@ Ligne 104: / Ligne 103: @@
 aura accès à la clé ssh stockée dans l'agent. Bien sur cela ne marche que pour un script lancé avec le même utilisateur que l'agent ssh !
-----
 ===== Distribution de commandes =====
@@ Ligne 147: / Ligne 145: @@
 [[http://linux-attitude.fr/post/Distribution-de-commandes#comments | Une réaction, répondez-y]]
-----
 ===== Login par clé ssh =====
@@ Ligne 189: / Ligne 186: @@
 Pam étant une bibliothèque, il n'y a rien a relancer.
-----
 ===== S'échapper devant un problème =====
@@ Ligne 210: / Ligne 206: @@
 <code>
  $ telnet localhost imap
- &gt; Trying 127.0.0.1...
+ > Trying 127.0.0.1...
- &gt; Connected to localhost.
+ > Connected to localhost.
- &gt; Escape character is '^]'.
+ > Escape character is '^]'.
 </code>
 Si on ne connaît pas le protocole, on ne peut plus sortir de telnet car l'imap demande une séquence bien particulière pour vous déconnecter. De plus une fois connecté le ctrl-c ne fonctionne plus car il est envoyé comme tout autre caractère. Il vous faut donc donc taper "^]quit<return>" pour forcer la déconnexion.
@@ Ligne 226: / Ligne 222: @@
 Une autre commande particulièrement utile de ssh est ~C elle permet de rentrer dans un mode commande de ssh. Help vous donnera plus d'infos, mais cette commande permet surtout d'ajouter ou de supprimer des tunnels directement comme vous l'auriez fait avec les options -L et -R, mais cette fois sans relancer ssh.
-----
-===== [[http://linux-attitude.fr/post/SXP | SXP]] =====
+===== SXP =====
+[[http://linux-attitude.fr/post/SXP | SXP]]
 Par Peck le 4 juin 2007, 20:00 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
@@ Ligne 245: / Ligne 241: @@
 Maintenant supposons que vous n'ayez que ssh à disposition. Hé bien il est possible de faire le même genre de chose :
- $ scp user1@machine1:/my/file/1 user2@machine2:/your/path
+  $ scp user1@machine1:/my/file/1 user2@machine2:/your/path
 Le processus est alors le suivant :
-* scp vous connecte sur machine 1 (avec mot de passe si besoin)
+  * scp vous connecte sur machine 1 (avec mot de passe si besoin)
-* puis depuis machine1, il tente de se connecter à user2@machine2 pour faire la copie (sans interaction cette fois).
+  * puis depuis machine1, il tente de se connecter à user2@machine2 pour faire la copie (sans interaction cette fois).
 Ceci a 2 inconvénients :
-* si le flux ssh n'est pas ouvert de machine1 vers machine2 vous êtes coincés
+  * si le flux ssh n'est pas ouvert de machine1 vers machine2 vous êtes coincés
-* il faut que vous puissiez vous connecter de machine1 à machine2 sans mot de passe (avec une clé et un [[http://linux-attitude.fr/post/Connexion-sans-mot-de-passe | forward d'agent]])
+  * il faut que vous puissiez vous connecter de machine1 à machine2 sans mot de passe (avec une clé et un [[#Connexion_sans_mot_de_passe | forward d'agent]])
 Si le flux est ouvert de machine2 vers machine1 (dans l'autre sens) ou si vous n'avez pas de clé ssh, vous pouvez aussi utiliser la commande suivante :
- $ ssh user2@machine2 "scp user1@machine1:/my/file/1 /your/path"
+  $ ssh user2@machine2 "scp user1@machine1:/my/file/1 /your/path"
 Et si aucun flux n'est ouvert entre machine1 et machine2 il vous reste une dernière solution : passer par votre machine de commande. Pour ne pas avoir à stocker le fichier sur votre machine (transit uniquement) utilisez la commande suivante :
- $ ssh user1@machine1 "cat /my/file/1" | ssh machine2 "cat &gt; /your/path/1"
+  $ ssh user1@machine1 "cat /my/file/1" | ssh machine2 "cat > /your/path/1"
 **PS** : Dans vos commandes scp, il est possible d'écrire "machine:" comme équivalent de "machine:~/"
@@ Ligne 269: / Ligne 265: @@
 **PS2** : Dans vos commandes, si le nom d'un fichier local contient un ":", il vous faut donner un chemin contenant un / pour ne pas confondre avec un nom de machine. Ex:
- $ scp machine:~/toto ./mon:repertoire/
+  $ scp machine:~/toto ./mon:repertoire/
-----
-===== [[http://linux-attitude.fr/post/La-dure-loi-du-ssh | La dure loi du ssh]] =====
+===== La dure loi du ssh =====
+[[http://linux-attitude.fr/post/La-dure-loi-du-ssh | La dure loi du ssh]]
 Par Peck le 19 septembre 2007, 21:45 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
@@ Ligne 283: / Ligne 279: @@
 Exemple pour interdire l'utilisation de mots de passe à un groupe d'utilisateurs (à mettre dans /etc/ssh/sshd_config) :
+<code>
  Match Group glandus
  PasswordAuthentication no
+</code>
 Attention, toutes les lignes qui suivent un match sont liées à ce match juqu'au prochain match ou à la fin du fichier de configuration. Placez donc vos directives match à la fin du fichier.
 Pour forcer l'utilisation d'une commande à un utilisateur donné :
+<code>
  Match User toto
  ForceCommand /bin/cat /etc/php5/apache2/php.ini
+</code>
 Pour forcer l'affichage d'un texte d'avertissement avant la connexion pour les machines venant d'un certain réseau :
+<code>
  Match Host *.linux.fr
  Banner /etc/ssh_warn
+</code>
 Pour interdire le forwarding de port à une machine (un utilisateur un peu doué saura contourner ça) :
+<code>
  Match Address 192.168.1.1
  AllowTcpForwarding no
+</code>
 [[http://linux-attitude.fr/post/La-dure-loi-du-ssh#comments | 2 réactions, répondez-y]]
-----
-===== [[http://linux-attitude.fr/post/Aie-confiance-crois-en-moi | Aie confiance ... crois en moi ...]] =====
+===== Aie confiance ... crois en moi... =====
+[[http://linux-attitude.fr/post/Aie-confiance-crois-en-moi | Aie confiance ... crois en moi ...]]
 Par Peck le 26 septembre 2007, 22:03 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
@@ Ligne 318: / Ligne 320: @@
 Vous avez tous déjà touché à un ssh. Rappelez-vous votre première connexion :
+<code>
  $ ssh 127.0.0.1
  The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
  RSA key fingerprint is d9:16:53:ef:84:cf:1a:ce:42:03:55:09:86:5c:0e:50.
  Are you sure you want to continue connecting (yes/no)?
+</code>
 Mais qu'est-ce que c'est que ce bin's ? Bon aujourd'hui vous êtes grands, vous le savez, il s'agit de vérifier que la machine à laquelle on parle est bien celle à laquelle on voulait parler. Pour faire cette vérification, il faut aller demander à une personne de confiance qui administre ou qui s'est déjà connectée à la machine, si l'empreinte que vous avez sous les yeux est la bonne.
@@ Ligne 334: / Ligne 337: @@
 Que faire pour éviter le désagrément de cette première connexion ? Tout dépend de votre confiance. Vous pouvez avoir une confiance absolue en votre réseau de machines :
- $ ssh -o StrictHostKeyChecking=no mamachine.toto.net
+  $ ssh -o StrictHostKeyChecking=no mamachine.toto.net
 Ou alors vous pouvez avoir une confiance nulle et considérer toute connexion dont la clé n'a pas été ajoutée à la main comme une première connexion :
- $ ssh -o StrictHostKeyChecking=yes mamachine.toto.net
+  $ ssh -o StrictHostKeyChecking=yes mamachine.toto.net
 La valeur par défaut est ask et est écrite dans /ect/ssh/ssh_config (ou ~/.ssh/config si vous en avez un).
@@ Ligne 348: / Ligne 351: @@
 Hé bien cette chose existe ... presque. Vous pouvez mettre cette information dans votre serveur DNS sous la forme d'un champ SSHFP.
- mamachine    IN    SSHFP   1   1   1d7b808b64aa57c2451d3635dc4dbb6931c8c715
+  mamachine    IN    SSHFP   1   1   1d7b808b64aa57c2451d3635dc4dbb6931c8c715
 et 1 indiquent les type de clé et sont suivis par la clé elle-même.
@@ Ligne 354: / Ligne 357: @@
 Ensuite vous vous connectez à votre machine pour la première fois
+<code>
  $ ssh -o VerifyHostKeyDNS=yes mamachine.toto.net
  The authenticity of host 'toto.localhost (127.0.0.2)' can't be established.
@@ Ligne 359: / Ligne 363: @@
  Matching host key fingerprint found in DNS.
  Are you sure you want to continue connecting (yes/no)?
+</code>
 Presque, mais ssh ne fait pas confiance à votre serveur DNS et il vous pose donc quand même la question.
@@ Ligne 366: / Ligne 371: @@
 Pour que ssh fasse confiance à votre serveur DNS, il faut que ce soit un resolver DNSSEC. C'est à dire dns sécurisé. Donc à toute allure vous installez un resolver sécurisé, une zone DNSSEC, et tadaaam :
+<code>
  $ ssh -o VerifyHostKeyDNS=yes mamachine.toto.net
  $ hosname
- &gt; mamachine.toto.net
+ > mamachine.toto.net
+</code>
 Bravo ! vous pouvez maintenant gérer vos machines en toute quiétude. Sans vous préoccuper du fait que vous êtes en train de faire confiance à un resolver DNSSEC. Or pour ceux qui connaissent un peu, dnssec permet de faire confiance aux sources de données (le serveur qui sert la zone), mais n'impose rien dans le protocole entre le client et le resolver dns (seul un bit ad est présent et indique que le résolver a utilisé une procédure sécurisée). Ce qui veut dire que la la partie communication locale avec le dns n'est pas vraiment sécurisée ...
@@ Ligne 376: / Ligne 383: @@
 Vous pouvez quand même mettre en place vos entrées SSHFP, ca sera toujours mieux que rien, vous aurez une vérification disponible. Pour ne pas devoir récupérer à la main vos entrées SSHFP, vous pouvez utiliser ssh-keygen :
+<code>
  $ ssh-keygen -r localhost
 .0.0.1 IN SSHFP 1 1 1d7b808b64aa57c2451d3635dc4dbb6931c8c715
 .0.0.1 IN SSHFP 2 1 ba276a0efde89b9f041b4e42780ee317a48403b9
  # prêt à être inséré dans la zone DNS
+</code>
 D'autre part si vous faites une zone signée dnssec (pour ne plus avoir de confirmation du tout) il faudra que vous ayez un resolver dns séparé de votre serveur de zone (lequel ne mettra pas le bit ad de lui-même). Sinon ssh ignorerait le fait que votre zone est sécurisée. Ceci implique donc une architecture suffisament grande pour séparer les 2 ou le fait que vous ne travaillez que sur des serveur distants (dnsment parlant).
@@ Ligne 385: / Ligne 394: @@
 [[http://linux-attitude.fr/post/Aie-confiance-crois-en-moi#comments | 3 réactions, répondez-y]]
-----
-===== [[http://linux-attitude.fr/post/Nom-dune-machine | Nom d'une machine [=!=]]] =====
+===== Nom d'une machine ! =====
+[[http://linux-attitude.fr/post/Nom-dune-machine | Nom d'une machine !]]
 Par Peck le 28 octobre 2007, 19:59 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
 **Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
-**Résumé** : ssh root@&lt;tab&gt;
+**Résumé** : ssh root@<tab>
 Je suis sûr qu'il vous arrive souvent de taper ssh toto@mamachine.monreseau.net. Tellement souvent que vous avez fini par modifier votre ~/.ssh/config pour y mettre des alias. Pour ceux qui ont oublié comment faire voici la ligne à mettre :
+<code>
  Host machine
  Hostname mamachine.monreseau.net
+</code>
 Au passage vous pouvez ajouter le port et le login par défaut dans cette configuration.
+<code>
  Host machine
  Hostname mamachine.monreseau.net
  Port 1022
  User toto
+</code>
 Bien, maintenant quelque chose de tout aussi sympathique. Il est possible de demander à bash de compléter ces noms de machine, plutôt que de les entrer tout seul comme un grand. En effet, bash dispose de la complétion sur les noms de machine. Le simple fait de préfixer un nom par @ permet à ssh de supposer que c'est un nom de machine. Mais alors comment fait-il pour les connaître tous ? Il lit la variable $HOSTFILE qui doit contenir le nom d'un fichier au format /etc/hosts. Si elle est vide il lit le fichier /etc/hosts.
-Donc : ssh root@l&lt;tab&gt; complète toujours au moins par localhost (ou presque).
+Donc : ssh root@l<tab> complète toujours au moins par localhost (ou presque).
 Bien, mais nous n'allons pas remplir le fichier /etc/hosts à la main tout de même !
@@ Ligne 414: / Ligne 427: @@
 Non, nous allons faire mieux. Hop un script shell :
+<code bash>
  #!/bin/sh
@@ Ligne 423: / Ligne 437: @@
  # machines à ajouter à la main (l'IP b'est pas vraiment obligatoire)
- cat &gt; $FILE &lt;&lt; EOF
+ cat > $FILE << EOF
 mamachine.youpi.fr
 tamachine.youpi.fr
@@ Ligne 430: / Ligne 444: @@
  for domaine in $DOMAINS
  do
-   dig $domaine axfr | egrep "IN[=[[:space:]]=]+A" | awk '{print  $5,$1}' &gt;&gt; $FILE
+   dig $domaine axfr | egrep "IN[=[[:space:]]=]+A" | awk '{print  $5,$1}' >> $FILE
  done
+</code>
 Bien sûr on pourrait le faire en perl, d'ailleurs, ne vous gênez pas. On pourrait aussi séparer la configuration dans un autre fichier. En attendant c'est simple et ça tient dans un fichier. Ce script scanne des domaines en leur envoyant la commande axfr et y ajoute une liste personnelle de machines. Attention, rares sont les domaines qui acceptent la commande axfr de l'extérieur, ce qui veut dire que (logique) elle doit s'appliquer à des serveurs que vous gérez, ou tout au moins pour lesquels vous avez un accès privilégié (interne).
@@ Ligne 437: / Ligne 452: @@
 Maintenant il vous reste à le lancer (au moins une fois), à ajouter une ligne dans votre .bashrc :
+<code bash>
  export HOSTFILE=~/.hosts
  /
+</code>
 Et à ajouter ce script dans une crontab pour être toujours à jour de la liste de vos machines.
@@ Ligne 444: / Ligne 461: @@
 Attention, si vous avez un bash récent avec une distrib sympa, la complétion par HOSTFILE est désactivée et est remplacée par une complétion par known_hosts. Si vous voulez la réactiver, il faut taper la commande suivante (ou ne pas inclure le /etc/bash_completion) :
- $ shopt -s hostcomplete
+<code bash>
+  $ shopt -s hostcomplete
+</code>
-Si vous préférez la complétion telle que définie dans le bash_completion, il vous faudra avoir toutes vos machines dans votre fichier ~/.ssh/known_host. Et pour cela attendez l'[[http://linux-attitude.fr/index.php?post/article-suivant | article suivant ...]]
+Si vous préférez la complétion telle que définie dans le bash_completion, il vous faudra avoir toutes vos machines dans votre fichier ~/.ssh/known_host. Et pour cela attendez l'[[#article_suivant | article suivant ...]]
-----
-===== [[http://linux-attitude.fr/post/article-suivant | ... article suivant]] =====
+===== article suivant =====
+[[http://linux-attitude.fr/post/article-suivant | ... article suivant]]
 Par Peck le 29 octobre 2007, 19:41 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
 **Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
-**Résumé** : ssh root@&lt;tab&gt;
+**Résumé** : ssh root@<tab>
-Rappelons le [[http://linux-attitude.fr/post/Nom-dune-machine | contexte]], on veut pouvoir faire de la complétion automatique sur les noms de machine. La plupart des distributions ont déjà défini un fichier /etc/bash_completion qui fait ceci. Pour le faire, il lit le fichier ~/.ssh/known_hosts. On veut donc récupérer un fichier known_hosts complet pour permettre la complétion automatique. Et ô magie, il existe un outil presque tout fait pour faire ca : ssh-keyscan. C'est un outil qui va récupérer pour vous toutes les clés publiques des serveurs ssh que vous lui demandez. Mieux, il les met au format known_hosts, mieux il sait le faire en parallèle. Donc reprenons notre script d'hier et adaptons :
+Rappelons le [[#Nom_dune_machine | contexte]], on veut pouvoir faire de la complétion automatique sur les noms de machine. La plupart des distributions ont déjà défini un fichier /etc/bash_completion qui fait ceci. Pour le faire, il lit le fichier ~/.ssh/known_hosts. On veut donc récupérer un fichier known_hosts complet pour permettre la complétion automatique. Et ô magie, il existe un outil presque tout fait pour faire ca : ssh-keyscan. C'est un outil qui va récupérer pour vous toutes les clés publiques des serveurs ssh que vous lui demandez. Mieux, il les met au format known_hosts, mieux il sait le faire en parallèle. Donc reprenons notre script d'hier et adaptons :
+<code bash>
  #!/bin/sh
@@ Ligne 468: / Ligne 488: @@
  # machines à ajouter à la main (plus d'ip du tout)
- cat &gt; $FILE &lt;&lt; EOF
+ cat > $FILE << EOF
  mamachine.youpi.fr
  tamachine.youpi.fr
@@ Ligne 475: / Ligne 495: @@
  for domaine in $DOMAINS
  do
-   dig $domaine axfr | egrep "IN[=[[:space:]]=]+A" | awk '{print  $1}' &gt;&gt; $FILE
+   dig $domaine axfr | egrep "IN[=[[:space:]]=]+A" | awk '{print  $1}' >> $FILE
  done
  # grep pour quelques petits bugs
- grep -v "[#_*]" $FILE | ssh-keyscan -t rsa,dsa -f - &gt; ~/.ssh/known_hosts
+ grep -v "[#_*]" $FILE | ssh-keyscan -t rsa,dsa -f - > ~/.ssh/known_hosts
+</code>
 Petit inconvénient, ssh-keyscan s'arrête dès qu'il y a une erreur de résolution de nom. Pas cool, vous devez le relancer en filtrant mieux lorsque vous tombez sur une erreur.
@@ Ligne 491: / Ligne 512: @@
 Vous abandonnerez donc une protection (somme toute légère), et en contrepartie vous avez une complétion avancée sous bash. Mieux, si votre agent tourne et que vous avez poussé vos clés sur les machines en question, la complétion fonctionnera aussi sur les noms de fichiers distants, exemple :
- $ scp toto@machine:/&lt;tab&gt;&lt;tab&gt; # root c'est mâaal !
+  $ scp toto@machine:/<tab><tab> # root c'est mâaal !
 Victoire !
@@ Ligne 497: / Ligne 518: @@
 [[http://linux-attitude.fr/post/article-suivant#comments | Une réaction, répondez-y]]
-----
-===== [[http://linux-attitude.fr/post/Discussion-assistee-par-ordinateur | Discussion assistée par ordinateur]] =====
+===== Discussion assistée par ordinateur =====
+[[http://linux-attitude.fr/post/Discussion-assistee-par-ordinateur | Discussion assistée par ordinateur]]
 Par Peck le 18 novembre 2007, 22:25 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
@@ Ligne 530: / Ligne 551: @@
 Pour le lancer :
- $ screen -S irc
+  $ screen -S irc
- $ irssi
+  $ irssi
 Puis pour vous y reconnecter :
- $ screen -d -r irc
+  $ screen -d -r irc
 Sachant que votre machine irssi sera distante de temps en temps, créez vous un alias pour vous connecter à irc :
- alias irc="ssh serveur.reseau.net 'screen -d -r irc'"
+  alias irc="ssh serveur.reseau.net 'screen -d -r irc'"
 Irssi dispose de [[http://irssi.org/themes | thèmes]] permettant de changer l'apparence des clients. Personnellement je préfère les thèmes alignés comme [[http://irssi.org/themefiles/dot.png | dot]]. Irssi dispose aussi de nombreux [[http://irssi.org/scripts/ | plugins]] permettant d'étendre celui-ci directement en perl. J'utilise par exemple hilightwin.pl qui permet d'avoir une fenêtre supplémentaire pour tous les messages qui vous concernent sur les canaux auxquels vous êtes connectés.
-----
-===== [[http://linux-attitude.fr/post/Agent-007-espion-infiltre | Agent 007, espion infiltré]] =====
+===== Agent 007, espion infiltré =====
+[[http://linux-attitude.fr/post/Agent-007-espion-infiltre | Agent 007, espion infiltré]]
 Par Peck le 17 décembre 2007, 23:29 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
@@ Ligne 552: / Ligne 573: @@
 **Résumé** : ssh-agent ; ssh-add
-Comme je l'ai déjà [[http://linux-attitude.fr/post/Connexion-sans-mot-de-passe | expliqué]] il y a quelque temps, il est possible grâce à ssh-agent de réutiliser sa clé ssh. C'est bien, mais en pratique, comment fonctionne cet agent ?
+Comme je l'ai déjà [[#Connexion_sans_mot_de_passe | expliqué]] il y a quelque temps, il est possible grâce à ssh-agent de réutiliser sa clé ssh. C'est bien, mais en pratique, comment fonctionne cet agent ?
 L'agent est un processus qui gère vos clés. Il communique à travers une socket. Ssh-add lit une clé sur votre compte utilisateur et demande de l'ajouter à travers la socket. Le client ssh lui va demander les clés disponibles à la socket pour se connecter quelque part.
@@ Ligne 562: / Ligne 583: @@
 Pour avoir la liste des agents disponibles :
- $ ls -ld /tmp/ssh-* | grep `whoami`
+<code bash>
+  $ ls -ld /tmp/ssh-* | grep `whoami`
+</code>
 Mais attention, cela contient aussi les socket ouvertes pas les ssh qui se sont connectés avec le forwarding d'agent. Pour les différencier, vous devrez utiliser la date. Vous pouvez aussi avoir quelques info supplémentaire avec netstat :
- $  netstat -lnp --unix | grep ssh-
+<code bash>
+  $  netstat -lnp --unix | grep ssh-
+</code>
 Maintenant, pour la réutiliser, il suffit simplement d'affecter la variable adaptée :
- $ export SSH_AUTH_SOCK=/tmp/ssh-lwksuR6740/agent.6740
+<code bash>
- $ ssh nouvelle.machine
+  $ export SSH_AUTH_SOCK=/tmp/ssh-lwksuR6740/agent.6740
- # et voila !
+  $ ssh nouvelle.machine
+  # et voila !
+</code>
 C'est bien pratique, mais n'oubliez pas une chose, cela signifie que root a accès à vos clés sans passphrase. Cela signifie aussi que vous ne devez jamais forwarder votre agent lorsque que vous vous connectez sur une machine avec un compte partagé. Cela signifierait que vos associés auraient accès à toute les clés dont vous disposez sur votre machine de départ. Si vous ne pouvez pas vous en passer, essayez au moins d'utiliser l'option -t de ssh-add qui limite en temps la validité de la clé.
- $ ssh-add -t 600
+<code bash>
+  $ ssh-add -t 600
+</code>
-----
+===== Un tien vaut mieux que deux connexions =====
-===== [[http://linux-attitude.fr/post/Un-tien-vaut-mieux-que-deux-connexions | Un tien vaut mieux que deux connexions]] =====
+[[http://linux-attitude.fr/post/Un-tien-vaut-mieux-que-deux-connexions | Un tien vaut mieux que deux connexions]]
 Par Peck le 15 février 2008, 23:47 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
@@ Ligne 591: / Ligne 619: @@
 Il est plus judicieux de ne faire qu'une seule connexion ssh et de multiplexer toutes vos commandes par dessus (soit à cause de la faiblesse de la machine, soit parce que vous faites un grand nombre de connexions). Heureusement, ssh a tout prévu :
+<code BASH>
  # première connexion
  $ ssh -M -S /tmp/master mamachine.net
@@ Ligne 596: / Ligne 625: @@
  # deuxième connexion
  $ ssh -S /tmp/master mamachine.net
+</code>
 La deuxième connexion est infiniment plus rapide (ajoutez l'option -v pour en être convaincu). De plus notez que même si vous terminez la commande (ou le shell) de la première connexion, celle-ci ne sera vraiment terminée que lorsque la deuxième commande le sera aussi. Vous pouvez ainsi multiplexer autant de connexions que vous voulez, l'option -M ne sert qu'une fois pour la création du master de connexion.
@@ Ligne 601: / Ligne 631: @@
 Remarquez que vous pouvez utiliser n'importe quel nom de machine pour les connexions slave, c'est la syntaxe ssh qui vous force à en utiliser un, mais il n'est pas réellement utilisé, exemple :
- $ ssh -M -S /tmp/master mamachine.net
+<code bash>
- # mamachine.net ou azerty c'est pareil
+  $ ssh -M -S /tmp/master mamachine.net
- $ ssh -S /tmp/master azerty
+  # mamachine.net ou azerty c'est pareil
+  $ ssh -S /tmp/master azerty
+</code>
 [[http://linux-attitude.fr/post/Un-tien-vaut-mieux-que-deux-connexions#comments | Une réaction, répondez-y]]
-%block bgcolor=#dfd border='1px dotted green' define=snoopy%
-%snoopy%1. Le 18 février 2008, 11:25 par Simon\\
-\\
-Et pour automatiser l'usage de cette option :\\
+>Le 18 février 2008, 11:25 par Simon
+>Et pour automatiser l'usage de cette option :
+<code bash>
  cat >> ~/.ssh/config << EOF
  Host *
@@ Ligne 617: / Ligne 646: @@
  ControlMaster auto
  EOF
-%snoopy%(outrageusement copié depuis http://nion.modprobe.de/blog/archives/502-Speeding-up-SSH-ControlMaster.html)\\
+</code>
+>(outrageusement copié depuis http://nion.modprobe.de/blog/archives/502-Speeding-up-SSH-ControlMaster.html)
-----
-===== [[http://linux-attitude.fr/post/Donner-sa-la-langue-au-sshat | Donner sa la langue au sshat]] =====
+===== Donner sa la langue au sshat =====
+[[http://linux-attitude.fr/post/Donner-sa-la-langue-au-sshat | Donner sa la langue au sshat]]
 Par Peck le 19 mars 2008, 22:54 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
@@ Ligne 637: / Ligne 666: @@
 Étant des variables d'environnement, ces infos sont transmises de processus en processus. Donc de shell en commande. Pour connaître la locale en cours, c'est simple :
- $ locale
+  $ locale
 Pour la changer :
+<code>
  # on liste les locales disponibles
  $ locale -a
  # on en choisit une
  $ export LANG=fr_FR
+</code>
 À ajouter dans votre .bashrc pour conserver la chose un peu plus longtemps (attention, gnome et kde ''et caetera'' sont à configurer séparément).
@@ Ligne 652: / Ligne 683: @@
 Pour les systèmes utilisant pam (su, login, kdm, gdm, ...) vous pouvez aller lire les /etc/pam.d/XXX qui peuvent contenir une ligne du type :s
- auth    required        pam_env.so readenv=1 envfile=/etc/default/locale
+  auth    required        pam_env.so readenv=1 envfile=/etc/default/locale
 indiquant où chercher vos variables.
@@ Ligne 660: / Ligne 691: @@
 Sur le serveur, dans /etc/ssh/sshd_config :
- # on autorise le client a jouer avec les locales à la connexion
+  # on autorise le client a jouer avec les locales à la connexion
- AcceptEnv LANG LC_*
+  AcceptEnv LANG LC_*
 Sur le client, de préférence dans /etc/ssh/ssh_config :
- Host *
+  Host *
- # on envoit nos locales au serveur
+  # on envoit nos locales au serveur
- SendEnv LANG LC_*
+  SendEnv LANG LC_*
 Et voilà, pour peu que votre /etc/pam.d/ssh ne contienne pas de référence à un fichier qui forcerait les locales, vous êtes chez vous.
@@ Ligne 673: / Ligne 704: @@
 [[http://linux-attitude.fr/post/Donner-sa-la-langue-au-sshat#comments | 3 réactions, répondez-y]]
-----
-===== [[http://linux-attitude.fr/post/Le-travail-a-la-chaine-cest-has-been | Le travail à la chaîne, c'est has been.]] =====
+===== Le travail à la chaîne, c'est has been. =====
+[[http://linux-attitude.fr/post/Le-travail-a-la-chaine-cest-has-been | Le travail à la chaîne, c'est has been.]]
 Par ebzao le 21 mars 2008, 23:44 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
@@ Ligne 684: / Ligne 715: @@
 Bonjour à tous, très honoré d'être à la tribune de ce blog, mais [[http://linux-attitude.fr/post/A-vous-les-studios | on m'a forcé la main]] !
-Pour rebondir sur un [[http://linux-attitude.fr/post/Distribution-de-commandes | post récent]] (tout juste un an !), voici quelques outils pour travailler efficacement sur un groupe de machines.
+Pour rebondir sur un [[#Distribution_de_commandes | post récent]] (tout juste un an !), voici quelques outils pour travailler efficacement sur un groupe de machines.
 ==== Konsole et dsh, les ancêtres ====
-Comme Peck [[http://linux-attitude.fr/post/Distribution-de-commandes | l'avait présenté]], pour envoyer une même suite de commandes sur un groupe de machines, on peut soit le faire à l'aveugle avec Konsole (si on supporte KDE), soit lancer ses commandes coûte que coûte avec dsh, mais sans contrôle encore une fois sur le déroulement.
+Comme Peck [[#Distribution_de_commandes | l'avait présenté]], pour envoyer une même suite de commandes sur un groupe de machines, on peut soit le faire à l'aveugle avec Konsole (si on supporte KDE), soit lancer ses commandes coûte que coûte avec dsh, mais sans contrôle encore une fois sur le déroulement.
-Avec Konsole : préparez dans une même fenêtre une machine à contrôler par onglet, puis dans les menus : ''View &gt; Send Input to All Sessions''. Désormais, tout ce que vous tapez est répété dans toutes les fenêtres.
+Avec Konsole : préparez dans une même fenêtre une machine à contrôler par onglet, puis dans les menus : ''View > Send Input to All Sessions''. Désormais, tout ce que vous tapez est répété dans toutes les fenêtres.
 Avec dsh :
@@ Ligne 699: / Ligne 730: @@
   dsh -m machine1 -m machine2 -m ... "echo $HOSTNAME"
- dsh -m machine1 -m machine2 -m ... 'echo $HOSTNAME'
+  dsh -m machine1 -m machine2 -m ... 'echo $HOSTNAME'
-[[http://linux-attitude.fr/post/Distribution-de-commandes | Relisez l'article]] pour apprendre comment créer des groupes de machines avec dsh.
+[[#Distribution_de_commandes | Relisez l'article]] pour apprendre comment créer des groupes de machines avec dsh.
 ==== clusterssh et clusterm ====
@@ Ligne 709: / Ligne 740: @@
 Vous pouvez définir vos groupes de machines dans le fichier /etc/clusters :
- groupe1 machine1 machine2 machine3 machine4 machine5 machine6 machine7 machine8 machine9
+  groupe1 machine1 machine2 machine3 machine4 machine5 machine6 machine7 machine8 machine9
- groupe2 machine10 machine11 machine12 machine13 machine14 machine15
+  groupe2 machine10 machine11 machine12 machine13 machine14 machine15
- all groupe1 groupe2
+  all groupe1 groupe2
 Dès lors, un
- cssh groupe1 # vous ouvre un terminal sur machine1 à machine 9
+  cssh groupe1 # vous ouvre un terminal sur machine1 à machine 9
- cssh groupe2 # vous ouvre un terminal sur machine10 à machine15
+  cssh groupe2 # vous ouvre un terminal sur machine10 à machine15
- cssh all # pour machine1 à machine15
+  cssh all # pour machine1 à machine15
 Si vous avez des ports particuliers, des utilisateurs particuliers à utiliser sur certaines machines, pensez à votre ~/.ssh/config :-)
@@ Ligne 737: / Ligne 768: @@
 Le plus simple est de lire ce qu'indique la description du paquet (apt-cache show pssh) :
-* Parallel ssh (parallel-ssh, upstream calls it pssh), executes commands on multiple hosts in parallel
+  * Parallel ssh (parallel-ssh, upstream calls it pssh), executes commands on multiple hosts in parallel
-* Parallel scp (parallel-scp, upstream calls it pscp), copies files to multiple remote hosts in parallel
+  * Parallel scp (parallel-scp, upstream calls it pscp), copies files to multiple remote hosts in parallel
-* Parallel rsync (parallel-rsync, upstream calls it prsync), efficiently copies files to multiple hosts in parallel
+  * Parallel rsync (parallel-rsync, upstream calls it prsync), efficiently copies files to multiple hosts in parallel
-* Parallel nuke (parallel-nuke, upstream calls it pnuke), kills processes on multiple remote hosts in parallel
+  * Parallel nuke (parallel-nuke, upstream calls it pnuke), kills processes on multiple remote hosts in parallel
-* Parallel slurp (parallel-slurp, upstream calls it pslurp), copies files from multiple remote hosts to a central host in parallel
+  * Parallel slurp (parallel-slurp, upstream calls it pslurp), copies files from multiple remote hosts to a central host in parallel
+ <code bash>
  # Tout d'abord, constituer un fichier groupe1.txt contenant une machine par ligne
  parallel-ssh groupe1.txt uptime
@@ Ligne 756: / Ligne 788: @@
  # Pousser un fichier localement sur toutes les machines
  parallel-scp -h groupe1.txt toto.pl ~/toto.pl
+</code>
 ==== Ailleurs ====
@@ Ligne 765: / Ligne 798: @@
 [[http://linux-attitude.fr/post/Le-travail-a-la-chaine-cest-has-been#comments | Une réaction, répondez-y]]
-----
-===== [[http://linux-attitude.fr/post/Nouveautes-chez-les-poissons | Nouveautés chez les poissons]] =====
+===== Nouveautés chez les poissons =====
+[[http://linux-attitude.fr/post/Nouveautes-chez-les-poissons | Nouveautés chez les poissons]]
 Par Peck le 24 juillet 2008, 22:29 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
@@ Ligne 782: / Ligne 815: @@
 Commençons par une nouvelle option de sshd :
- $ sshd -T
+  $ sshd -T
 Cette option permet de tester la configuration du serveur. Ce genre d'option devrait être disponible sur tous les softs, grâce à elle, vous pourrez savoir du premier coup d'oeil si vous avez bien écrit votre configuration et si sshd a bien compris la même chose que ce que vous vouliez lui dire.
@@ Ligne 790: / Ligne 823: @@
 Ensuite, une nouvelle option de ssh (qui n'est pas activée par défaut) :
- $ ssh -o "VisualHostKey true" mamachine.net
+  $ ssh -o "VisualHostKey true" mamachine.net
 Cette option affiche une interprétation du fingerprint de la machine distante sous forme d'[[http://fr.wikipedia.org/wiki/Art_ASCII | ASCII art]]. Il est ainsi beaucoup plus facile de comparer 2 clés (il suffit de les regarder).

Fourre Tout

Outils pour utilisateurs

Outils du site

Différences

Outils de la page