Mise en place d'un serveur de rebond pour ses connections SSH

From Deimos.fr / Bloc Notes Informatique
Jump to: navigation, search

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

  • sshfs
  • tsocks
  • afuse

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 deimos) doit bien appartenir au groupe fuse :

[email protected]:~$ id -a
uid=1000(deimos) gid=1000(deimos) groups=4(adm),20(dialout),...106(fuse),108(lpadmin),...1000(deimos)

Si ce n'est pas le cas, vous pouvez rajouter l'utilisateur avec la commande suivante :

[email protected]:~$ sudo usermod -G fuse deimos

ou

[email protected]:~$ adduser deimos fuse

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. Sinon vous pouvez utiliser cette commande si vous ne souhaitez pas vous délogger :

newgrp fuse

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

2.1 Génération de la clé

[email protected]:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/deimos/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/deimos/.ssh/id_dsa.
Your public key has been saved in /home/deimos/.ssh/id_dsa.pub.
The key fingerprint is:
a9:xx:7d:xx:d9:xx:ea:xx:bd:xx:66:xx:98:xx:47:xx [email protected]

2.2 Dépôt de la clé sur le serveur de rebond

[email protected]:~$ cat .ssh/id_dsa.pub | ssh [email protected] "cat >> /home/deimos/.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.
[email protected]'s password:

Sinon sur Debian, vous pouvez utiliser cette commande :

ssh-copy-id [email protected]

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 :

[email protected]:~$ ssh [email protected]
Last login: Wed Mar 5 09:21:35 2008 from xx.xx.xx.xx
Authorized uses only. All activity may be monitored and reported.
[email protected]#

3 Création d'un point de montage sshfs

[email protected]:~$ mkdir test
[email protected]:~$ sshfs [email protected]:/tmp test
[email protected]:~$ ls test
croxxLa crxxLa getxxxt psxxta
crouxxiLa get_xxp lxxe
croxxiLa gexxxt PPCxx303

Ça à l'air de fonctionner !

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

[email protected]:~$ ssh -o ConnectTimeout=2 [email protected]
ssh: connect to host host-dmz1 port 22: Connection timed out

Impossible de se connecter directement sur le serveur host-dmz1

[email protected]:~$ ssh [email protected]
Last login: Wed Mar 5 09:45:36 2008 from 10.251.100.134
[email protected]#ssh [email protected]
[email protected]'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.

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

[email protected]:~$ ssh -D 8888 [email protected]
Could not request local forwarding.
Last login: Wed Mar 5 09:48:38 2008 from 10.251.100.134
[email protected]#

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 :

  • vous avez déjà une connexion ouverte avec un tunnel
  • vous avez un programme en local qui fait appel au port 8888 => Changez en !

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 :

[email protected]:~$ 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 :

[email protected]:~$ LD_PRELOAD=/usr/lib/libtsocks.so ssh [email protected]st-dmz1
[email protected]'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 :

[email protected]:~$ LD_PRELOAD=/usr/lib/libtsocks.so sshfs [email protected]:/usr/local/lib test
[email protected]:~$ 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 !

5 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.

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 [email protected]%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 :

[email protected]:~$ cd sshfs/
[email protected]:~/sshfs$ ls
[email protected]:~/sshfs$ cd host-dmz1
[email protected]:~/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
[email protected]:~/sshfs/host-dmz1$ cd ..
[email protected]:~/sshfs$ ls
host-dmz1
[email protected]:~/sshfs$ cd recette-dmz1
[email protected]:~/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
[email protected]:~/sshfs/recette-dmz1$ cd ..
[email protected]:~/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 !

6 Ressources

http://linuxfr.org/2008/03/07/23807.html
http://ensl.free.fr/softrez/faq/faq-9.html#ss9.1