Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Liens connexes

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.
Sécurité
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.

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.

> Lire la dépêche (18 commentaires, moyenne: 3,6).  

Installation

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 :
Si vous choisissez aptitude pour faire votre installation, vous procéderez comme suit :

sudo aptitude install fuse tsocks afuse

L'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 yannig

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.

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-desktop


2/ 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 :
L'idée est donc de réutiliser tout le temps la même connexion pour faire transiter vos connexions vers la DMZ. Pour se faire nous allons utiliser les tunnels SSH et notamment, l'attribution des connexions dynamiques (option -D).

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: 8888


2 possibilités s'offrent à vous :
Remarque : par la suite, je ne parlerai plus de port dynamique mais de serveur SOCKS.

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 = 8888


Il 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.a


Et 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 :
Nous allons maintenant nous attacher à monter les partitions automatiquement à l'aide de afuse.

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" ~/sshfs


A 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-dmz1


Vous 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 !

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.

ProxyCommand

Posté par ribwund () le 07/03/2008 à 00:20. (lien). Évalué à 6.

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)

Dépêche

Posté par FAbrice M () le 07/03/2008 à 15:06. (lien). Évalué à 10.

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

introduction ?

Posté par Anglade Pierre-Matthieu (page perso, ) le 07/03/2008 à 18:05. (lien). Évalué à 4.

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

Astuces OpenSSH : le multiplexage

Posté par herodiade () le 08/03/2008 à 11:31. (lien). Évalué à 7.

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.

Revenir en haut de page