TortoiseGit SSH client change: moving from TortoiseGitPlink to OpenSSH breaks production authentication

Why the mismatch matters

On a workstation TortoiseGit often talks to a remote via TortoiseGitPlink, which pulls keys from Pageant and keeps its own host‑key cache in the registry. In a CI job the same repository is usually accessed by the command‑line git, which defaults to the OpenSSH ssh.exe bundled with Git for Windows. Because the two clients look in different places for keys and host keys, the same credentials can succeed in one environment and fail in another.

1. Confirm the SSH client used by TortoiseGit

1. Open TortoiseGit Settings – Settings > Network > SSH client. Note the full path shown. If it points to plink.exe (or a custom path), TortoiseGit will use that binary.
2. Run where.exe plink.exe (or the path you saw) from a command prompt in the same user session to ensure the executable is reachable.

2. Confirm the SSH client used by command‑line Git

1. In the repository run git config --show-origin --get-all core.sshCommand. If a value appears, it overrides the default.
2. Check environment variables that can override Git: GIT_SSH_COMMAND and GIT_SSH.
3. Run git config --global --show-origin core.sshCommand and git config --system --show-origin core.sshCommand to see if a global or system setting is in place.

3. Verify which binary actually runs during a fetch

GIT_TRACE=1 GIT_SSH_COMMAND=\"ssh -v\" git ls-remote [contact removed]:org/repo.git

The trace will print the path of the binary that Git invoked, the key files it offered, and the host‑key check it performed. Look for lines like debug1: Reading configuration data /c/Users/me/.ssh/config to confirm the OpenSSH client, or debug1: Reading configuration data /c/Users/me/.ssh/ssh_config for PuTTY‑style config if you are using plink with its own config file.

4. Compare host‑key stores

• OpenSSH: %USERPROFILE%\\.ssh\\known_hosts.
• PuTTY/Plink: HKCU\\Software\\SimonTatham\\PuTTY\\SshHostKeys.

If the server’s key appears only in the registry entry, Plink has connected before; if it’s only in known_hosts, OpenSSH has. A missing entry in both indicates the host has never been seen by either client.

5. Optional: Test key presence

Run ssh -v [contact removed] (or the remote host) from the same user session. If the connection succeeds, the key is available to OpenSSH. For Plink, run plink -v [contact removed] and watch for the Authentication succeeded message.

6. Ask the missing diagnostic detail

Does the CI job run under a user session that has Pageant or ssh-agent active, or is it executed as a Windows service? This affects whether a PuTTY‑based workflow can work in CI and may change the recommendation.

Conclusion

For a mixed team that uses both GUI workflows and automated CI, pointing every installation of TortoiseGit to the Git for Windows ssh.exe is the most maintainable path. It keeps key management in plain files (~/.ssh/id_* and known_hosts), which Git, TortoiseGit, and CI all read consistently. Moving to PuTTY/Pageant only makes sense if the organization already relies on .ppk keys, hardware tokens, or a Pageant‑based agent that cannot be replicated in CI.