====== ssh en profondeur ======
D'après [[http://linux-attitude.fr/tag/Ssh | Linux attitude]]
===== Sshfs =====
[[http://linux-attitude.fr/post/Sshfs | Sshfs]] Par Peck le 23 mars 2007, 00:12 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
**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 && sshfs user@machine:/rep /mnt
==== Sshfs ou comment vous faciliter la vie. ====
N'avez-vous pas déjà pesté sur le fait de devoir travailler à distance ? Ouvrir un shell et utiliser les moyens du bord vi / emacs (ne lançons pas de troll, personnellement, je préfère ed), ou pire lancer une interface graphique (si disponible voir un éventuel autre article :-) pour éditer vos fichier et constater que tout cela est bien lent. Une autre alternative est de copier les fichiers en local chez vous et de travailler dessus (ouf enfin les outils sympa!), mais ensuite c'est la galère, il faut penser à renvoyer les fichier et après quelques aller-retours, on ne sait plus quel est le dernier fichier modifié et dans quel sens transmettre. rsync (over ssh svp) est la pour vous aider, mais ça manque de convivialité.
==== Aperçu ====
{{:linux:fichiers:sshfs.png|}}
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 :
$ ssh loin.tresloin.com "ls -a ~/devel/"
> . .. README projetv1 projetv2
$ mkdir ~/loin-devel
$ ls -a loin-devel
> . ..
$ sshfs loin.tresloin.com:~/devel loin-devel
$ ls -a loin-devel
> . .. README projetv1 projetv2
Et voilà ! Faites comme chez vous.
Vous avez tous compris, sshfs fait apparaître comme locaux des fichiers distants à travers une connexion ssh. Il suffit dont de disposer d'un accès ssh à une machine pour pouvoir faire tout ce qu'on veut.
À l'usage vous aurez éventuellement besoin de démonter un montage sshfs : utilisez la commande
$ fusermount -u ~/loin-devel
==== Installation ====
C'est génial me direz-vous, mais comment dois-je faire pour l'avoir chez moi ?
Commençons par expliquer le fonctionnement de sshfs. C'est un système de fichier basé sur ssh et donc implémenté en userland (ie pas dans le noyau) . Or "tous" les systèmes de fichiers sont dans le noyau. Une API a alors été développée pour rendre tout ceci possible: fuse (filesystem in userland). Par conséquent sshfs dépend de la présence de fuse dans votre noyau.
Ensuite à chaque utilisateur de trouver sa méthode pour installer sshfs.
apt-get install
tar xvfz && ./configure && make && sudo make install
L'information se trouve ici : http://fuse.sourceforge.net/sshfs.html
==== Note ====
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 =====
[[http://linux-attitude.fr/post/Connexion-sans-mot-de-passe | Connexion sans mot de passe]]
Par Peck le 26 mars 2007, 19:48 - [[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 moi@machine
==== Utilisation de la clé ====
Vous le savez sûrement, ssh permet de se connecter à une machine avec un mot de passe ou avec une clé. Tout d'abord un petit rappel :
$ ssh-keygen # on crée une clé ssh
$ ssh-copy-id moi@machine # on copie la partie publique sur la machine qui nous intéresse
$ ssh moi@machine # hop on peut se connecter avec la clé directement
{{:linux:fichiers:pam_ssh1.png|Connexion par ssh}}
==== Utilisation de l'agent ====
Oui c'est bien mais ... il faut se retaper la passphrase à chaque fois. Et il faut bien avouer que c'est lourd. Mais OpenSSH dans sa grande bonté nous offre un outil supplémentaire : l'agent ssh. Deuxième rappel :
$ ssh-add # on tape la passphrase une fois pour toutes
Oui c'est bien mais ... c'est lourd de se rappeler de taper ssh-add. Heureusement, il y a des outils faits pour nous le rappeler après le login graphique : les paquets ''ssh-askpass'', ''ssh-askpass-fullscreen'' et ''ssh-askpass-gnome'' qui vous demandent la clé et la mettent dans le ssh-agent.
==== Réutilisation de l'agent ====
Une dernière chose, rien de vous empêche de lancer plusieurs agents.
Voici une petite astuce pour donner à des scripts automatiques l'accès à une clé ssh sans pourtant lui donner une passphrase vide :
$ # à mettre dans un script et a lancer à la main après chaque reboot
$ ssh-agent | head -n 2 > ~/ssh-info
$ source ~/ssh-info
$ ssh-add
{{:linux:fichiers:pam_ssh2.png|Connexion avec un agent ssh}}
Maintenant tout script qui fera :
$ source ~/ssh-info
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 =====
[[http://linux-attitude.fr/post/Distribution-de-commandes | Distribution de commandes]]
Par Peck le 2 avril 2007, 20:00 - [[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é** : dsh -g cluster "echo Bonjour"
Avez-vous déjà eu à lancer la même commande sur plusieurs machines ? Si oui, cet article est fait pour vous.
{{:linux:fichiers:dsh.png?350|schéma dsh}}
==== Konsole ====
Tout d'abord, le premier outil, bien sympathique si vous avez peu de machines et si vous voulez lancer une commande interactive (par exemple vi).
Le terminal de kde "konsole" dispose d'une fonction bien utile qui est la diffusion de l'entrée utilisateur à toutes les sessions.
Pour lancer une commande sur plusieurs machines, ouvrez plusieurs onglets dans konsole, sur chaque onglet connectez-vous à une machine. Puis mettez-vous sur le premier onglet et sélectionnez "diffusion de l'entrée à toutes les sessions" dans le menu "Affichage".
A partir de maintenant, toute touche que vous taperez dans le premier onglet (et seulement lui) sera rediffusée sur tous les onglets et donc sur toutes les machines.
Attention tout de même car rien ne vous indique que ce que vous ferez sera identique sur toutes les machines. Prenons l'exemple d'un éditeur quelconque. Si sur l'une des machines le fichier à éditer est légèrement différent, il se peut que vous éditiez la mauvaise ligne. De plus, évitez d'utiliser les raccourcis permettant de revenir aux précédentes commandes, rien ne prouve que ce seront les mêmes partout. Il faut donc être vigilant et vérifier régulièrement la situation sur tous les onglets. Une bonne connaissance des raccourcis vous sera utile.
==== Dsh ====
Une autre solution qui peut être utilisée sur un bien plus grand nombre de machines est dsh.
Dsh permet de lancer une commande identique sur un groupe de machines. Il faut préalablement avoir configuré ces groupes de machines dans la configuration de dsh. Pour cela, listez simplement les machines dans le fichier $(HOME)/.dsh/group/mongroupe, une machine par ligne. Il est aussi possible de spécifier la liste des machines au coup par coup en ligne de commande, mais c'est très rapidement fatigant.
Ensuite, il suffit de lancer la commande :
$ dsh -g mongroupe 'echo $HOSTNAME'
Par défaut dsh lance ses commandes séquentiellement et le nom de la machine est ajouté devant chaque ligne de sortie. Il est possible grâce à l'option -c de lancer toutes les commandes simultanément si besoin.
L'option -m permet d'ajouter des machines au groupe à la volée.
Notez que dsh permet une interaction simple (stdin) au besoin (l'option -i peut vous être utile).
[[http://linux-attitude.fr/post/Distribution-de-commandes#comments | Une réaction, répondez-y]]
===== Login par clé ssh =====
[[http://linux-attitude.fr/post/Login-par-cle-ssh | Login par clé ssh]]
Par Peck le 4 avril 2007, 20:19 - [[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é** : apt-get install libpam-ssh && vi /etc/pam.d/...
Après avoir utilisé l'agent ssh et les clés (voir [[#Connexion sans mot de passe|article de lundi 26]]), vous voulez aller plus loin.
{{:linux:fichiers:pam_ssh1.png|pam_ssh initial}}
Je suis sûr que vous utilisez régulièrement ssh. Chose embêtante, après chaque login vous devez retaper cette passphrase pour vous connecter. Bien sûr vous avez mis un ssh-askpass pour ne plus oublier de la taper, mais c'est un peu lourd.
Je vous propose donc d'entrer cette passphrase une seule fois directement au login. Elle remplacera votre mot de passe et enregistrera directement la clé dans l'agent. Comment faire ? Tout d'abord installez libpam-ssh avec la méthode que propose votre distrib favorite. Ensuite, il vous faut choisir pour quels type de login vous voulez ceci. La liste se trouve dans /etc/pam.d Il est probable que vous le vouliez pour kdm ou gdm mais pas pour les autres. Dans ce cas éditez le fichier en question, il doit ressembler à quelque chose comme ceci :
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include pam-ssh-auth
@include common-auth
@include common-account
session required pam_limits.so
@include pam-ssh-session
@include common-session
@include common-password
Les includes liés à pam-ssh se situent avant les autres pour permettre de demander la passphrase en premier. Mais on a gardé l'ancienne méthode, donc en cas d'échec, il est toujours possible de donner son mot de passe pour se connecter.
Il se peut que votre distribution n'utilise pas d'include pour configurer pam. A ce moment les lignes à ajouter ressembleront plutôt à ceci :
auth sufficient pam_ssh.so try_first_pass keyfiles=id_dsa,id_rsa,identity,id_dsa1,id_dsa2,id_dsa3
session optional pam_ssh.so
{{:linux:fichiers:pam_ssh2.png|pam_ssh nouveau}}
Pam étant une bibliothèque, il n'y a rien a relancer.
===== S'échapper devant un problème =====
[[http://linux-attitude.fr/post/Sechaper-devant-un-probleme | S'échapper devant un problème]]
Par Peck le 11 mai 2007, 19:20 - [[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é** : ^] et ~.
Telnet et son successeur sécurisé ssh sont des client permettant un accès distant. Tout caractère tapé dans le client est aussitôt transmis au système distant qui aura la charge de l'interpréter. Tous ! Non, quelques caractères résistent encore et toujours au transfert sauvage.
En effet, il est possible de donner des commandes directement au client avec le clavier. Pour que celles-ci fonctionnent, il faut que certains caractères ne soient pas envoyés au serveur mais interprétés par le client lui-même. Ce sont des caractères de contrôle. Nous allons voir le cas particulier du caractère d'échappement.
==== Telnet ====
Le caractère d'échappement de telnet est par défaut ^] (ou ctrl-] selon l'écriture choisie). Tapez ensuite "help" pour avoir la liste des commandes que peut comprendre telnet. La plus importante à connaître est quit.
Elle est utile lorsque vous tentez de vous connecter à une machine avec telnet et que votre connexion est bloquée pour une raison ou pour une autre. Ex :
$ telnet localhost imap
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
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" pour forcer la déconnexion.
**Note** : le caractère de contrôle ^E (ou ctrl-E) permet de désactiver l'affichage de ce qu'on est en train de taper, c'est parfois utile si le serveur répète ce que vous écrivez.
==== Ssh ====
Le caractère d'échappement de ssh est par défaut ? et la commande la plus importante est ~. qui permet comme avec telnet de couper la connexion et de quitter ssh.
Par exemple si vous lancez un processus qui bloque votre shell ou si le serveur distant ne répond plus, vous ne pouvez plus rien faire. La séquence permet d'arreter directement le client ssh sans attendre un timeout.
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.
===== SXP =====
[[http://linux-attitude.fr/post/SXP | SXP]]
Par Peck le 4 juin 2007, 20:00 - [[http://linux-attitude.fr/category/Sysadmin | Sysadmin]]
**Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
**Résumé** : scp machine1:~/file machine2:~/
==== FXP ====
Le FXP est un détournement du protocole FTP. Le FTP utilisant une connexion différente pour les données et pour les commandes, il est possible d'ouvrir une connexion de commande sur 2 machine et leur demander d'ouvrir la connexion de données entre elles deux. [[http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-FXP.html | Explication plus détaillée]].
En pratique, la plupart des clients ftp supportent ce système nativement (même en ligne de commande).
==== SCP ====
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
Le processus est alors le suivant :
* 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).
Ceci a 2 inconvénients :
* 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 [[#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"
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 > /your/path/1"
**PS** : Dans vos commandes scp, il est possible d'écrire "machine:" comme équivalent de "machine:~/"
**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/
===== 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]]
**Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
**Résumé** : Match
Savez vous qu'en ssh vous pouvez imposer des contraintes à certains utilisateurs seulement.
Exemple pour interdire l'utilisation de mots de passe à un groupe d'utilisateurs (à mettre dans /etc/ssh/sshd_config) :
Match Group glandus
PasswordAuthentication no
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é :
Match User toto
ForceCommand /bin/cat /etc/php5/apache2/php.ini
Pour forcer l'affichage d'un texte d'avertissement avant la connexion pour les machines venant d'un certain réseau :
Match Host *.linux.fr
Banner /etc/ssh_warn
Pour interdire le forwarding de port à une machine (un utilisateur un peu doué saura contourner ça) :
Match Address 192.168.1.1
AllowTcpForwarding no
[[http://linux-attitude.fr/post/La-dure-loi-du-ssh#comments | 2 réactions, répondez-y]]
===== 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]]
**Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
**Résumé** : ssh -o VerifyHostKeyDNS=yes
Désolé pour lundi dernier, over-blog était en rade et ça m'a fait une excuse pour ne pas publier :-)
Vous avez tous déjà touché à un ssh. Rappelez-vous votre première connexion :
$ 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)?
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.
En pratique personne ne le fait ! Si vous l'avez toujours fait, soit vous ne vous êtes jamais connecté avec ssh, soit vous êtes Rain-Man. Sinon vous êtes à peu près normal.
Par conséquent vous faites confiance aux pirates de tout poil pour ne pas avoir attaqué votre serveur au moment de votre première session. Question qui ne se pose plus par la suite où vous faites implicitement confiance à vos connexions précédentes.
==== Confiance relative ====
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
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
La valeur par défaut est ask et est écrite dans /ect/ssh/ssh_config (ou ~/.ssh/config si vous en avez un).
==== Confiance toute aussi relative ====
Mais vous vous dites, pourquoi cette information n'est elle pas centralisée, il suffirait ainsi de faire confiance à une unique entité pour que toutes les connexions ssh soient "de confiance".
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
1 et 1 indiquent les type de clé et sont suivis par la clé elle-même.
Ensuite vous vous connectez à votre machine pour la première fois
$ ssh -o VerifyHostKeyDNS=yes mamachine.toto.net
The authenticity of host 'toto.localhost (127.0.0.2)' can't be established.
RSA key fingerprint is d9:16:53:ef:84:cf:1a:ce:42:03:55:09:86:5c:0e:50.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
Presque, mais ssh ne fait pas confiance à votre serveur DNS et il vous pose donc quand même la question.
==== Confiance un peu plus relative ====
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 :
$ ssh -o VerifyHostKeyDNS=yes mamachine.toto.net
$ hosname
> mamachine.toto.net
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 ...
==== Un peu plus loin ====
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 :
$ ssh-keygen -r localhost
127.0.0.1 IN SSHFP 1 1 1d7b808b64aa57c2451d3635dc4dbb6931c8c715
127.0.0.1 IN SSHFP 2 1 ba276a0efde89b9f041b4e42780ee317a48403b9
# prêt à être inséré dans la zone DNS
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).
[[http://linux-attitude.fr/post/Aie-confiance-crois-en-moi#comments | 3 réactions, répondez-y]]
===== 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@
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 :
Host machine
Hostname mamachine.monreseau.net
Au passage vous pouvez ajouter le port et le login par défaut dans cette configuration.
Host machine
Hostname mamachine.monreseau.net
Port 1022
User toto
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 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 !
Non, nous allons faire mieux. Hop un script shell :
#!/bin/sh
# fichier hosts personnel
FILE=~/.hosts
# domaines à scanner
DOMAINS="toto.net mamachine.net"
# machines à ajouter à la main (l'IP b'est pas vraiment obligatoire)
cat > $FILE << EOF
1 mamachine.youpi.fr
2 tamachine.youpi.fr
EOF
for domaine in $DOMAINS
do
dig $domaine axfr | egrep "IN[=[[:space:]]=]+A" | awk '{print $5,$1}' >> $FILE
done
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).
Maintenant il vous reste à le lancer (au moins une fois), à ajouter une ligne dans votre .bashrc :
export HOSTFILE=~/.hosts
/
Et à ajouter ce script dans une crontab pour être toujours à jour de la liste de vos machines.
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
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 ...]]
===== 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@
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 :
#!/bin/sh
# fichier hosts
FILE=~/.hosts
# domaines à scanner
DOMAINS="toto.net mamachine.net"
# machines à ajouter à la main (plus d'ip du tout)
cat > $FILE << EOF
mamachine.youpi.fr
tamachine.youpi.fr
EOF
for domaine in $DOMAINS
do
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 - > ~/.ssh/known_hosts
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.
Et voilà !
Enfin presque, car vous avez bien récupéré les clés, c'est pratique pour votre utilisation de ssh, mais qu'en est-il des nouvelles machines auxquelles vous accédez ? Elles sont naturellement ajoutées au fichier known_hosts, mais il existe deux méthodes pour stocker les noms de machine dans le known_hosts, soit en clair, soit hashé.
Et pour que la complétion fonctionne, il faut nécessairement que ce soit en clair. Donc option "HashKnownHosts no " dans .ssh/config. Mais attention, l'option a été inventée pour qu'en cas de compromission de votre machine l'attaquant ne sache pas quelles sont les machines que vous administrez régulièrement (pour tenter de s'y attaquer).
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:/ # root c'est mâaal !
Victoire !
[[http://linux-attitude.fr/post/article-suivant#comments | Une réaction, répondez-y]]
===== 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]]
**Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
**Résumé** : xchat ; screen irssi
Allez-vous sur irc de temps en temps ? Non alors je vais vous couper la tête !
==== Introduction ====
Irc, Internet Relay Chat est LE moyen de discuter sur internet. Contrairement à la messagerie instantanée, l'irc a pour principe de base de discuter avec des groupes de personnes et non pas avec une personne en particulier. Bien sur, ceux qui veulent discuter seul à seul le peuvent aussi. Je vous passe les bases du protocole, mais il est assez simple. Le principe est de faire passer toute communication par un serveur, lequel redistribue le message vers les clients concernés. Comme il ne peut y avoir un serveur unique, les serveurs sont connectés entre eux et se redistribuent les messages à travers le net.
Au départ l'irc était comme le mail, tout le monde pouvait parler à tout le monde, mais l'histoire ainsi que des désaccords sur la façon de gérer ce réseau on fait que l'irc est maintenant divisé en réseaux qui ne communiquent pas entre eux. Ces réseaux portent des noms comme efnet, dalnet, freenode ... on les compte par centaines. Et c'est bien dommage, car il est assez difficile de s'y repérer.
Sur un réseau irc, on retrouve de nombreux canaux, un canal est un lieu de discussion dont le nom commence généralement par #. On en trouve des dizaines de milliers, chacun avec un sujet différent. C'est dire si vous pouvez y trouver votre bonheur.
==== Un client simple ====
Pour vous connecter sur irc, il existe un outil sympathique nommé [[http://xchat.org/ | xchat]]. Il a l'avantage de connaître la plupart des réseaux et la plupart des serveurs associés. Il vous permettra de vous connecter à plusieurs serveurs et de nombreux canaux simultanément ?
Son interface graphique est simple et intuitive, et la plupart des actions peuvent être effectuées sans taper une ligne de commande.
==== Un client avancé ====
Mais ce n'est pas pour vous parler de xchat que je fais cet article. Un autre client irc populaire chez les linuxiens est [[http://irssi.org/ | irssi]]. Ce client fonctionne purement en mode texte. C'est à la fois un avantage et un inconvénient. Inconvénient car les débutants devront apprendre le commandes irc de base. Mais un avantage car il est possible de le lancer à peu près partout avec ou sans interface graphique et qu'on peut le combiner avec screen.
Détaillons donc ce que cela veut dire. Si vous disposez d'une machine connectée en permanence à internet, vous pourrez y lancer irssi pour ne jamais l'arrêter, jamais ... Vous ne perdrez plus une miette des discussions, et on pourra vous écrire même quand vous n'êtes pas là.
Pour le lancer :
$ screen -S irc
$ irssi
Puis pour vous y reconnecter :
$ 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'"
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.
===== 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]]
**Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
**Résumé** : ssh-agent ; ssh-add
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.
Lorsque vous vous connectez en ssh avec l'option -A (en général présente par défaut), ssh tunnelle simplement une socket sur la machine de destination vers la machine de départ. Ce qui veut dire que l'agent que vous utiliserez sur cette machine distante est celui de la machine d'origine. Autrement dit vous disposez des clés de la machine de départ, mais ssh-add ajoutera des clés de la machine de destination sur la machine de départ. Testez, vous verrez c'est amusant.
Maintenant puisque la communication se fait à travers une socket, n'importe quel processus peut communiquer avec elle. C'est en partie vrai, car les socket respectent les droits établis par le système de fichier. Donc en gros seul root et vous peuvent communiquer avec cette socket. Ainsi, si vous vous connectez à une machine sur laquelle vous avez déjà un agent qui tourne vous pouvez le réutiliser.
Pour avoir la liste des agents disponibles :
$ ls -ld /tmp/ssh-* | grep `whoami`
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-
Maintenant, pour la réutiliser, il suffit simplement d'affecter la variable adaptée :
$ export SSH_AUTH_SOCK=/tmp/ssh-lwksuR6740/agent.6740
$ ssh nouvelle.machine
# et voila !
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
===== 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]]
**Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
**Résumé** : ssh -M -S
Si vous faites de nombreuses connexions ssh à une machine, soit pour lancer plusieurs shells, soit pour exécuter des séries de commandes, votre client ssh va initialiser une nouvelle connexion à chaque fois. Ceci peut devenir très lourd pour une machine un peu ancienne. En effet, ceci implique le handshake tcp, la négociation du cryptage, l'échange de clés et donc un certain temps de calcul.
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 :
# première connexion
$ ssh -M -S /tmp/master mamachine.net
# deuxième connexion
$ ssh -S /tmp/master mamachine.net
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.
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
# mamachine.net ou azerty c'est pareil
$ ssh -S /tmp/master azerty
[[http://linux-attitude.fr/post/Un-tien-vaut-mieux-que-deux-connexions#comments | Une réaction, répondez-y]]
>Le 18 février 2008, 11:25 par Simon
>Et pour automatiser l'usage de cette option :
cat >> ~/.ssh/config << EOF
Host *
ControlPath ~/.ssh/master-%r@%h:%p
ControlMaster auto
EOF
>(outrageusement copié depuis http://nion.modprobe.de/blog/archives/502-Speeding-up-SSH-ControlMaster.html)
===== 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]]
**Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
**Résumé** : locale ; export LANG ; AcceptEnv ; SendEnv
Je vais devoir arrêter les voyages, hier, je change de locale, aujourd'hui je me connecte ... rien !
Une locale c'est tout un ensemble de choses qui permettent de faire en sorte que les logiciels s'affichent dans la langue qui vous convient. Pour les développeurs, j'ai un début d'[[http://linux-attitude.fr/Donnez-moi-du-texte | explication]] sur la [[http://linux-attitude.fr/post/Toujours-du-texte | technique]].
Et ça commence par des variables locales. La première c'est LANG, qui définit la façon par défaut d'afficher les informations. Cette méthode peut ensuite être surchargée finement avec les variables LC_*, par exemple LC_MONETARY permet de changer spécifiquement l'affichage de la monnaie. Et enfin, toutes ces valeurs peuvent encore être surchargées globalement et d'un coup par la variable LC_ALL.
É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
Pour la changer :
# on liste les locales disponibles
$ locale -a
# on en choisit une
$ export LANG=fr_FR
À ajouter dans votre .bashrc pour conserver la chose un peu plus longtemps (attention, gnome et kde ''et caetera'' sont à configurer séparément).
Pour changer ceci de façon globale, ben c'est pas gagné, selon les distributions et les softs, tous n'utilisent pas les même fichiers de configuration. Tout d'abord, il y a l'historique /etc/environment, pour les shells on peut aussi chercher dans /etc/profile. Et ensuite, mais c'est spécifique debian, il y a /etc/default/locale.
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
indiquant où chercher vos variables.
Et enfin, parlons ubiquité, je ne sais pas vous, mais moi je suis partout, j'ai un compte sur toutes les machines (si je n'en ai pas chez vous, appelez-moi, j'accepterai volontiers un compte, de préférence root, mais je ne voudrais pas déranger). Je suis tout d'abord chez moi, avec ma locale, et donc mon terminal adapté à cette locale (hé oui, pensez iso vs utf8) et je me connecte en ssh sur un de mes comptes. Je voudrais bien rester moi-même et garder mes locales et non pas prendre celle du système ou devoir configurer chacun des shells de destinations à la main. Heureusement, ssh a aussi prévu ce cas. Il permet la transmission des locales s'il est configuré correctement.
Sur le serveur, dans /etc/ssh/sshd_config :
# on autorise le client a jouer avec les locales à la connexion
AcceptEnv LANG LC_*
Sur le client, de préférence dans /etc/ssh/ssh_config :
Host *
# on envoit nos locales au serveur
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.
[[http://linux-attitude.fr/post/Donner-sa-la-langue-au-sshat#comments | 3 réactions, répondez-y]]
===== 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]]
**Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
**Résumé** : clusterssh, clusterm, konsole, dsh, pssh
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 [[#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 [[#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 > Send Input to All Sessions''. Désormais, tout ce que vous tapez est répété dans toutes les fenêtres.
Avec dsh :
dsh -m machine1 -m machine2 commande
Attention, n'oubliez pas que votre commande est d'abord interprétée par votre shell. Ainsi, comparez :
dsh -m machine1 -m machine2 -m ... "echo $HOSTNAME"
dsh -m machine1 -m machine2 -m ... 'echo $HOSTNAME'
[[#Distribution_de_commandes | Relisez l'article]] pour apprendre comment créer des groupes de machines avec dsh.
==== clusterssh et clusterm ====
Mais si on désire surveiller ce qui se passe sur toutes les machines, et ainsi avoir un contrôle visuel, et au besoin effectuer une correction sur une machine en particulier, alors des outils graphiques rendent bien service, en affichant dans un terminal distinct chacune des machines que l'on contrôle. Par ici pour des captures d'écran, et [[http://debaday.debian.net/2007/12/09/clusterssh-control-serveral-ssh-sessions-via-a-single-interface/ | un petit article de présentation de clusterssh]] !
Vous pouvez définir vos groupes de machines dans le fichier /etc/clusters :
groupe1 machine1 machine2 machine3 machine4 machine5 machine6 machine7 machine8 machine9
groupe2 machine10 machine11 machine12 machine13 machine14 machine15
all groupe1 groupe2
Dès lors, un
cssh groupe1 # vous ouvre un terminal sur machine1 à machine 9
cssh groupe2 # vous ouvre un terminal sur machine10 à machine15
cssh all # pour machine1 à machine15
Si vous avez des ports particuliers, des utilisateurs particuliers à utiliser sur certaines machines, pensez à votre ~/.ssh/config :-)
Et comme indiqué dans les commentaires, une alternative à clusterssh est [[http://sourceforge.net/projects/clusterm | clusterm]], qui est un peu plus ''eye-candy'' et offre en plus la merveilleuse fonctionnalité d'afficher les différences entre les écrans, à la vimdiff, très pratique pour comparer rapidement des fichiers de configuration entre n machines distinctes ! Malheureusement, ce programme n'est pas packagé pour Debian, libre à vous de lancer une ITP dessus ;-)
Toutefois, des paquets pour ubuntu existent (ils marchent aussi sous debian), il suffit de récupérer les 2 .deb [[http://sourceforge.net/project/showfiles.php?group_id=150463 | proposés]] et de les installer à coup de dpkg -i.
Pas de fichier de configuration de groupe pour ce programme, mais plusieurs options :
alias clusterm-groupe1='clusterm machine1 machine2 machine3 machine4 machine5 machine6 machine7 machine8 machine9'
ou bien constituer votre groupe "à la main" dans l'interface, en ouvrant successivement vos shells sur chacune des machines indiquées, puis enregistrer votre session (menu fichier) sous forme d'un raccourci à placer sur votre bureau :-)
==== pssh ====
Une autre petite suite d'outils bien sympathique est pssh, qui propose diverses commandes comme parallel-ssh (équivalent de dsh -c), parallel-nuke, parallel-scp ou parallel-slurp (son contraire).
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 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 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
# Tout d'abord, constituer un fichier groupe1.txt contenant une machine par ligne
parallel-ssh groupe1.txt uptime
# Récupérer dans des répertoires relatifs au nom des serveurs un fichier donné sur chacun des serveurs
mkdir -p /tmp/slurp
parallel-slurp -h groupe1.txt -L /tmp/slurp /etc/hostname hostname
ls -lR /tmp/slurp
# Tuer apache* sur tout un groupe de machines
parallel-nuke -h groupe1.txt apache
# Pousser un fichier localement sur toutes les machines
parallel-scp -h groupe1.txt toto.pl ~/toto.pl
==== Ailleurs ====
Autrement, d'autres outils du même acabit existent, vous trouverez ici [[http://tentakel.biskalar.de/similar/ | une liste non exhaustive]]. N'hésitez pas à partager ici vos découvertes !
À plus peut être pour une nouvelle aventure, si vous le voulez bien :-)
[[http://linux-attitude.fr/post/Le-travail-a-la-chaine-cest-has-been#comments | Une réaction, répondez-y]]
===== 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]]
**Niveau** : {{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:s.gif|}}{{:linux:fichiers:e.gif|}}{{:linux:fichiers:e.gif|}}\\
**Résumé** : sshd -T ; ssh -l
I'm back ! Ca y est j'ai déménagé. Je peux maintenant reprendre mon activité normale ...
Au cas où vous ne le sauriez pas, la dernière version de [[http://www.openssh.com/ | openssh]] vient de sortir, la 5.1. La lecture du [[http://openssh.com/txt/release-5.1 | changelog]] est très instructive. On y découvre entre autre deux nouveautés ben sympathiques.
==== Serveur ====
Commençons par une nouvelle option de sshd :
$ 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.
==== Client ====
Ensuite, une nouvelle option de ssh (qui n'est pas activée par défaut) :
$ 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).
Cette fonction répond au problème de la confiance au serveur ssh. Lorsque vous vous connectez, ssh vérifie que le serveur distant est connu, si vous vous y êtes déjà connecté et que la clé n'a pas changé, on peut faire confiance en son identité. Mas lorsque c'est la première fois que vous vous connectez, il faut vérifier manuellement que la clé est ben la bonne. Avec cette option la vérification est simplifiée, on espère donc que les gens la feront plus souvent ...
[[http://linux-attitude.fr/post/Nouveautes-chez-les-poissons#comments | 2 réactions, répondez-y]]