TortoiseGit SSH-Client Setting Change Reconfigures Key-Format and Agent-Usage Without Unified Migration Path

Short answer

No. Changing TortoiseGit's Settings > Network > SSH client does not automatically alter authentication for an existing repository when .ppk and OpenSSH keys coexist. The switch only changes which backend TortoiseGit invokes for new SSH operations. It does not migrate keys, reload Pageant or ssh-agent, change remote URLs, or override GIT_SSH, GIT_SSH_COMMAND, core.sshCommand, or repository-specific .git/config entries. If such an override exists, the UI change may have no effect.

Confirmed backend behavior

• PuTTY / TortoiseGitPLink pairs with Pageant and .ppk private keys.
• Git for Windows OpenSSH pairs with ssh-agent and OpenSSH-format private keys.
• A .ppk key is not directly usable by ssh.exe, and an ssh-agent key is not directly usable by Pageant, without conversion or loading into the target agent.

Selection criteria after a setting change

TortoiseGit applies roughly this order:

1. Active backend from Settings > Network > SSH client.
2. PuTTY backend: Pageant if running and holding an unlocked identity; otherwise a directly configured .ppk key.
3. OpenSSH backend: ssh-agent if SSH_AUTH_SOCK is reachable and holds an identity; otherwise a directly configured OpenSSH private key.
4. If neither agent nor matching key is available, authentication fails; the UI change does not load identities.

Host-key acceptance in scripted contexts

• PuTTY backend uses the PuTTY host-key cache and may reject or prompt on an uncached or changed host key in batch mode, depending on version.
• OpenSSH backend uses known_hosts and typically fails on an unknown or changed host key in non-interactive use unless StrictHostKeyChecking is relaxed or known_hosts is pre-populated.

Defaults are version-sensitive, so do not rely on UI defaults for CI or scripts.

Steps for this case

1. Inspect the effective SSH configuration: remote URL, git config --get core.sshCommand, and environment variables GIT_SSH, GIT_SSH_COMMAND, SSH_AUTH_SOCK.
2. Confirm the TortoiseGit SSH-client setting under Settings > Network > SSH client.
3. Test one remote with fetch or pull after the switch and note whether errors reference Pageant, .ppk, ssh-agent, or host-key verification.
4. If the backend and key format mismatch, convert the key and load it into the target agent before changing production repositories.
5. For scripts, pre-populate known_hosts or set StrictHostKeyChecking explicitly; do not rely on interactive prompts.

Assumptions and uncertainty

This assumes a recent TortoiseGit release with both backends, Git for Windows installed for OpenSSH, an SSH remote URL, and no environment or repository config overriding the SSH command. Exact defaults and minimum supported versions vary by release and should be checked against your installed versions.

Verification

git config --get remote.origin.url
git config --get core.sshCommand
echo 'GIT_SSH=$GIT_SSH GIT_SSH_COMMAND=$GIT_SSH_COMMAND SSH_AUTH_SOCK=$SSH_AUTH_SOCK'

Then run git fetch against the remote and compare observed agent and key-format errors against the selected backend.

Missing diagnostic detail: does the repository or environment define core.sshCommand, GIT_SSH, or GIT_SSH_COMMAND? If any override exists, the TortoiseGit UI setting alone will not change authentication, and the fix must target the override instead of the backend selector.