git - credential cache

Obwohl es im allgemeinen üblicher ist entfernte git - Repositories über SSH und damit über das SSH Private/Public-Key Verfahren, kommt es immer wieder vor, dass Repositories nur über das https Protokoll verfügbar sind.

Bei öffentlichen Repositories - ohne Zugangsdaten - ist dies ein Vorteil, da sie ohne eine notwendige Installation von SSH-Keys direkt - anonym - genutzt werden kann.

Für private Repositories wird es dann allerdings problematisch. Die Zugangsdaten müssen entweder bei jedem Aufruf eines git pull oder git push erneut eingegeben oder über die Konfiguration gespeichert werden.

user@linux $ git clone https://git.example.com/test.git
Klone nach 'test'...
Username for 'https://git.example.com': test
Password for 'https://test@git.example.com': 
remote: Enumerating objects: 309, done.
remote: Counting objects: 100% (234/234), done.
remote: Compressing objects: 100% (152/152), done.
remote: Total 309 (delta 112), reused 190 (delta 77), pack-reused 75
Empfange Objekte: 100% (309/309), 117.68 KiB | 3.46 MiB/s, fertig.
Löse Unterschiede auf: 100% (137/137), fertig.

user@linux $ git clone https://test:test@git.example.com/test.git
Klone nach 'test'...
remote: Enumerating objects: 309, done.
remote: Counting objects: 100% (234/234), done.
remote: Compressing objects: 100% (152/152), done.
remote: Total 309 (delta 112), reused 190 (delta 77), pack-reused 75
Empfange Objekte: 100% (309/309), 117.68 KiB | 3.46 MiB/s, fertig.
Löse Unterschiede auf: 100% (137/137), fertig.

So einfach und sicher der zweite Fall scheint, so unsicher ist er. Damit die Benutzerdaten bei der Anmeldung angegeben werden können, werden sie im Klartext abgespeichert. Damit sind sie für jeden, der Zugriff auf die lokale Kopie des git - Repositories hat direkt einsehbar.

user@linux $ cd test
user@linux $ git config --get remote.origin.url
https://test:test@git.example.com/test.git

Eigentlich wäre ein Zwischenmodus zwischen Eingabe und Speicherung der Zugangsdaten wünschenswert. Hier kommt der git credential cache ins Spiel.

Seine Aufgabe ist es als Dienst im Hintergrund zu laufen, vom git beim ersten Zugriff auf das Repository die Zugangsdaten abzufragen und sie für eine voreinstellbare Zeit zu speichern. Sobald innerhalb der Speicherzeit der git die Zugangsdaten erneut benötigt, stellt er sie zur Verfügung.

Wurden die Daten durch den Timeout vergessen, fragt git sie erneut an und speichert sie dann wieder.

Die Einrichtung ist recht simpel und nur ein Eintrag in der Konfiguration des git.

user@linux $ git config credential.helper 'cache --timeout=3600'

Durch diese Konfiguration startet git - wenn benötigt - den credential-cache-daemon im Hintergrund.

Um die Zwischenspeicherung zu von Zugangsdaten zu beenden kann der Daemon jederzeit beendet werden. Damit werden die zwischengespeicherten Zugangsdaten automatisch vergessen und müssen bei Zugriffen auf das Repository erneut eingegeben werden. Da hierfür ein neuer credential-cache-daemon gestartet wird.

user@linux $ git credential-cache exit

Die Nutzung des git credential cache ist deutlich sicherer als das Speichern der Zugangsdaten in der git Konfiguration. Zudem ist es komfortabler als die Zugangsdaten jedes Mal per einzugeben.

Allerdings gibt es auch bei dieser Methode eine Gefahr. Der git Befehl kommuniziert mit dem Daemon über einen Unix-Socket. Dies ist eine Datei vom Typ Socket über die mit einem Programm kommuniziert werden kann.

Im Gegensatz zum Zugriff per IP Adresse und Port gibt es hier keine Möglichkeit den Zugriff über eine Firewall - Regel zu begrenzen. Allein durch die Zugriffs- und Besitzrechte auf die Datei wird festgelegt wer mit dem Daemon kommunizieren darf.

Daher sollte man bei Benutzung des credential-cache-daemon sicherstellen, dass keine anderen Benutzer auf dem gleichen Rechner eine Zugriffsmöglichkeit auf die Datei (den Socket) hat und damit die zwischengespeicherten Zugangsdaten auslesen kann.

Kann man dies nicht sicherstellen, sollte der Daemon nicht genutzt und die Zugangsdaten jedes Mal eingegeben werden. Alternativ wäre zu prüfen ob nicht auf SSH mit Keys umgestellt werden kann.