Forum Linux.général Sécurité d'un rsync via ssh

Posté par (page perso) .
Tags : aucun
1
23
oct.
2009
Bonjour à tous,

dans le cadre de la mise en place de miroir pour le téléchargement, je souhaite mettre en place un système basé sur rsync afin de les miroirs soient automatiquement mis à jour.

Pour cela, sur mon serveur principal, j'ai créé un utilisateur et un groupe (miroir) ayant pour répertoire personnel /home/miroir

Dans ce répertoire, je créer un répertoire .ssh dans lequel je place le fichier "authorized_keys" contenant les clés publiques des miroirs autorisés à ce connecter en restreignant la connexion ssh à une IP par clé et à l'exécution d'une seule commande (rsync)

Je crée ensuite un fichier de configuration pour rsync comme ceci :

log file = /var/log/rsyncd.log
uid = miroir
gid = miroir
use chroot = no

[fs_miroir]
path = /home/miroir/base
list = yes
read only = yes


Ensuite les miroirs exécute via cron la commande suivante :
rsync -e "ssh -i ${PRIVATE_KEY}" --force --delete -av miroir@${MAIN_SERVER}::fs_miroir miroir

Cela fonctionne correctement. Mais, je me demande si avec cette configuration, les miroirs ne pourrait pas récupérer d'autres fichiers que ceux présents dans le répertoire "/home/miroir/base"

En effet, si je fait un :
rsync -e "ssh -i ${PRIVATE_KEY}" --force --delete -av miroir@${MAIN_SERVER}:/home/miroir/.ssh/authorized_keys .
Je vais pouvoir le récupérer (ce qui n'est pas vraiment embêtant pour ce fichier). J'ai testé en essayant de récupérer des fichiers situé dans d'autres répertoires, je n'ai pas réussi. Mais je suis peut-être tombé que sur des cas spécifiques et peut-être que certains fichiers en dehors du répertoire base sont tout de même récupérable ?

Est-ce que cette solution est sécurisée ou il y a un défaut quelque part ?
  • # ssh / chroot / force_command

    Posté par (page perso) . Évalué à 1.

    Si la commande suivante fonctionne:

    rsync -e "ssh -i ${PRIVATE_KEY}" --force --delete -av miroir@${MAIN_SERVER}:/

    En fait, tous les fichiers lisibles sur l'hôte distant sont copiables...

    Une solution parmi d'autre:
    -chrooter ssh

    ou l'option command="command" du fichier authorized_keys qui permet de lancer uniquement cette commande. Avec cette methode tu copies du maitre vers les "cibles".

    Système - Réseau - Sécurité Open Source

    • [^] # Re: ssh / chroot / force_command

      Posté par (page perso) . Évalué à 2.

      Le chroot ssh me semble la meilleure idée. Je vais regarder de ce côté.

      Pour la copie du maître vers les miroirs, cela demande plus de travail du côté des miroirs et je ne suis pas forcément pour.

      Merci beaucoup pour l'astuce.
      • [^] # Re: ssh / chroot / force_command

        Posté par . Évalué à 3.

        pour le chroot ssh,

        au debut de l'année il fallait recompiler openssh pour lui ajouter la capacité de faire un chroot

        qui se faisait simplement en mettant un ./ dans le chemin du home de l'utilisateur
        ex : /home/./user


        depuis la fonction de chroot a du etre activé par defaut dans les nouvelles versions de ssh
  • # l'inverse ?

    Posté par . Évalué à 2.

    pourquoi ne pas pousser du serveur maitre sur les mirroirs ?

    1°) comme ca tu pousses quand tu sais que le depot maitre est "sain" avant de pousser vers le mirroir

    2°) tu sais ce qui est poussé
    • [^] # Re: l'inverse ?

      Posté par (page perso) . Évalué à 1.

      Effectivement, cela serait une solution. Mais comme les miroirs sont de gentils bénévoles, il faudrait en plus de faire miroir qu'ils veuillent nous ouvrir un accès ssh et/ou rsync en écriture.

      Cela me semble beaucoup leur demander alors qu'avec la solution proposée, il n'ont qu'un script à mettre en cron et pas de configuration à faire sur leur serveur.
      • [^] # Re: l'inverse ?

        Posté par . Évalué à 2.

        il reste alors le chroot ssh

        (cf reponse premiere)
  • # et pourquoi ssh ?

    Posté par . Évalué à 2.

    avec rsync tu peux filtrer quelles @ip ont acces à quels partage rsync et rsync supporte le chroot tout seul (tu as d'ailleurs mis chroot=no).

    pourquoi veut tu authentifier tes mirroirs avec une clef ssh + leur @ip ?
    si leur serveur est compromis, tes fichiers y sont déjà (c'est un mirroir), et la clef privée ssh certainement sans passphrase (pour marcher en cron) est déjà sur le serveur ...

    peut-etre que tu complique juste le problème, tu peux configurer rsync pour qu'il soit lancé par xinetd, et gerer les accès dans /etc/rsyncd.conf, même plus besoin de créer un user par site mirroir sur ton système ...
    • [^] # Re: et pourquoi ssh ?

      Posté par (page perso) . Évalué à 1.

      Oui, je sais que je peux utiliser rsync sans ssh, mais comme le port ssh est de tout façon ouvert, je préfère ne pas ouvrir un port de plus (pour rsync) sur le serveur et passer par ssh.

      Ainsi rsync n'écoute que la boucle locale et n'a pas d'accès vers l'extérieur. Mais de cette façon, j'ai l'impression que l'on ne peut pas configurer le chroot de rsync (à moins que j'ai mal cherché).

      Enfin, je ne crée qu'un seul user (et pas un par miroir) mais cet utilisateur peut s'identifier avec plusieurs clé ssh.
  • # Solution retenue

    Posté par (page perso) . Évalué à 1.

    tout d'abord merci à tous pour vos propositions.

    Vu que ma version d'OpenSSH ne supportait pas le chroot en natif et que j'avais moyennement envie d'installer une nouvelle version majeure, j'ai trouvé une autre solution.

    Il s'agit de modifier le seul script autorisé a être exécuté par mon utilisateur miroir (via le fichier "authorized_keys")

    Voici mon script :

    #!/bin/bash

    case "$SSH_ORIGINAL_COMMAND" in
    *\&*)
    echo "Rejected"
    ;;
    *\(*)
    echo "Rejected"
    ;;
    *\{*)
    echo "Rejected"
    ;;
    *\;*)
    echo "Rejected"
    ;;
    *\<*)
    echo "Rejected"
    ;;
    *\`*)
    echo "Rejected"
    ;;
    *\|*)
    echo "Rejected"
    ;;
    *\/*)
    echo "Rejected"
    ;;
    rsync\ --server*)
    $SSH_ORIGINAL_COMMAND
    ;;
    *)
    echo "Rejected"
    ;;
    esac


    L'ajout du cas "/" permet de bloquer l'utilisateur aux seuls modules définis dans le fichier rsyncd.conf et d'empêcher les miroirs de mettre un path.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.