Abhängig von Ihren Anforderungen, insbesondere Ihren Sicherheitsanforderungen, gibt es einige Optionen. Sowohl für HTTP als auch für SSH gibt es einen passwortlosen oder passwortgeschützten Zugriff.
HTTP
==============
Passwortlos
Nützlich für Nur-Fetch-Anforderungen, Push ist standardmäßig deaktiviert. Perfekt, wenn anonymes Klonen beabsichtigt ist. Sie sollten Push auf keinen Fall für diese Art von Konfiguration aktivieren. Die Manpage für git-http-backend enthält gute Informationen, Online-Kopie unter http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html. Es enthält ein Beispiel dafür, wie Apache konfiguriert wird, um dies bereitzustellen.
Benutzer/Passwort in .netrc oder URL eingebettet
Wobei .netrc-Dateien in der Form verwendet werden:
machine <hostname> login <username> password <password>
Und eingebettete URLs hätten die Form:
http://user:[email protected]/repo
Da Git keine Authentifizierung für Sie durchführt, müssen Sie einen Webserver wie Apache konfigurieren, um die Authentifizierung durchzuführen, bevor Sie die Anfrage an die Git-Tools weiterleiten. Denken Sie auch daran, dass die Verwendung der eingebetteten Methode ein Sicherheitsrisiko darstellt, selbst wenn Sie https verwenden, da es Teil der angeforderten URL ist.
Wenn Sie in der Lage sein möchten, nicht interaktiv zu pullen, aber anonyme Benutzer am Zugriff auf das Git-Repository hindern möchten, sollte dies eine einigermaßen leichte Lösung sein, die Apache für die grundlegende Authentifizierung und vorzugsweise die .netrc-Datei zum Speichern von Anmeldeinformationen verwendet. Als kleinen Fallstrick aktiviert git den Schreibzugriff, sobald die Authentifizierung verwendet wird. Verwenden Sie also entweder anonymes http für schreibgeschützten Zugriff, oder Sie müssen einige zusätzliche Konfigurationen vornehmen, wenn Sie verhindern möchten, dass der nicht interaktive Benutzer Schreibzugriff hat .
Siehe:
- httpd.apache.org/docs/2.4/mod/mod_auth_basic.html für weitere Informationen zur Konfiguration der grundlegenden Authentifizierung
- www.kernel.org/pub/software/scm/git/docs/git-http-backend.html für einige Beispiele zur benötigten Apache-Konfiguration.
SSH
==============
Passwortlos
Öffnet sich für Sicherheitsprobleme, da jeder, der den privaten ssh-Schlüssel erhalten kann, jetzt das Remote-Git-Repo als dieser Benutzer aktualisieren kann. Wenn Sie dies nicht interaktiv verwenden möchten, würde ich empfehlen, etwas wie gitolite zu installieren, um es ein wenig einfacher zu machen, sicherzustellen, dass diejenigen mit dem privaten ssh-Schlüssel nur aus dem Repo ziehen können, und es erfordert ein anderes ssh-Schlüsselpaar zum Aktualisieren das Repo.
Weitere Informationen zu gitolite finden Sie unter github.com/sitaramc/gitolite/.
stromberg.dnsalias.org/~strombrg/ssh-keys.html - zum Erstellen passwortloser SSH-Schlüssel:Vielleicht möchten Sie auch die Verwaltung mehrerer SSH-Schlüssel behandeln:www.kelvinwong.ca/2011/03/30/multiple-ssh-private- Schlüsselidentitätsdatei/
Passphase geschützt
Kann ssh-agent zum Entsperren pro Sitzung verwenden, nur wirklich nützlich für interaktives Abrufen von Git. Da Sie root erwähnen und nur über die Ausführung von „Git Pull“ sprechen, klingt es so, als wäre Ihr Anwendungsfall nicht interaktiv. Dies ist etwas, das besser mit Gitolite kombiniert werden könnte (github.com/sitaramc/gitolite/).
Zusammenfassung
==============
Die Verwendung von etwas wie gitolite wird einen Großteil der Konfiguration für SSH-Setups abstrahieren und wird definitiv empfohlen, wenn Sie glauben, dass Sie möglicherweise zusätzliche Repositories haben oder unterschiedliche Zugriffsebenen angeben müssen. Die Protokollierung und Prüfung sind ebenfalls sehr nützlich.
Wenn Sie nur in der Lage sein wollen, über http zu pullen, sollte die git-http-backend-Manpage genügend Informationen enthalten, um Apache so zu konfigurieren, dass er das Notwendige tut.
Sie können jederzeit anonyme http(s) für Klonen/Pull kombinieren, mit passphrasengeschütztem ssh-Zugriff, der für vollen Zugriff erforderlich ist. In diesem Fall müssen Sie gitolite nicht einrichten, Sie fügen einfach den öffentlichen ssh-Schlüssel zu ~/ hinzu. ssh/authorized_keys-Datei.
Siehe die Antwort auf diese Frage. Sie sollten den SSH-Zugang anstelle von HTTPS/GIT verwenden und sich über Ihren öffentlichen SSH-Schlüssel authentifizieren. Dies sollte auch lokal funktionieren.