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 miroirCela 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 nono14 (site web personnel) . Évalué à 1.
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 - Ouvert à de nouvelles opportunités
[^] # Re: ssh / chroot / force_command
Posté par leviathan (site web personnel) . Évalué à 2.
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 NeoX . Évalué à 3.
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 NeoX . Évalué à 2.
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 leviathan (site web personnel) . Évalué à 1.
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 NeoX . Évalué à 2.
(cf reponse premiere)
# et pourquoi ssh ?
Posté par PLuG . Évalué à 2.
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 leviathan (site web personnel) . Évalué à 1.
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 leviathan (site web personnel) . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.