Il existe quelques options, en fonction de vos besoins, en particulier de vos besoins en matière de sécurité. Pour HTTP et SSH, il existe un accès sans mot de passe ou un accès avec mot de passe.
HTTP
==============
Sans mot de passe
Utile pour les exigences de récupération uniquement, par défaut, le push est désactivé. Parfait si le clonage anonyme est l'intention. Vous ne devriez certainement pas activer le push pour ce type de configuration. La page de manuel de git-http-backend contient de bonnes informations, une copie en ligne sur http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html. Il fournit un exemple de configuration d'Apache pour fournir cela.
Utilisateur/mot de passe dans .netrc ou URL intégrée
Où les fichiers .netrc sont utilisés sous la forme :
machine <hostname> login <username> password <password>
Et les URL intégrées seraient sous la forme :
http://user:[email protected]/repo
Étant donné que git ne fera pas l'authentification pour vous, vous devrez configurer un serveur Web tel qu'Apache pour effectuer l'authentification, avant de transmettre la demande aux outils git. N'oubliez pas non plus que l'utilisation de la méthode intégrée présente un risque pour la sécurité, même si vous utilisez https, car il fait partie de l'URL demandée.
Si vous souhaitez pouvoir extraire des informations non interactives, mais empêcher les utilisateurs anonymes d'accéder au référentiel git, cela devrait être une solution raisonnablement légère utilisant apache pour l'authentification de base et de préférence le fichier .netrc pour stocker les informations d'identification. En tant que petit piège, git activera l'accès en écriture une fois l'authentification utilisée, utilisez donc soit le http anonyme pour la lecture seule, soit vous devrez effectuer une configuration supplémentaire si vous souhaitez empêcher l'utilisateur non interactif d'avoir accès en écriture. .
Voir :
- httpd.apache.org/docs/2.4/mod/mod_auth_basic.html pour en savoir plus sur la configuration de l'authentification de base
- www.kernel.org/pub/software/scm/git/docs/git-http-backend.html pour quelques exemples sur la configuration apache nécessaire.
SSH
==============
Sans phrase de passe
S'ouvre pour des problèmes de sécurité, puisque toute personne pouvant obtenir la clé privée ssh peut désormais mettre à jour le référentiel git distant en tant qu'utilisateur. Si vous souhaitez l'utiliser de manière non interactive, je vous recommande d'installer quelque chose comme gitolite pour faciliter un peu la tâche de s'assurer que ceux qui ont la clé privée ssh ne peuvent tirer que du référentiel, et cela nécessite une paire de clés ssh différente pour mettre à jour le dépôt.
Voir github.com/sitaramc/gitolite/ pour en savoir plus sur gitolite.
stromberg.dnsalias.org/~strombrg/ssh-keys.html - pour créer des clés ssh sans mot de passe :peut également couvrir la gestion de plusieurs clés ssh :www.kelvinwong.ca/2011/03/30/multiple-ssh-private- clés-identityfile/
Passphase protégé
Peut utiliser ssh-agent pour déverrouiller session par session, uniquement très utile pour la récupération interactive à partir de git. Puisque vous mentionnez root et ne parlez que de l'exécution de 'git pull', il semble que votre cas d'utilisation ne soit pas interactif. C'est quelque chose qui pourrait être mieux combiné avec gitolite (github.com/sitaramc/gitolite/).
Résumé
==============
L'utilisation de quelque chose comme gitolite supprimera une grande partie de la configuration pour les configurations de type SSH, et est certainement recommandée si vous pensez avoir des référentiels supplémentaires ou si vous devez spécifier différents niveaux d'accès. Sa journalisation et son audit sont également très utiles.
Si vous voulez juste pouvoir tirer via http, la page de manuel git-http-backend devrait contenir suffisamment d'informations pour configurer apache pour faire le nécessaire.
Vous pouvez toujours combiner des http(s) anonymes pour clone/pull, avec un accès ssh protégé par une phrase de passe requis pour un accès complet, auquel cas il n'est pas nécessaire de configurer gitolite, vous ajouterez simplement la clé publique ssh au fichier ~/. fichier ssh/authorized_keys.
Voir la réponse à cette question. Vous devez utiliser l'accès SSH au lieu de HTTPS/GIT et vous authentifier via votre clé publique SSH. Cela devrait également fonctionner localement.