Forum général.général SSH et enregistrements DNS SRV

Posté par  .
Étiquettes :
3
7
jan.
2012

Salut,

Lorsque l'on veut mettre en place un gestionnaire de code source (SCM), celui-ci est le plus souvent accompagné d'un accès par le Web en HTTP. Si l'on prend le cas de Git, ceci implique donc d'installer sur un même serveur Git, OpenSSH, Gitolite, un serveur Web, ... Si l'on possède déjà un serveur Web, on serait tenter d'installer le tout sur ce dernier.

Les pricinpes de sécurité veulent que l'on installe qu'un type de service par serveur. De plus, installer SSH (peu importe les méthodes de sécurisation) peut fournir un acces non voulu au système. Ne parlons même pas des "hooks" qui permettent de faire un peu tout ce que l'on veut sur le serveur.

L'idée serait donc de dissocier la partie Web de la partie SSH. Pour cela, les enregistrements DNS SRV conviennent parfaitement à ce cas :

_ssh._tcp.git.example.com. 3600 IN SRV 0 5 22 ssh.example.com.
_http._tcp.git.example.com. 3600 IN SRV 0 5 80 www.example.com.
_https._tcp.git.example.com. 3600 IN SRV 0 5 443 www.example.com.

Et hop, parfait, on a dissocié les deux services. Malheureusement, il semblerait que OpenSSH ne fasse pas de requête pour les champs SRV... :(

Ma question, s'il y en a une, serait alors : comment séparer les deux services ? Patcher OpenSSH ? Ne rien séparer du tout ? La réponse "D" ?

  • # j'ai pas tout compris

    Posté par  . Évalué à 2.

    git comme d'autres peut utiliser differents protocoles pour lire/ecrire sur ton depot.

    git http://example.com/path/projet.git se basera donc sur http avec la securité qui va avec.

    si ca ne te plait, pas, tu peux ne pas mettre de service web, et faire alors du git au travers de SSH

    coté serveur tu peux parfaitement limiter les commandes qui seront executés
    tu dois meme pouvoir chrooter un utilisateur

    donc soit j'ai pas compris ton probleme, soit tu te poses trop de questions.

    ;)

    • [^] # Re: j'ai pas tout compris

      Posté par  . Évalué à 2.

      En effet on peut utiliser plusieurs protocoles. L'idée est d'utiliser SSH pour interagir avec le dépôt et de fournir une interface Web pour parcourir ce dernier en ligne. Du coup il s'agit de deux services différents (sauf si on voit le tout comme étant un service "SCM").

      Si je souhaite n'utiliser qu'un nom de domaine comme git.example.com, la machine doit fournir les deux services à savoir serveur Web (visualisation) et SSH (push). J'aimerais pouvoir dissocier le serveur Web du dépôt et ainsi, je pourrais appliquer différentes politiques en fonction du service sans avoir à faire de concessions pour l'un ou l'autre.

      D'un côté, le serveur de dépôt avec SSH et accès en écriture, si accès malveillant il y a, ben... le dépôt est foutu. De l'autre le serveur Web (qui dessert aussi d'autres sites) avec accès en lecture uniquement sur le dépôt, si accès malveillant il y a, on peut sauver le dépôt.

      • [^] # Re: j'ai pas tout compris

        Posté par  . Évalué à 2.

        c'est trop compliqué d'avoir
        git.example.com pour ton serveur GIT qui gere plusieurs depots.

        et
        projetA.example.com pour l'interface web du projetA
        projetB.example.com pour l'interface web du projetB

        • [^] # Re: j'ai pas tout compris

          Posté par  . Évalué à 2.

          Ce type de configuration, je le verrais plutôt pour les sites dédiés aux projets. Ce que je veux c'est plus une interface cgit avec tous les dépôts listés (http://git.kernel.org/).

          Dans le cas de kernel.org, tous les services sont sur le même serveur. Et je pense qu'en l'état actuel, c'est la seule solution. Je trouve dommage que l'on ne puisse pas séparer les deux...

          • [^] # Re: j'ai pas tout compris

            Posté par  . Évalué à 2.

            redmine te permet d'avoir un serveur web, qui va ensuite interroger un depot distant en git pure.

            tu peux alors avoir 2 serveurs physiques distincts

Suivre le flux des commentaires

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