Windows Dev Story: Git in WSL2 (richtig) konfigurieren

An unserem letzten Slackday – der hier bei uns in der Mayflower-Kultur Mayday genannt wird – haben wir zusammen mit den Kollegen unseren Firmen-Twitch-Channel erstellt. Und ich durfte als Erster streamen (juhu).

<werbung> Folgt uns gerne auf Twitch. Dort versuchen wir zumindest an jedem Mayday mindestens eine Session Live zu übertragen. </werbung>

Da mein mobiler Arbeitsplatz nicht stark genug war um das Video-Encoding korrekt hinzubekommen, musste ich schnell auf einen leistungsstarken PC umsteigen – und, nun ja … da lief Windows mit WSL2 drauf. Spätestens ab hier wird es spannend.

Git in WSL2

Denn alleine schon Git richtig zu konfigurieren, kann in einem WSL2-Setup mit einer oder mehreren Maschinen zur Challenge werden. Vor allem, weil das Internet bei Problemen in dem Kontext auch nur sehr beschränkt weiterhilft.

Bevor wir loslegen ist es glaube ich wichtig anzumerken, dass man Git auf zwei Arten verwenden kann:

• Basic Auth (https://github.com/<user>/<project>.git)
• SSH Key (git@github.com:<user>/<project>.git)

Wer jetzt viel auf und mit Unix-Systemen gearbeitet hat, der hat vielleicht vergessen, dass es eben auch die Basic-Auth-Methode gibt. Zumindest ging es mir so; darum hat es auch sehr lange gedauert, das Folgende aufzusetzen.

Option 1: Git Credential Manager

Der Git Credential Manager (GCM) ist – einfach gesagt – ein Cross-Plattform-Interface zwischen den OAuth2 Authorization-Flows diverser großer Git-Hoster (Github, Gitlab, Bitbucket, …) und den System-spezifischen Secret Stores (Windows Credential Manager unter Windows und die login keychain unter macOS).

Und ja, damit unterstützt er eben auch Basic Auth über HTTPS.

Ach ja, habe ich schon erwähnt, dass er sich 1A mit unseren WSL-Systemen verheiraten lässt?

Nachdem Git auf dem Windows-Host installiert wurde, können wir unser WSL jetzt so konfigurieren, dass es den GCM vom Windows-Host-System nutzt:

# In unserer PowerShell
wsl

# Oder um in die nicht default WSL zu gelangen
wsl -d Ubuntu

# Ab hier befinden wir uns in der WSL VM
# Nun nur noch Git installieren, unter Ubuntu z.B.:
apt-get install git
# Fuer alle anderen Linux Distributionen einfach in der Git Doku nachschlagen (https://git-scm.com/download/linux)

# Minimal Git Konfig
git config --global user.name "Max Mustermann"
git config --global user.email "max.mustermann@example.com"
    
# Und jetzt kommt der WICHTIGE Teil
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-manager-core.exe"

Der letzte Befehl in dem Beispiel macht die ganze Magie: nun kann man einfach ganz normal mit git arbeiten. Bei der ersten Verbindung geht ein Browserfenster auf, in dem man sich einloggen kann.

Und ja, das funktioniert sogar ohne jegliche weitere Konfiguration auch innerhalb von Visual Studio Code Remote Containers, solange Docker mit dem WSL2-Backend läuft.

Option 2: SSK-Key

Gerade der Ansatz der auf allen meinen anderen Dev-Host-Systemen der Gängige ist, enttarnt sich unter Windows als die komplexere Option. Aber warum ist das so?

SSH-Keys sind eigentlich nicht dafür da, geteilt zu werden. Und da jeder einzelne WSL2-Host ein eigenes, vollständig virtuelles Linux ist, müssten wir dafür theoretisch auf jedem auch eigene SSH-Keys generieren, die wir dann anschliessend bei dem Git-Hoster unserer Wahl hinterlegen können.

Das kann man schon so machen. Ich kann aber auch verstehen, wenn man nur ein Key Pair haben möchte – und zwar das vom Windows-Host.

Ich will hier gar nicht im Detail beschreiben wie das geht; hierzu gibt es nämlich – im Gegenteil zum Git Credential Manager – sehr schöne Blog-Posts, die zeigen, wie man das machen kann.

Zum Beispiel erklärt der Blog-Post Sharing SSH keys between Windows and WSL 2 von Burke Holland, wie man SSH-Keys vom Host-System in seine jeweiligen WSL2-Systeme kopieren kann.

Während der Blog-Post Forwarding SSH Agent requests from WSL to Windows von Stuart Leeks super erklärt, wie man SSH Agent requests von einem WSL auf den Windows-Host weiterleiten kann. Im Gegensatz zum vorherigen Ansatz müssen wir dafür nicht den SSH-Key in das WSL-System kopieren.

Und zum Abschluss gibt es noch ein kleines Caveat für alle, die mit Visual Studio Code, WSL2 und Remote-Containern Probleme haben.

VSC in Kombination mit der Remote-Containers-Extension

Um Git auch innerhalb des Dev-Containers verwenden zu können, muss sichergestellt sein, dass der SSH-Key vom Windows-Host im VSC-Backend hinterlegt ist (auch wenn VS Code mit code <project-dir> von innerhalb einer WSL2-Instanz gestartet wurde):

# Standardmaessig ist der ssh-agent-Service deaktiviert. Mit folgendem Kommando erlauben wir das manuelle starten des Services.
# Stelle sicher, dass Du die PowerShell als Administrator ausgefuehrt hast.
Get-Service ssh-agent | Set-Service -StartupType Manual

# Starte den Service
Start-Service ssh-agent

# Sollte den Status "Running" zurueckgeben
Get-Service ssh-agent

# Jetzt lade deine SSH-Key-Dateien in den ssh-agent
ssh-add ~\.ssh\id_ed25519

Zum Schluss noch ein Pro-Tipp: Um den ssh-agent nicht nach jedem Windows-Neustart manuell starten zu müssen, empfiehlt sich folgender Befehl:

Get-Service ssh-agent | Set-Service -StartupType Automatic

Quellen

• GCM: Git Credential Manager: authentication for everyone
• GCM: Git Credential Manager
• GCM WSL: WSL-Doc
• GCM: Use Git Credential Manager to authenticate to Azure Repos
• Remote Containers: Git: SSH error Permission denied in WSL2 + Remote Containers
• OpenSSH Windows: OpenSSH key management
• WSL2 Docker: Docker Desktop WSL 2 backend
• WSL Git: Get started using Git on Windows Subsystem for Linux