Articles précédents : Articles
- [70] NIN : quand la musique s'ouvre un peu
- [65] Le test Acid3 a été publié en version finale
- [23] Gary Gygax est décédé
- [9] Opale, un logiciel libre pour produire des documents de formation
- [20] Le projet Milimail désire changer de nom
- [34] Opération « OS Réfugié » relancée chez Mandriva
- [23] Retour sur la panne serveur et l'appel aux dons
- [12] Le libre et les mémoires de traduction
- [20] Campagne Sound Copyright contre l'allongement des droits des artistes-interprètes
- [48] Avant-projet Olivennes : un texte extrémiste ?
Liens connexes
- Automounting FUSE filesystems (linux.com) (190 hits)
- Using MySQL as a filesystem (linux.com) (218 hits)
- FUSE (FileSystem in UserspacE) (130 hits)
- SSHFS (fuse) (172 hits)
- afuse (automount fuse) (125 hits)
Dépêche modérée par
Dépêche éditée par
Articles : Administration de serveur Unix en DMZ via serveur de rebond
Posté par yannig (page perso, ). Modéré le 07 mars 2008.Dans ce qui va suivre, je ferai des références à un ensemble de produits. Je vais en faire ici une rapide présentation :
- openssh (que je ne présenterai pas)
- fuse : module noyau permettant de manipuler des points de montage en tant qu'utilisateur lambda
- tsocks : bibliothèque permettant l'encapsulation des requêtes réseaux d'un programme.
- afuse : utilitaire permettant de se servir de fuse pour faire des automounts.
Automounting FUSE filesystems (linux.com) (190 hits)
Using MySQL as a filesystem (linux.com) (218 hits)
FUSE (FileSystem in UserspacE) (130 hits)
SSHFS (fuse) (172 hits)
afuse (automount fuse) (125 hits)
> Lire la dépêche (18 commentaires, moyenne: 3,6).
Pour ce qui va suivre, je me baserai sur une installation standard de Kubuntu 7.10 et nous allons notamment avoir besoin des paquets suivants :
- sshfs
- tsocks
- afuse
sudo aptitude install fuse tsocks afuseL'installation ne posant pas de problème insurmontable, je ne m'étendrai pas plus sur le sujet.
Vous devez en revanche vous assurer que votre utilisateur (dans mon cas yannig) doit bien appartenir au groupe fuse :
yannig@yannig-desktop:~$ id -a
uid=1000(yannig) gid=1000(yannig) groups=4(adm),20(dialout),...106(fuse),108(lpadmin),...1000(yannig)Si ce n'est pas le cas, vous pouvez rajouter l'utilisateur avec la commande suivante :
yannig@yannig-desktop:~$ sudo usermod -G fuse yannigAttention de vous déloguer/reloguer si vous êtes dans une session graphique pour prendre en compte ce changement de groupe. Il faudra également relancer votre terminal si vous êtes logué en ssh sur votre machine.
Mise en place
La première étape va consister à mettre en place nos moyens de communication avec le serveur de rebond et entre autre la mise en place de clé d'authentification. Pour se faire, nous allons user des clés d'authentification que nous déposerons dans le répertoire adhoc de l'utilisateur du serveur de rebond :
1/ Génération de la clé :
yannig@yannig-desktop:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/yannig/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/yannig/.ssh/id_dsa.
Your public key has been saved in /home/yannig/.ssh/id_dsa.pub.
The key fingerprint is:
a9:xx:7d:xx:d9:xx:ea:xx:bd:xx:66:xx:98:xx:47:xx yannig@yannig-desktop2/ Dépôt de la clé sur le serveur de rebond :
yannig@yannig-desktop:~$ cat .ssh/id_dsa.pub | ssh yannig@rebond "cat >> /home/yannig/.ssh/authorized_keys"
The authenticity of host 'rebond (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is 78:xx:ab:xx:d7:xx:26:xx:49:xx:ec:xx:aa:xx:47:xx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'rebond' (RSA) to the list of known hosts.
yannig@rebond's password:Nous recopions ici le contenu de la clé publique que nous venons de générer dans la liste des clés autorisées à se connecter sur mon compte sur le serveur de rebond. Ainsi, la prochaine fois que nous chercherons à nous connecter sur la machine de rebond, je n'aurai pas de mot de passe à saisir :
yannig@yannig-desktop:~$ ssh yannig@rebond
Last login: Wed Mar 5 09:21:35 2008 from xx.xx.xx.xx
Authorized uses only. All activity may be monitored and reported.
yannig@rebond#3/ Création d'un point de montage sshfs
yannig@yannig-desktop:~$ mkdir test
yannig@yannig-desktop:~$ sshfs yannig@rebond:/tmp test
yannig@yannig-desktop:~$ ls test
croxxLa crxxLa getxxxt psxxta
crouxxiLa get_xxp lxxe
croxxiLa gexxxt PPCxx303Ça à l'air de fonctionner !
Accès à nos serveurs via serveur de rebond
Nous avons maintenant configuré une connexion à notre serveur de rebond et nous pouvons même monter en local le système de fichier via SSH du serveur de rebond. Problème, si nous devons accéder aux serveurs derrière le serveur de rebond, nous sommes obligés de nous reconnecter à chaque fois sur ce dernier pour ensuite lancer la connexion :
yannig@yannig-desktop:~$ ssh -o ConnectTimeout=2 yannig@host-dmz1
ssh: connect to host host-dmz1 port 22: Connection timed out=> impossible de se connecter directement sur le serveur host-dmz1
yannig@yannig-desktop:~$ ssh yannig@rebond
Last login: Wed Mar 5 09:45:36 2008 from 10.251.100.134
yperre@rebond#ssh yannig@host-dmz1
yannig@host-dmz1's password:Ce genre de chose entraîne plusieurs inconvénients :
- multiplication du nombre de connexions sur la machine de rebond
- perte de temps et multiplication des opérations pour se connecter à vos machines. Lorsque vous avez un parc de 200 machines à administrer, vous n'avez pas forcément envie de vous reconnecter 50 fois par jour.
Pour se faire, nous allons relancer notre connexion sur le serveur de rebond en y ajoutant l'option '-D 8888' permettant la création d'un port dynamique sur le port 8888 (le port dynamique est en réalité vu comme un serveur socks) :
yannig@yannig-desktop:~$ ssh -D 8888 yannig@rebond
Could not request local forwarding.
Last login: Wed Mar 5 09:48:38 2008 from 10.251.100.134
yannig@rebond#Remarque, si vous voyez les lignes suivantes :
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 88882 possibilités s'offrent à vous :
- vous avez déjà une connexion ouverte avec un tunnel
- vous avez un programme en local qui fait appel au port 8888 => Changez en !
C'est très bien tout ça mais ssh ne peut pas utiliser de serveur SOCKS pour se connecter sur nos serveurs. Il va donc falloir trouver une autre solution : une bibliothèque 'socksificatrice' (ouf!)
Vous avez le choix entre dante-client et tsocks. Mon choix c'est porté sur tsocks en raison de sa simplicité mais ce qui va suivre est tout à fait utilisable sous dante !
Comme nous l'avons vu plus haut, tsocks (sous *Ubuntu) s'installe simplement via le système de packaging. Par défaut, il vous proposera un fichier de configuration /etc/tsocks.conf. Je vous propose de le modifier de la manière suivante :
yannig@yannig-desktop:~$ cat /etc/tsocks.conf
#
server = 127.0.0.1
# Server type defaults to 4 so we need to specify it as 5 for this one
server_type = 5
# The port defaults to 1080 but I've stated it here for clarity
server_port = 8888Il nous reste maintenant à socksifier nos appels ssh et tadam :
yannig@yannig-desktop:~$ LD_PRELOAD=/usr/lib/libtsocks.so ssh yannig@host-dmz1
yannig@host-dmz1's password:Nous sommes maintenant en mesure d'accéder directement à notre serveur en DMZ depuis notre poste de travail. Essayons maintenant de combiner ceci avec un montage sshfs encapsulé dans un tunnel ssh :
yannig@yannig-desktop:~$ LD_PRELOAD=/usr/lib/libtsocks.so sshfs yannig@host-dmz1:/usr/local/lib test
yannig@yannig-desktop:~$ ls test
libcharset.a libgcc_s.so.1 libpopt.la
libcharset.la libiconv.la libpopt.so
libcharset.so libiconv.so libpopt.so.0
libcharset.so.1 libiconv.so.2 libpopt.so.0.0.0
libcharset.so.1.0.0 libiconv.so.2.4.0 libstdc++.a
libg2c.a libintl.a libstdc++.la
libg2c.la libintl.la libstdc++.so
libg2c.so libintl.so libstdc++.so.6
libg2c.so.0 libintl.so.3 libstdc++.so.6.0.3
libg2c.so.0.0.0 libintl.so.3.4.0 preloadable_libiconv.so
libgcc_s.so libpopt.aEt hop, on a directement accès en local, de manière transparente, à nos fichiers sur la machine en DMZ. De là, il est tout à fait possible de recopier nos fichiers d'un serveur à un autre en s'appuyant sur ces points de montage.
Vous me direz que c'est déjà pas mal comme situation mais je suis malheureusement au regret de vous annoncer qu'on peut faire encore mieux : l'utilisation d'un automount fuse !
Automount avec fuse
Nous avons vu jusqu'à maintenant les points suivants :
- utilisation d'un serveur de rebond
- échange des clés privés / publiques
- montage d'un système de fichier à l'aide du protocole ssh
- connexion sur un serveur au travers d'un serveur SOCKS / tunnel / port dynamique
- connexion d'un système de fichier par l'utilisation d'un serveur SOCKS.
Pour se faire, nous allons lancer une commande qui prendra comme paramètre un template de montage fuse sshfs.
Voici la commande en question :
afuse -f -o \
mount_template="LD_PRELOAD=/usr/lib/libtsocks.so sshfs yannig@%r:/ %m" -o \
unmount_template="fusermount -u -z %m" ~/sshfsA remarquer que cette commande bloquera votre terminal. Si vous désirez la lancer en tant que démon, il faudra la précéder de la commande nohup ainsi que '&' pour la lancer en arrière plan.
Autre remarque important, si vous utilisez une distribution récente (*ubuntu, debian, mandriva, etc), votre distribution utilisera certainement un encodage UTF8. Si vous utilisez un vieil Unix / Unix proprio (Solaris 8, AIX 5.x etc), vous aurez surement un encodage de type ISO8859-1. Il vous faudra surement renseigner l'option '-o from_code=ISO8859-1'.
Voyons maintenant le résultat :
yannig@yannig-desktop:~$ cd sshfs/
yannig@yannig-desktop:~/sshfs$ ls
yannig@yannig-desktop:~/sshfs$ cd host-dmz1
yannig@yannig-desktop:~/sshfs/host-dmz1$ ls
bin cdrom etc initrd lib media opt root srv tmp var
boot dev home initrd.img lost+found mnt proc sbin sys usr vmlinuz
yannig@yannig-desktop:~/sshfs/host-dmz1$ cd ..
yannig@yannig-desktop:~/sshfs$ ls
host-dmz1
yannig@yannig-desktop:~/sshfs$ cd recette-dmz1
yannig@yannig-desktop:~/sshfs/recette-dmz1$ ls
1 dead.letter HDS lost+found proc root
11 dev home mnt prod sbin
devices kernel mnt2 doc legal noautoshutdown
bin etc lib opt var usr
LICENSE.txt platform
yannig@yannig-desktop:~/sshfs/recette-dmz1$ cd ..
yannig@yannig-desktop:~/sshfs$ ls
host-dmz1 recette-dmz1Vous voici maintenant capable de faire des recopies de manière transparente entre 2 machines pouvant se trouver sur 2 DMZ différentes depuis votre poste (ou encore en éditant ceci avec un emacs ou autre kate et vi) et tout ceci de manière complétement transparente tout en facilitant l'accès à vos machines en DMZ.
C'est les gars de la sécurité qui vont être contents !
ProxyCommand
je trouve la méthode utilisant Proxycommand bien plus simple et transparente:
voir par exemple ici: http://ensl.free.fr/softrez/faq/faq-9.html#ss9.1
(cela necessite d'avoir tcpconnect ou netcat sur le serveur rebond)
-
[^]Re: ProxyCommand
Posté par yannig (page perso, ) le 07/03/2008 à 13:16. (lien). Évalué à 2.Pour ma part, je préfère tsocks ou dante pour une raison simple : tu n'as besoin de rien sur ton serveur de rebond sauf de pouvoir créer des tunnels SSH.
-
[^]Re: ProxyCommand
Posté par Etienne "Tinou" Labaume () le 07/03/2008 à 14:29. (lien). Évalué à 3.En l'occurrence, pour la technique utilisant ProxyCommand, le seul prérequis dont tu as besoin, c'est d'avoir netcat sur le serveur de rebond. Rien d'autre n'est requis sur aucune des 3 machines (client, serveur, et serveur de rebond). Il se trouve en plus que nc est installé par défaut sur certains OS (OpenBSD, par ex.).
--
Tinou
-
-
[^]Re: ProxyCommand
Posté par kolter (page perso, ) le 07/03/2008 à 23:56. (lien). Évalué à 2.je suis clairement d'accord avec toi, de plus je vais briser un mythe :
Attention de vous déloguer/reloguer si vous êtes dans une session graphique pour prendre en compte ce changement de groupe. Il faudra également relancer votre terminal si vous êtes logué en ssh sur votre machine.
et là je dis NON, la commande newgrp existe et autant s'en servir donc : newgrp fuse
de plus si je peux faire quelque remarques :
sudo usermod -G fuse yannig -> adduser yannig fuse
et :
cat .ssh/id_dsa.pub | ssh yannig@rebond "cat >> /home/yannig/.ssh/authorized_keys" -> ça peut se simplifier en utilisant ssh-copy-id sur les distribs basé sur debian.
M.
Dépêche
Bonjour,
Ce didacticiel est de qualité mais suis-je le seul à me demander ce qu'il fait parmi des dépêches ? N'aurait-il pas sa place parmi les astuces plutôt ?
J'ai appris des choses sur ssh mais si on commence à mettre des tutos on ne verra plus les news.
Une place pour chaque chose et chaque chose à sa place...
FAb
-
[^]Re: Dépêche
Posté par patrick_g (page perso, ) le 07/03/2008 à 15:20. (lien). Évalué à 4.Y'a eu polémique lors de l'étape de modération. Le problème, je crois, c'est que peu de gens lisent les astuces alors qu'une dépêche à plus de visibilité. C'est ce qui a conduit à l'acceptation en tant que news.
-
[^]Re: Dépêche
Posté par Christophe KINNE () le 07/03/2008 à 15:29. (lien). Évalué à 4.Pourquoi ne pas faire les deux tout simplement lorsque on a une petite doc de qualité comme celle là ?
Plus de visibilité, dispo dans les astuces et une petite dépêche sympa en plus sur le site... qui ne croule pas non plus sous les news (patapai c'est juste pour dire que la première page ne se renouvelle pas aussi vite que sur d'autres sites moins regardants sur la qualité du contenu.)-
[^]Re: Dépêche
Posté par Totoffe (page perso, ) le 07/03/2008 à 15:56. (lien). Évalué à 10.Suggestion qui découle de la précédente : faire, de temps en temps (par exemple 1 ou 2 fois par mois), un article qui récapitulerait les (meilleures ?) astuces postées pendant la période.
On resterait dans une optique "News", tout en donnant plus de visibilité aux astuces (et à davantage d'astuces, au passage).-
[^]Re: Dépêche
Posté par baud123 (Jabber id, page perso, ) le 08/03/2008 à 19:44. (lien). Évalué à 3.C'est toujours cool d'avoir des suggestions de rédacteurs en puissance, merci d'avance de vos dépêches à venir :-)
-
[^]Re: Dépêche
Posté par Christophe KINNE () le 14/03/2008 à 16:32. (lien). Évalué à 1.Mes news c'est une sorte de cycle naturel : y'en a deux par décennies comme les grosses tempêtes, on a passé le cap des 5 ans alors les probabilité d'en voir une débarquer augmentent fortement ;).
Plus sérieusement si j'ai quelque chose d'intéressant à dire, je le dis, sinon je me tais et je n'embête pas les gentils modérateurs de linuxfr avec des trucs qui ne méritent même pas un journal ;-).-
[^]Re: Dépêche
Posté par Christophe KINNE () le 14/03/2008 à 16:34. (lien). Évalué à 1.s/probabilité/probabilités.
<déconne>
Et l'édit sur lfr c'est pour quand ? Faut passer au waib 2.0 les gars ;)
Je sais j'envoie un patch...
</déconne>
-
-
-
-
-
-
[^]Re: Dépêche
Posté par albert (page perso, ) le 07/03/2008 à 17:49. (lien). Évalué à 3.perso, ce didactiel aurait à mon avis mieux eu sa place sur un site comme lea-linux.
vu le nombre de dépèches sur linuxfr, celui ci partira vite dans les oubliettes...
Allez y, vous pouvez me moinsser ;)
introduction ?
Je crois que c'est cette partie qui fait le plus cruellement défaut. Pour que cette news puisse être comprises par la majorité des lecteurs de Linuxfr, il me semble qu'il auait fallu passer au moins 3 voir peut-être dix lignes a expliquer l'objectif de la manoeuvre pour les ignorants du réseaux et autres paresseux de la sécurité qui se contente de quelques ALL:ALL dans leurs hosts.deny en guise de configuration.
Je ne prétend pas être un génie mais j'utilise Linux depuis environs 10 ans et pourtant je suis presque incapable de me figurer les tenants et aboutissants de ce tutotrial en lisant :
Dans ce qui va suivre, j'essaierai de vous présenter une technique que j'utilise pour accéder à mes serveurs via des points de montage sshfs (basé sur fuse) encapsulé dans des tunnels SSH.
En lisant les commentaires des autres jai l'impression d'être le seul ??? quelqu'un veux bien m'expliquer ?
PMA
-
[^]Re: introduction ?
Posté par benoar (Jabber id, ) le 07/03/2008 à 19:30. (lien). Évalué à 2.Oui effectivement, je trouve aussi que ca fait tres abrupt pour commencer, je me suis dit : "mais qu'est ce que ca fout la ?". Apres, pour l'histoire de la visibilité des news par rapport aux astuces, OK, mais une petite introduction n'aurait pas fait de mal ...
BTW : au lieu d'essayer de me rappeler a chaque dans quel fichier il faut rajouter ma clé publique, j'utilise ssh-copy-id, ce qui rend les choses beaucoup plus simple :
ssh-copy-id yannig@rebond
Et roule ma poule.
-
[^]Re: introduction ?
Posté par yannig (page perso, ) le 07/03/2008 à 19:41. (lien). Évalué à 1.Effectivement, j'aurai peut-être dû rajouter ça. Mais comme qui dirait, ce n'est pas trop mon fort. J'ai plutôt axé le tout la partie technique ce qui est effectivement un tort.
-
[^]Re: introduction ?
Posté par Anglade Pierre-Matthieu (page perso, ) le 09/03/2008 à 17:31. (lien). Évalué à 1.Mais il n'est jamais trop tard pour bien faire. Alors si le cœur t'en dit n'hésites plus !
--
PMA-
[^]Re: introduction ?
Posté par yannig (page perso, ) le 10/03/2008 à 09:12. (lien). Évalué à 1.Je pense que je vais reprendre toutes les petites remarques et je vais en aller proposer ça chez léa Linux :)
-
-
Astuces OpenSSH : le multiplexage
Bon, ça n'a pas grand chose à voir avec le contenu de la dépêche, mais puis qu'on parle d'astuces OpenSSH...
Depuis la version 4.2, OpenSSH est capable de réduire fortement le temps d'initialisation de la connexion (en éliminant le besoin de re-négociation des algos, ré-authentification, ...), car il permet de multiplexer les connexions vers un même hôte.
Les cas d'utilisations qui bénéficient typiquement de cette fonctionnalité sont ceux qui requiert des re-connexions régulières à une même machine, par exemple pour accéder à un serveur Subersion, ou CVS, ou un distcc, ou ceux qui ont l'habitude de se connecter pour lancer une seule commande à la fois (« ssh user@serveur commande »)...
Le principe est simple : on crée une connexion « maitre » initiale, celle-ci est maintenue en fond et sera réutilisée pour toutes les connexions suivantes vers le même hôte.
En pratique :
1) Placer ceci dans son ~/.ssh/config (ce fichier doit être en mode 0600) :
Host *
ControlPath ~/.ssh/mux_socket-%r@%h:%p
2) Ensuite, on crée une socket « maître » utilisée pour le multiplexage (cela crée aussi un processus ssh qui maintient cette socket, en arrière plan) vers monhotedistant:
ssh -fMN monhotedistant
Et voila ! On peut maintenant profiter de nouvelles connexions très rapides. Exemple chez moi :
# Avant la mise en place du multiplexage :
$ time ssh monserveur exit
real 0m0.530s
# Avec le multiplexage :
$ time ssh monserveur exit
real 0m0.018s
Autant dire que les opérations courantes (svn diff, log, up, ...) sur mon dépôt subversion sont beaucoup plus confortables.
Une autre astuce dont il faudrait parler : les dernières versions d'OpenSSH permettent de créer des VPN (utilisant des tunnels sur des interfaces virtuelles tun(4), à la façon d'OpenVPN) de façon très simple et ne nécessitant que OpenSSH. Je suis sûr que ça aurait pu être utilisé pour arriver à des résultats similaires à ce qui est présenté dans la dépêche, mais en n'utilisant qu'OpenSSH.



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.