Question
Switching TortoiseGit from TortoiseGitPlink to Git's ssh.exe: what key and host-key configuration must move with it
Ash Echo
0 reputation · 15 Nov 2023, 17:12 UTC
76.5K views1
Loading…
0 reputation · 15 Nov 2023, 17:12 UTC
Our team standardizes developer machines on TortoiseGit over Windows. Repositories authenticate to our Git server over SSH, and the setup works on every interactive desktop where Pageant holds a PuTTY-format .ppk key. The same repositories fail authentication when cloned from a Windows service account on a build machine, and we are considering changing Settings > Network > SSH client from the bundled TortoiseGitPlink to Git's ssh.exe (OpenSSH) so both contexts behave identically.
My understanding is that TortoiseGitPlink reads keys from Pageant or a per-remote Putty key setting, and ignores ~/.ssh/config and OpenSSH-format keys, while ssh.exe honors ~/.ssh/config, id_* key files, and its own known_hosts. Switching the client therefore seems to change which key files, host-key stores, and per-remote overrides apply, and the build account cannot see the interactive user's Pageant session anyway.
What is unclear is the full migration surface: whether existing per-remote Putty key settings are silently ignored after the switch, whether cached host keys in the PuTTY registry need to be re-established for OpenSSH, and whether GIT_SSH or a system OpenSSH install can still override the settings dialog.
Assume a current TortoiseGit 2.x release; exact menu labels to be verified against the installed version.
31775 reputation · 16 Nov 2023, 01:21 UTC
When you switch TortoiseGit’s SSH client from TortoiseGitPlink to Git’s ssh.exe, the per‑remote PuTTY key settings are ignored and host‑key verification moves from the PuTTY registry to OpenSSH’s known_hosts file. You must therefore copy or convert the private key to OpenSSH format (or reference it via ~/.ssh/config) and pre‑populate the service account’s known_hosts.
If the service account cannot see the interactive user’s Pageant session, you must make the key available to OpenSSH. OpenSSH cannot read PuTTY‑format .ppk files directly, so either convert them with PuTTYgen or use an ssh‑pageant bridge. The known_hosts file must be readable by the account; if the account’s HOME points to a non‑writable directory, ssh.exe will fail to load keys or host keys.
Please confirm whether the service account’s HOME (or %USERPROFILE%) points to a writable directory where .ssh can be created, and whether any GIT_SSH, GIT_SSH_COMMAND or core.sshCommand variables are set for that account, as they would override the TortoiseGit setting.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 16 Nov 2023, 01:20 UTC
TortoiseGit resolves the SSH client in this order: GIT_SSH environment variable → Settings → Network → SSH client dropdown → ssh.exe on PATH. Setting GIT_SSH=C:\\Program Files\\Git\\usr\\bin\\ssh.exe (or the Git for Windows install path) in the service account’s environment guarantees the same binary regardless of the UI setting, and it survives TortoiseGit updates. The dropdown value is stored at HKCU\\Software\\TortoiseGit\\SSHClient (REG_SZ), which can be scripted via Group Policy or a .reg file for machine provisioning.
Unlike PuTTY, OpenSSH on Windows requires the private key file to be accessible only by the account running ssh.exe. After copying or converting the key, run:
putty
ssh
tortoisegiticacls \"%USERPROFILE%\\.ssh\\id_ed25519\" /inheritance:r /grant:r \"%USERNAME%:(R)\"If the service account’s profile is under a non-standard path (e.g., C:\\ServiceProfiles\\svc_git), ensure that directory exists and is writable before first use; psexec -s -i cmd can create it for SYSTEM accounts.
To confirm the exact binary and arguments at runtime, set GIT_TRACE=1 and GIT_SSH_COMMAND=\"ssh -v\" in the service account’s environment, then trigger a clone/pull. The trace output (stderr or GIT_TRACE2_EVENT file) shows lines like exec: 'C:\\Program Files\\Git\\usr\\bin\\ssh.exe' ..., eliminating ambiguity about which client was invoked.