How-To: Nahtlos mit git, SSH und Podman Desktop in WSL2 entwickeln

Sei es um als Windows-Nutzer eine einheitlichere Entwicklungsumgebung und Kompatibilität im Team mit MacOS und Linux Nutzern zu erreichen, man allgemein eine nähere Verwandschaft mit seiner Zielumgebung wünscht, oder Linux-exklusive Werkzeuge wie Claude Code, einem KI-Programmierassistenten, ausführen will.
Es gibt viele Gründe zu eine Unix-ähnlichere Umgebung zu adaptieren.

Nativ läuft das Setup mit git und SSH schon ganz gut und die SSH-Keys werden automatisch vom Passwortmanager zum SSH-Agent hinzugefügt oder entfernt. Und für Aufgaben mit Docker genügt die Podman Desktop-Installation.
Allerdings sind diese Werkzeuge nicht direkt in WSL verfügbar.
Die Schlüssel im SSH-Agenten bleiben nicht persistent über mehrere Sitzungen und die Passwörter müssen bei jedem Start einer Sitzung neu eingegeben werden, wenn man sie über das Shell-Profil hinzufügt. Eine Verknüpfung mit dem Passwortmanager ist auch nicht ohne weiteres möglich, da die WSL-Umgebung für diesen nicht sichtbar ist.
Wenn man Docker in WSL installiert, müssen bereits bei Podman unter Windows vorhandenen Images erneut heruntergeladen werden und die Container etc. werden dupliziert.
Das ist nicht unbedingt eine wünschenswerte Situation.

Den Windows-SSH-Agenten in WSL benutzen

Da in Windows schon alles vorhanden und eingerichtet ist, können wir auch das benutzen.

WSL fügt dem $PATH .exe Dateien aus dem Windows PATH hinzu und macht diese ausführbar. Die exe-Versionen nutzen automatisch die in Windows laufenden Dienste und Konfigurationen.

1$ ssh -T git@gitlab.com
2
3> git@gitlab.com: Permission denied (publickey).
4
5$ ssh.exe -T git@gitlab.com
6
7> Welcome to Gitlab, @username!

Hier können wir also einfach Aliase für SSH erstellen:

1alias ssh ssh.exe
2alias ssh-add ssh-add.exe
3alias ssh-keygen ssh-keygen.exe

ℹ | INFO
Es ist auch möglich den SSH-Agenten aus Windows direkt in WSL verfügbar zu machen. Das würde aber eine etwas kompliziertere Einrichtung mit zusätzlicher Software, die man selber aus einem GitHub-Repo bauen muss, erfordern. » npiperelay

Git in WSL konfigurieren, um SSH aus Windows zu benutzen

Lediglich einen Alias in der Shell zu definieren reicht aber noch nicht für git.
Damit das funktioniert müssen wir für git genau festlegen welche programme für SSH und GPG genutzt werden sollen. ind der globalen ~/.gitconfig müssen folgende stellen ergänzt werden:

Klonen und Synchronisieren

1[core]
2       sshcommand = ssh.exe
3[http]
4       sslBackend = gnutls

Commits signieren

1[user]
2        signingkey = <Inhalt des Public Keys>
3[gpg]
4        format = ssh
5[gpg "ssh"]
6        program = ssh-keygen.exe
7        allowedSignersFile = /mnt/c/users/<Benutzername>/.ssh/allowed_signers
8[commit]
9        gpgsign = true

🌐| Siehe git ssh und gpg Dokumentation der Einstellungen.

Damit sollten die Authentifizierung und Signierung der Commits mit dem SSH-Agenten aus dem Windows Hostsystem funktionieren.

🗒️| NOTIZ
Warum benutzt man nicht einfach git.exe? - Der Dateisystemzugriff zwischen Windows und WSL ist sehr langsam. Daher wird grundsätzlich empfohlen die Dateisysteme in Projekten nicht zu vermischen. Git würde dann durch die Dateisystemüberwachung stark verlangsamt werden.

Installation und Verknüpfung der Docker-/Podman-CLI mit Podman Desktop

in Ubuntu/WSL

Kann man also einfach das gleiche mit Podman machen? - Eher nicht. Grundlegende Befehle funktionieren wohl, aber Beispielsweise beim Einbinden von Dateisystem-Mounts würde es zu nicht zusammenpassenden Dateipfaden kommen.
Ausserdem erwarten einige Entwicklungswerkzuege einen Docker-Socket oder eine echte ausführbare Datei.

Zunächsteinmal sollten wir uns anschauen, wie man Podman von einer anderen WSL Distribution aus erreicht. Podman Desktop stellt unter /mnt/wsl/podman-sockets/podman-machine-default/ Sockets für die Kommunikation mit der Engine bereit.
Wir können die gleiche Methode wie aus der Podman Desktop Dokumentation benutzen, um eine echte Docker-CLI mit podman zu verknüpfen.

❗| ACHTUNG Seit Version 29 hat Docker den Support für die API-Version 1.41, die noch von Podman benutzt wird, eingestellt. Die letzte Version, die noch von Docker unterstützt wird, ist 1.44.
Eventuell muss also eine ältere Docker-CLI installiert werden.

Wir erstellen einen Kontext für den Podman Socket und setzten ihn in Docker aktiv:

1docker context create podman-root --docker "host=unix:///mnt/wsl/podman-sockets/podman-machine-default/podman-root.sock"
2 docker context use podman-root

Alternativ kann auch die DOCKER_HOST-Variable genutzt werden.

in Windows

Auf Windows können die Docker Client Binaries installiert werden. Diese werden jedoch ohne plugins ausgeliefert. Das compose und buildx müssen noch nachinstalliert werden.
Die Pakete sind jeweils auch über den Windows Paket Manager verfügbar.

Wenn man sich für die WinGet Pakete entscheidet oder die losen Downloads nicht im Plugin-Ordner für Docker ablegt, muss man noch Symbolische Links anlegen, die auf die Binärdateien verweisen.

1winget add Docker.DockerCLI
2winget add Docker.DockerCompose
3winget add Docker.Buildx
4
5sudo Powershell.exe ni -Path ~/.docker/cli-plugins/docker-compose.exe -ItemType SymbolicLink -Value "$($Env:LocalAppData)\Microsoft\WinGet\Packages\Docker.DockerCompose_Microsoft.Winget.Source_8wekyb3d8bbwe\docker-compose.exe" -Force
6sudo Powershell.exe ni -Path ~/.docker/cli-plugins/docker-buildx.exe -ItemType SymbolicLink -Value "$($Env:LocalAppData)\Microsoft\WinGet\Packages\Docker.Buildx_Microsoft.Winget.Source_8wekyb3d8bbwe\docker-buildx.exe" -Force

ℹ | INFORMATION

sudo für Windows ist ein optionales Eintwicklertool, dass Prozesse mit Admin-Privilegien ausführt.
Es kann aber nicht direkt Befehle ausführen.

Mit aktiviert Docker-Kompatibilität sollte die CLI ohne Weitere konfiguration eines Kontexts funktionieren.

---

ℹ | INFORMATION
Beim Ausführen von Devcontainern mit etwas anderem als Docker wird man früher oder später unweigerlich auf Probleme stoßen. - Selbst wenn man Docker benutzt ist ein fehlerfreier Betrieb nicht unbedingt garantiert.

In dieser Diskussion werden einige Workarounds für häufige Fehler mit Podman in WSL und Devcontainern aufgeführt.
Gegebenfalls muss zusätzlich noch die Runtime für Podman von runc auf crun ungestellt werden, wenn man die Fehler
bind mounts cannot have any filesystem-specific options applied oder
invalid additional build context format: {"dev_containers_feature_content_source":{"IsURL":false,"IsImage":false,"Value":"/tmp/devcontainercli bekommt.

» ~/.config/containers/containers.conf:

1[engine]
2runtime = "/user/bin/crun"